Solr的（JVM）高峯每小時

Question

解決

在我們的情況下，問題是，對於SuggestRequestHandler（requestHandler NAME =「/建議」）現在facelimit已設置：10個 每個也出現了幾個請求單一建議由應用程序提出的請求。爲什麼這導致（只）小時高峯尚未明確...

謝謝大家的提示和幫助 - 我讚賞！

我們的Solr/Java過程每過一個小時（中午12點，13點，14點，20點，20點，21點，22點和23點）都會有一個高峯，意味着Solr運行的Java進程增加了3倍的CPU使用率和響應時間 - 通常需要msecs響應，最多9秒。總是2-3分鐘，只有當我們的網站有流量時（有一個叫做Java的php應用程序）。 Crond完全禁用，但仍然是每一整小時的問題。基本上我認爲，我們幾乎嘗試了所有的GC和內存組合

有人任何想法，爲什麼發生這種情況 - 這裏的一些細節（或者也許不是？）：

• 系統：32 GB RAM，24核心（主要是共享用PHP-fpm的，但即使是分離的只是solr的作爲試驗同樣的問題）
• Solr的版本3.6（在碼頭 - 也暫時Glassfish的）
• OS：RHEL 5.7
• 多核設置（4個索引與每個2芯）

二手處理程序（solrconfig.xml中）：

<requestHandler name="standard" class="solr.SearchHandler" default="true"> 
<requestHandler name="dismax" class="solr.SearchHandler" > 
<requestHandler name="/suggest" class="solr.SearchHandler"> 
<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" /> 
<requestHandler name="/analysis/document" class="solr.DocumentAnalysisRequestHandler" /> 
<requestHandler name="/analysis/field" class="solr.FieldAnalysisRequestHandler" /> 
<requestHandler name="/admin/" class="org.apache.solr.handler.admin.AdminHandlers" /> 
<requestHandler name="/admin/ping" class="PingRequestHandler"> 
<requestHandler name="/debug/dump" class="solr.DumpRequestHandler" > 
<requestHandler name="/replication" class="solr.ReplicationHandler" > 

（也測試沒有複製和ping）

使用的過濾器：

<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" /> 
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" 
<filter class="solr.LowerCaseFilterFactory"/> 
<filter class="solr.PortugueseMinimalStemFilterFactory"/> 
<filter class="solr.ISOLatin1AccentFilterFactory"/> 
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true"/> 
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" 
<filter class="solr.LowerCaseFilterFactory"/> 
<filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="false"/> 
<filter class="solr.PortugueseMinimalStemFilterFactory"/> 
<filter class="solr.LowerCaseFilterFactory" /> 
<filter class="solr.EdgeNGramFilterFactory" maxGramSize="30" minGramSize="1"/> 
<filter class="solr.ASCIIFoldingFilterFactory"/> 
<filter class="solr.LowerCaseFilterFactory" /> 

指數尺寸：約100 MB（居然連少一點）

當前Java選項：

JAVA_OPTS="-Xmx4096m -Xms4096m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Dsun.rmi.dgc.server.gcInterval=300000 -Dsun.rmi.dgc.client.gcInterval=300000 -XX:NewRatio=1 -Xloggc:/shop/logs/live/solr/gc.log -verbose:gc -XX:+PrintGCDateStamps" 

相同的選項，但與1024,2048,8192和12 GB根本沒有幫助。

其他嘗試：

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的摘錄（例如整整一個小時的問題）：

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] 

也有隻有2個條目（大約1天）大於1秒： grep -oP「，[1-9] .. *？secs] $」/ shop/logs/live/solr/gc .log ，1.1727270秒] ，1.0390840秒]

有人有任何想法或已經有這種現象與solr/jvm？

Answer 1

如果索引大小僅僅是100MB，而問題的GC我將開始通過相關：

1. 減少-Xmx小於1024，開始於約256米，看看它是否夠
2. 不使用任何-XX在開始時
3. 使用最新的JDK

Answer 2

不要相信你的GC日誌，除非你有-XX：+ PrintGCApplicationStoppedTime期權。即使這樣，他們也會懷疑。除非包含此標誌，否則可能會有很長時間的暫停和部分暫停並未報告。例如。我看到偶爾長時間運行的計數循環需要15秒才能達到安全點，因爲GC只報告了實際做了一些工作的暫停時間的.08秒部分所引起的暫停。還有很多暫停，其原因不被認爲是「GC」的一部分，因此可能未被GC日誌標記報告。

您可以嘗試添加jHiccup作爲代理來報告觀察到的暫停/毛刺/失速/打嗝，而不是依賴JVM日誌的誠實。如果它顯示出多秒的故障，那麼你會知道你的JVM正在暫停。如果它顯示出流暢的JVM操作，那麼你知道看看你的其他配置部分。