Java 每小时Solr（JVM）峰值

解决

在我们的例子中，问题是SuggestRequestHandler（requestHandler name=“/suggest”）的facelimit已设置为：10 此外，对于应用程序提出的每个建议请求，都有多个请求。这导致（仅仅）小时高峰的原因还不清楚

谢谢你们给我的建议和帮助，我很感激

每一个完整的小时（12:00，13:00，14:00，…，20:00，21:00，22:00，23:00），我们的Solr/Java进程都有一个峰值-这意味着Solr运行的Java进程增加了3倍的CPU使用率和响应时间-通常需要毫秒来响应，最多9秒。始终为2-3分钟，只有当我们的网站上有流量（有一个php应用程序调用Java）。克罗德完全瘫痪了，但每一个小时都会出现问题。基本上，我认为我们尝试了几乎所有的GC和内存组合（或者可能不是？）

有人知道为什么会发生这种情况-以下是一些细节：

• 系统：32 GB RAM，24核（大部分与php fpm共享，但甚至只隔离了solr，以测试相同的问题）
• Solr版本3.6（在码头上-暂时也包括Glassfish）
• 操作系统：RHEL 5.7
• 多核设置（每2核4个索引）

使用的处理程序（solrconfig.xml）：

相同的选项，但1024、2048、8192和12GB的配置根本没有帮助

其他尝试：

JAVA_OPTS="-server -Xmx2048m -XX:MaxPermSize=128m -XX:+UseParNewGC     -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC"

JAVA_OPTS="-Xmx2048m -Xms2048m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Djava.util.logging.config.file=/opt/solr-jetty/etc/jetty-logging.properties"

其他尝试：

JAVA_OPTS="-server -Xmx2048m -XX:MaxPermSize=128m -XX:+UseParNewGC     -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC"

JAVA_OPTS="-Xmx2048m -Xms2048m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Djava.util.logging.config.file=/opt/solr-jetty/etc/jetty-logging.properties"

这里是gc.log的摘录（关于这样一个整整一小时的问题）：

此外，只有2个条目（约1天）大于1秒： grep-oP“，[1-9]…*？secs]$”/shop/logs/live/solr/gc.log ，1.1727270秒] ，1.0390840秒]

---

有人知道或已经知道solr/jvm存在这种现象吗？

如果索引大小仅为100MB，并且问题与GC有关，我将从以下内容开始：

将-Xmx减少到1024以下，从大约256m开始，看看是否足够

一开始不要使用任何-XX

使用最新的jdk

---

除非在选项中包含-XX:+PrintGCApplicationsTopedTime，否则不要相信GC日志。即使在那时也要怀疑他们。有些暂停和部分暂停可能很长，除非包含此标志，否则将无法报告。例如，我见过偶尔长时间运行计数循环导致的暂停，需要15秒才能到达安全点，GC只报告了暂停的0.08秒部分，而实际上它做了一些工作。还有很多暂停，其原因不属于“GC”的一部分，因此GC日志标记无法报告

---

您可以尝试添加代理来报告观察到的暂停/故障/暂停/打嗝，而不是依赖JVM日志的真实性。如果它显示多秒故障，那么您将知道JVM正在暂停。如果显示JVM运行平稳，那么您需要查看其他配置部分。

尝试禁用列表中的最后三个请求处理程序，看看会发生什么。另外，您如何触发文档分析？您是否排除了GC活动？我发现您在

-Xloggc:/shop/logs/live/solr/GC.log

中打印了GC活动。如果你这样做了，请在你的问题中包括它。它可能是计算机上每小时运行的其他东西吗？还是一个机器人每小时都来？或者你的ISP每小时都在节流？可能与solr autocommit\optimize功能有关？我不得不说我不明白这个问题的解决方案是什么@GeorgBuske你能更详细地解释一下吗？我想给你一个投票，因为这听起来是一个很好的进一步调试方法（这将是下一步之一）…：-）总之，关于jHiccup的一个问题是：当我们暂时切换到Glassfish时-如何将jHiccup放在Glassfish前面-只是修补bin命令？自述文件中有关于插入jHiccup的各种方法的注释。我发现其中一个最简单的方法是使用_JAVA_选项潜入，如：export _JAVA_OPTIONS='-javaagent:/path/to/jHiccup/bin/jHiccup.jar'也非常感谢您的回答！听起来都很合理：-）

JAVA_OPTS="-Xmx2048m -Xms2048m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Djava.util.logging.config.file=/opt/solr-jetty/etc/jetty-logging.properties"

2013-03-03T19:59:04.157-0300: 8087.754: [GC 3433559K->1788819K(3914560K), 0.0358190 secs]
2013-03-03T19:59:12.031-0300: 8095.628: [GC 3437075K->1792088K(3914560K), 0.0365830 secs]
2013-03-03T19:59:22.419-0300: 8106.016: [GC 3440344K->1803266K(3914560K), 0.0422040 secs]
2013-03-03T19:59:29.044-0300: 8112.641: [GC 3451522K->1815743K(3914560K), 0.0439870 secs]
2013-03-03T19:59:37.002-0300: 8120.599: [GC 3463999K->1821601K(3914560K), 0.0378990 secs]
2013-03-03T19:59:45.468-0300: 8129.065: [GC 3469857K->1822911K(3914560K), 0.0386720 secs]
2013-03-03T19:59:53.750-0300: 8137.347: [GC 3471167K->1829299K(3914560K), 0.0405040 secs]
2013-03-03T20:00:01.829-0300: 8145.426: [GC 3477555K->1832046K(3914560K), 0.0383070 secs]
2013-03-03T20:00:06.327-0300: 8149.924: [GC 3480302K->1831567K(3914560K), 0.0450550 secs]
2013-03-03T20:00:11.123-0300: 8154.719: [GC 3479823K->1843283K(3914560K), 0.0401710 secs]
2013-03-03T20:00:14.360-0300: 8157.957: [GC 3491539K->1854079K(3914560K), 0.0368560 secs]
2013-03-03T20:00:17.419-0300: 8161.015: [GC 3502335K->1855130K(3914560K), 0.0375530 secs]
2013-03-03T20:00:20.006-0300: 8163.603: [GC 3503386K->1861867K(3914560K), 0.0413470 secs]
2013-03-03T20:00:22.726-0300: 8166.323: [GC 3510123K->1870292K(3914560K), 0.0360600 secs]
2013-03-03T20:00:25.420-0300: 8169.017: [GC 3518548K->1872701K(3914560K), 0.0326970 secs]
2013-03-03T20:00:27.138-0300: 8170.735: [GC 3520957K->1873446K(3914560K), 0.0381430 secs]
2013-03-03T20:00:28.748-0300: 8172.345: [GC 3521702K->1889189K(3914560K), 0.0379160 secs]
2013-03-03T20:00:30.404-0300: 8174.001: [GC 3537445K->1887193K(3914560K), 0.0407670 secs]
2013-03-03T20:00:32.713-0300: 8176.309: [GC 3535449K->1892863K(3914560K), 0.0366880 secs]
2013-03-03T20:00:34.791-0300: 8178.388: [GC 3541119K->1899095K(3914560K), 0.0398270 secs]
2013-03-03T20:00:36.533-0300: 8180.129: [GC 3547351K->1910071K(3914560K), 0.0373960 secs]
2013-03-03T20:00:39.037-0300: 8182.634: [GC 3558327K->1904198K(3914560K), 0.0393020 secs]
2013-03-03T20:00:41.548-0300: 8185.144: [GC 3552454K->1912352K(3914560K), 0.0444060 secs]
2013-03-03T20:00:43.771-0300: 8187.368: [GC 3560608K->1919304K(3914560K), 0.0427220 secs]
2013-03-03T20:00:47.411-0300: 8191.008: [GC 3566354K->1918102K(3914560K), 0.0418150 secs]
2013-03-03T20:00:50.925-0300: 8194.522: [GC 3564290K->1930888K(3914560K), 0.0414700 secs]
2013-03-03T20:00:52.991-0300: 8196.588: [GC 3579144K->1933251K(3914560K), 0.0349600 secs]
2013-03-03T20:00:53.027-0300: 8196.624: [GC 1939697K(3914560K), 0.0256300 secs]
2013-03-03T20:00:54.208-0300: 8197.804: [GC 2780505K(3914560K), 0.1424860 secs]
2013-03-03T20:00:55.684-0300: 8199.281: [GC 3029503K->1389766K(3914560K), 0.0370380 secs]
2013-03-03T20:00:58.289-0300: 8201.886: [GC 2213458K->570843K(3914560K), 0.0413220 secs]
2013-03-03T20:01:00.672-0300: 8204.268: [GC 1962741K->319619K(3914560K), 0.0410840 secs]
2013-03-03T20:01:02.906-0300: 8206.503: [GC 1966833K->319605K(3914560K), 0.0453730 secs]
2013-03-03T20:01:06.861-0300: 8210.458: [GC 1967861K->330864K(3914560K), 0.0425570 secs]
2013-03-03T20:01:10.067-0300: 8213.664: [GC 1979120K->336541K(3914560K), 0.0479380 secs]
2013-03-03T20:01:12.587-0300: 8216.184: [GC 1984797K->343203K(3914560K), 0.0376810 secs]