2012-05-08 13 views
5

करने से हम Solr 3.6 के साथ एक मास्टर-दास सेटअप चला रहे हैं निम्नलिखित ऑटो प्रतिबद्ध विकल्पों का उपयोग कर अद्यतन अनुरोध ब्लॉक करने के लिए प्रकट होता है 600000Solr जबकि

हम हमारे सूचकांक में लगभग 5 मिलियन दस्तावेज हैं जो लगभग 550 जीबी लेते हैं। हम अमेज़ॅन ईसी 2 एक्सलार्ज इंस्टेंस (4 आभासी कोर और 15 जीबी) पर मास्टर और गुलाम दोनों चला रहे हैं। हमारे पास विशेष रूप से उच्च लेखन थ्रूपुट नहीं है - प्रति मिनट लगभग 100 नए दस्तावेज़।

हम जेटी को एक कंटेनर के रूप में उपयोग कर रहे हैं जिसमें 6 जीबी आवंटित है।

समस्या यह है कि एक बार प्रतिबद्धता शुरू हो जाने के बाद, हमारे सभी अपडेट अनुरोध समय समाप्त हो जाते हैं (हम इस बॉक्स के खिलाफ प्रश्न नहीं कर रहे हैं)। प्रतिबद्धता में लगभग 20-25 मिनट लगते हैं, जिसके दौरान हम सोलर में कोई भी नया दस्तावेज़ जोड़ने में असमर्थ हैं।

निम्नलिखित प्रश्नों में से एक उत्तर में 2 कोर का उपयोग करने और पूरी तरह से अपडेट होने के बाद उन्हें स्वैप करने का सुझाव दिया गया है। हालांकि यह शीर्ष पर थोड़ा सा लगता है।

Solr requests time out during index update. Perhaps replication a possible solution?

कुछ और मैं देख जाना चाहिए कुछ भी क्यों Solr अवरुद्ध अनुरोध हो रहा है के बारे में पर है? मैं आशावादी आशा करती हूं कि वहाँ config है कि मैं अनदेखी की है में एक "dontBlockUpdateRequestsWhenCommitting" झंडा ...

बहुत धन्यवाद,

+0

सोलर का कौन सा संस्करण आप उपयोग करते हैं? – kamaci

उत्तर

1

इनाम कारण और समस्या यहाँ सवाल पर उल्लेख के अनुसार Solr से एक समाधान है:

सोलर की क्षमता है जिसे सोलर क्लाउड कहा जाता है जिसे सोलर के 4.x संस्करण से शुरू किया जाता है। पिछले मास्टर/गुलाम वास्तुकला के बजाय नेता और प्रतिकृतियां हैं। लीडर इंडेक्सिंग दस्तावेजों और प्रतिकृतियां सवालों के जवाब देने के लिए ज़िम्मेदार हैं। सिस्टम जुकीपर द्वारा प्रबंधित किया जाता है। यदि कोई नेता अपनी प्रतिकृतियों में से एक को छोड़ देता है तो उसे नए नेता के रूप में चुना जाता है।

सब कुछ अगर आप इंडेक्सिंग प्रक्रिया को विभाजित करना चाहते हैं जो स्वचालित रूप से SolrCloud के साथ ठीक है क्योंकि प्रत्येक शार्ड के लिए एक नेता मौजूद है और वे अपने शर्ड के दस्तावेज़ों के अनुक्रमण के लिए ज़िम्मेदार हैं। जब आप सिस्टम में कोई प्रश्न भेजते हैं तो कुछ सौर नोड्स होंगे (बेशक अगर शोर गिनती से अधिक सोलर नोड्स हैं) जो क्वेरी के जवाब देने के लिए तैयार होने के लिए ज़िम्मेदार नहीं है। जब आप अधिक प्रतिकृति जोड़ते हैं, तो आपको तेजी से क्वेरी परिणाम मिल जाएगा (लेकिन इंडेक्सिंग आदि के दौरान यह अधिक इनबाउंड नेटवर्क यातायात का कारण बन जाएगा)

-1

उन लोगों के लिए जो एक समान समस्या का सामना कर रहे हैं, मेरी समस्या का कारण था कि मेरे पास बहुत सारे क्षेत्र थे दस्तावेज़ में, मैंने स्वचालित फ़ील्ड्स * _t का उपयोग किया, और फ़ील्ड की संख्या बहुत तेज़ी से बढ़ती है, और जब यह एक निश्चित संख्या तक पहुंच जाती है, तो यह केवल हलर को हल करती है और प्रतिबद्ध हमेशा के लिए ले जाती है।

दूसरी बात, मैंने प्रोफाइलिंग करने के लिए कुछ प्रयास किए, यह अंततः स्ट्रिंग.intern() फ़ंक्शन कॉल द्वारा उपभोग किया जाता है, ऐसा लगता है कि दस्तावेज़ संख्या में फ़ील्ड की संख्या, जब यह संख्या बढ़ जाती है, string.intern() धीमा हो रहा है।

solr4 स्रोत अब string.intern() का उपयोग नहीं कर रहा है। लेकिन बड़ी संख्या में खेतों में प्रदर्शन अभी भी काफी आसानी से मारता है।