2013-03-04 6 views
5

हलSolr (JVM) शिखर हर घंटे

हमारे मामले में समस्या अब facelimit स्थापित किया गया है (requestHandler नाम = "/ सुझाव है") SuggestRequestHandler के लिए है कि गया था: 10 प्रत्येक के लिए इसके अलावा हुई है कई अनुरोध आवेदन द्वारा किए गए एकल सुझाव अनुरोध। क्यों यह एक (बस) घंटे की चोटी का नेतृत्व अभी तक स्पष्ट नहीं है ...

युक्तियों और सहायता के लिए सभी को धन्यवाद - मैंने सराहना की!

प्रत्येक पूर्ण घंटे (12:00, 13:00, 14:00, ..., 20:00, 21:00, 22:00, 23:00) हमारी सोलर/जावा प्रक्रिया में एक चोटी है - जो का अर्थ है जावा प्रक्रिया जहां सोलर चल रहा है 3x बार CPU उपयोग बढ़ता है और प्रतिक्रिया समय लेता है - जो आमतौर पर 9 सेकंड तक प्रतिक्रिया देने के लिए msecs लेता है। हमेशा 2 - 3 मिनट के लिए और केवल तभी जब हमारी साइट पर यातायात हो (वहां एक PHP अनुप्रयोग है जो जावा को कॉल करता है)। क्रॉन्ड पूरी तरह से अक्षम था लेकिन अभी भी हर पूर्ण घंटे में समस्या है। और मूल रूप से मुझे लगता है कि हम लगभग हर जीसी और स्मृति संयोजन की कोशिश की

किसी ने किसी भी विचार क्यों ऐसा होता है - यहाँ कुछ विवरण (या शायद नहीं?):

  • सिस्टम: 32 जीबी रैम, 24 कोर (ज्यादातर साझा php-एफ पी एम, लेकिन फिर भी पृथक सिर्फ Solr के रूप में परीक्षण एक ही समस्या)
  • Solr संस्करण 3.6 (जेट्टी पर साथ - अस्थायी रूप से भी Glassfish)
  • ओएस: RHEL 5.7
  • मल्टीकोर सेटअप (प्रत्येक 2 कोर के साथ 4 अनुक्रमित)

प्रयुक्त हैंडलर (solrconfig.xml):

<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 एमबी वास्तव में भी (

<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" > 

प्रयुक्त फिल्टर (भी प्रतिकृति और पिंग के बिना परीक्षण किया) थोड़ा कम)

वर्तमान जावा विकल्प:

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 जीबी के साथ बिल्कुल मदद नहीं मिली।

अन्य कोशिश:

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 के साथ था?

+0

अपनी सूची में अंतिम तीन अनुरोध हैंडलर को अक्षम करने का प्रयास करें, देखें कि क्या होता है। साथ ही, आप दस्तावेज़ विश्लेषण को कैसे ट्रिगर करते हैं? –

+0

क्या आपने जीसी गतिविधि को बाहर कर दिया है? मैंने पाया कि आपने '-Xloggc:/shop/logs/live/solr/gc.log' में जीसी गतिविधि मुद्रित की थी। यदि आपने ऐसा किया है, तो कृपया इसे अपने प्रश्न में शामिल करें। – ericson

+0

क्या यह संभवतः कुछ और है जो कंप्यूटर पर हर घंटे चलता है? या एक बॉट हर घंटे जा रहा है? या आपका आईएसपी हर घंटे थ्रॉटलिंग? – Patashu

उत्तर

0

अगर सूचकांक आकार सिर्फ 100 एमबी है, और इस मुद्दे को जीसी करने के लिए मैं शुरू होगा द्वारा संबंधित है: अगर यह काफी है

  1. 1024 से कम करने के लिए -Xmx को कम करने, के बारे में 256M पर शुरू और देखो
  2. विकल्पों में + PrintGCApplicationStoppedTime: न जब तक आप -XX शामिल अपने जीसी लॉग पर विश्वास मत करो शुरुआत
  3. उपयोग नवीनतम JDK
+0

उत्तर के लिए बहुत बहुत धन्यवाद! सभी बहुत उचित लगता है :-) –

5

पर किसी भी -XX का उपयोग करें। फिर भी उन्हें संदेह है। ऐसे विराम और विराम के कुछ भाग हैं जो बहुत लंबे समय तक हो सकते हैं और जब तक आप इस ध्वज को शामिल नहीं करते हैं तब तक रिपोर्ट नहीं किया जाता है। जैसे मैंने कभी-कभी लंबे समय तक चलने वाले गलती वाले लूप के कारण 15 सेकंड तक एक सुरक्षित बिंदु तक पहुंचने के कारणों को देखा है, जहां जीसी ने केवल विराम के केवल .08 सेकेंड हिस्से की सूचना दी जहां वास्तव में कुछ काम किया। ऐसे कई विराम भी हैं जिनके कारणों को "जीसी" का हिस्सा नहीं माना जाता है और इस प्रकार जीसी लॉगिंग झंडे द्वारा रिपोर्ट नहीं किया जा सकता है।

आप JVM लॉग की ईमानदारी में भरोसा करने के बजाय मनाए गए विराम/गड़बड़/स्टॉल/हिचकी पर रिपोर्ट करने के लिए एजेंट के रूप में jHiccup जोड़ने का प्रयास कर सकते हैं। यदि यह बहु-सेकंड ग्लिच दिखाता है तो आपको पता चलेगा कि आपका जेवीएम रुक रहा है। यदि यह चिकनी जेवीएम ऑपरेशन दिखाता है, तो आप अपने अन्य कॉन्फ़िगरेशन भागों को देखना चाहते हैं।

+0

मैं आपको एक अपवर्त देना चाहता हूं क्योंकि यह आगे डीबग करने का एक बहुत अच्छा तरीका लगता है (जो अगले चरण में से एक होता) ... :-) वैसे भी, jHiccup के बारे में एक प्रश्न : जैसा कि हमने अस्थायी रूप से ग्लासफ़िश पर स्विच किया - ग्लासफ़िश के सामने jHiccup डालना संभव है - बस बिन कमांड को पैच करना? –

+0

jHiccup डालने के विभिन्न तरीकों के बारे में README में नोट्स हैं। मुझे लगता है कि सबसे आसान में से एक को _JAVA_OPTIONS के साथ छेड़छाड़ करना है, जैसा कि: निर्यात _JAVA_OPTIONS = '- जावामैंट: /path/to/jHiccup/bin/jHiccup.jar' –

संबंधित मुद्दे