हमने अज़ुल ज़िंग जेवीएम का उपयोग करके ल्यूसीन इंडेक्स को रैम में रखा

संपूर्ण Google खोज इंडेक्स कम से कम 5 वर्षों से RAM में है। क्यों ल्यूसीन के लिए खोज सूचकांक के साथ एक ही बात की कोशिश नहीं की?

हाल ही में, रैम काफी सस्ती हो गई है, इसलिए अत्यधिक लोड संसाधनों के लिए, रैम में संपूर्ण खोज सूचकांक को रखकर एक गंभीर प्रदर्शन में सुधार की उम्मीद करना उचित है।

स्पष्ट प्रश्न यह है कि क्या हमें ल्यूसीन द्वारा प्रदान की गई RAMDirectory वर्ग में पूरे सूचकांक को लोड करने का प्रयास करना चाहिए?

दुर्भाग्य से, यह वर्ग कचरा कलेक्टर (जीसी) पर एक बहुत गंभीर भार बनाने के लिए जाना जाता है: प्रत्येक फ़ाइल को byte[1024] प्रकार के टुकड़ों की सूची के रूप में दर्शाया गया है byte[1024] । इसमें अनावश्यक सिंक्रनाइज़ेशन तंत्र भी शामिल हैं: यदि एप्लिकेशन इंडेक्स को अपडेट करता है (यानी, यह न केवल इसकी तलाश कर रहा है), RAMDirectory से डिस्क में किए गए परिवर्तनों को सहेजने का मुद्दा एक अलग समस्या है। प्रारंभ में समय भी काफी धीमा हो जाता है, क्योंकि शुरुआत में सूचकांक को स्मृति में लोड करने की आवश्यकता होती है। समस्याओं की इस सूची का सामना करते हुए, ल्यूसिन डेवलपर्स अक्सर RAMDirectory केवल छोटे अनुक्रमित या परीक्षण उद्देश्यों के लिए उपयोग करने की सलाह देते हैं, और अन्य मामलों में ऑपरेटिंग सिस्टम मेमोरी प्रबंधन तंत्र पर भरोसा करते हैं और MMapDirectory वर्ग का उपयोग करके इसे एक्सेस करते हैं।

RAMDirectory वर्ग के साथ इन समस्याओं के बावजूद, डेवलपर्स इसे बेहतर बनाने के लिए काम कर रहे हैं, और कई उपयोगकर्ता पहले से ही अपनी परियोजनाओं में इसका उपयोग कर रहे हैं।

मैंने हाल ही में अज़ुल द्वारा विकसित जावा द ज़िंग वर्चुअल मशीन के बारे में सीखा है, जो ढेर के बड़े संस्करणों के लिए भी एक पॉज़-फ्री कचरा कलेक्टर प्रदान करता है। यानी सिद्धांत रूप में, RAMDirectory वर्ग द्वारा उत्पन्न भारी मेमोरी लोड Zing के लिए कोई समस्या नहीं RAMDirectory । चलो इसे बाहर की जाँच करें! लेकिन पहले, थोड़ा स्पष्ट करें कि अस्पताल में औसत तापमान को मापने के बजाय सभी अनुरोधों के लिए प्रतिक्रिया समय का परीक्षण करना कितना महत्वपूर्ण है।

खोज क्वेरी प्रतिक्रिया समय के लिए प्रतिशत

डिफ़ॉल्ट रूप से, ल्यूसिनेयूटिल किट में उपयोगिताओं बेहद दिलचस्प चरम मूल्यों को त्यागते हुए, औसत प्रतिक्रिया समय को मापती हैं। ऐसा इसलिए किया जाता है क्योंकि इन उपयोगिताओं को एल्गोरिदम और उनके द्वारा किए गए परिवर्तनों की प्रभावशीलता का परीक्षण करने के लिए डिज़ाइन किया गया है, विशेष रूप से ऑपरेटिंग सिस्टम, डिस्क सबसिस्टम, कचरा कलेक्टर आदि के स्तर पर विलुप्त देरी द्वारा शुरू किए गए यादृच्छिक विचलन की अनदेखी कर रहा है।

लेकिन वास्तविक खोज अनुप्रयोगों के लिए, जो वास्तव में मायने रखता है वह सभी खोज प्रश्नों के लिए कुल प्रतिक्रिया समय है। खोज अनिवार्य रूप से एक संवादात्मक प्रक्रिया है: उपयोगकर्ता बैठता है और खोज परिणाम की प्रतीक्षा करता है उसके पास लौटने के लिए, और उसके बाद ही लिंक पर क्लिक करता है। यदि अनुरोधों का 1% भी बहुत समय लेता है, तो यह पहले से ही एक गंभीर समस्या है! उपयोगकर्ता अधीर हैं, और बहुत जल्दी प्रतियोगियों के पास जाते हैं।

इसलिए, मैंने लोड क्लाइंट ( सेंडटस्कसहोम ) को एक अलग मॉड्यूल में आवंटित करने के लिए ल्यूनेटुटिल को संशोधित किया, जो सभी अनुरोधों के लिए प्रतिक्रिया समय बचाता है; प्रतिक्रिया समय ग्राफ़ की साजिश रचने के लिए स्क्रिप्ट्स ( loadGraph.py और responseTimeGraph.py ) भी। सीधे चल रहे responseTimeTests.py स्क्रिप्ट को बढ़ते लोड (अनुरोध / सेकंड) के साथ परीक्षणों की एक श्रृंखला को निष्पादित करने के लिए भी संशोधित किया गया था, जो सर्वर प्रदर्शन से अधिक होने पर लोड स्वचालित रूप से परीक्षण बंद कर देता है। एक सुखद जोड़ के रूप में, यह दृष्टिकोण आपको वास्तविक सर्वर के प्रदर्शन को मापने की अनुमति देता है, बजाय औसत संकेतक से इसे अलग करने के।

वास्तविक अनुरोध भेजने के समय के सबसे सही सिमुलेशन के लिए, ग्राहक उन्हें पॉइसन वितरण के अनुसार भेजता है। परीक्षण स्क्रिप्ट एक थ्रेड में काम करती है, और यदि हम प्रति सेकंड 200 अनुरोधों की गति से अनुरोध भेजते हैं, और सर्वर किसी कारण से 5 सेकंड के लिए रुक जाता है, तो अनुरोध कतार 1000 तक बढ़ जाएगी। दुर्भाग्य से, बहुत सारे लोड परीक्षण अलग-अलग व्यवहार करते हैं, और प्रत्येक इम्यूलेटेड क्लाइंट के लिए एक अलग क्लाइंट स्ट्रीम शुरू करें।

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

विकिपीडिया पर परीक्षण

Zing का परीक्षण करने के लिए, मैंने 2.05.2012 के रूप में अंग्रेजी विकिपीडिया के पूर्ण डेटाबेस को अनुक्रमित किया, जिसमें 33.3 मिलियन दस्तावेजों का प्रतिनिधित्व करते हुए 28.78 जीबी सादे पाठ की मात्रा है, आकार में लगभग 1KB, जिसमें अंतर्निहित फ़ील्ड और टर्म वैक्टर शामिल हैं। इसके लिए धन्यवाद, मैं FastVectorHighlighter वर्ग का उपयोग करके परिणामों को उजागर कर सकता हूं। नतीजतन, 78 जीबी का एक सूचकांक प्राप्त किया गया था। प्रत्येक परीक्षण के लिए, सर्वर पूर्ण सूचकांक को RAMDirectory में लोड करता है, जिसके बाद क्लाइंट 500 सबसे गंभीर लोगों की सूची (दस्तावेजों में सबसे सामान्य शब्द) से अनुरोध भेजता है। इसी समय, सर्वर लगभग 100 दस्तावेजों प्रति सेकंड (~ 100 Kb / s) की गति से दस्तावेजों ( updateDocument ) को पुन: updateDocument ।

प्रत्येक परीक्षण एक घंटे के भीतर किया गया था, वार्मिंग के लिए आवश्यक पहले 5 मिनट को लेखांकन से बाहर रखा गया था। ढेर की अधिकतम मात्रा 140 जीबी ( -Xmx 140G ) थी। प्रदर्शन के एक बुनियादी स्तर के लिए, मैंने MMapDirectory भी परीक्षण किया, जिसकी अधिकतम क्षमता 4 GB है। मशीन में 32 प्रोसेसर कोर (हाइपर-थ्रेडिंग सक्षम के साथ 64) और 512 जीबी रैम है, सर्वर को 40 थ्रेड्स में संचालित करने के लिए कॉन्फ़िगर किया गया है।

मैंने लोड (अनुरोध / सेकंड) के विभिन्न स्तरों का परीक्षण किया, जो 50 (न्यूनतम) से 275 (बहुत बड़े) तक शुरू हुआ, और फिर विभिन्न विन्यासों के लिए प्रतिक्रिया समय के प्रतिशत को दर्शाते हुए रेखांकन किए। डिफ़ॉल्ट रूप से उपयोग किया जाता है, समानांतर ओरेकल जीसी ने बहुत धीरे-धीरे व्यवहार किया (मेमोरी साफ़ करने के लिए सेकंड के दर्जनों), इसलिए मैंने इसे परिणामी रिपोर्ट में शामिल नहीं किया। नई G1 कलेक्टर स्टार्टअप गति पर भी धीमी हो गई है (एक प्रतिस्पर्धी CMS कलेक्टर का उपयोग करते हुए, 900 सेकंड के विपरीत, RAMDirectory में सूचकांक को लोड करने में 6 घंटे का समय लगता है), और ऑपरेशन के दौरान, 100 सेकंड से अधिक के अनुभवी विलंब का अनुरोध करता है, इसलिए यह मैंने रिपोर्ट में परिणामों को भी शामिल नहीं किया (यह एक आश्चर्य था क्योंकि जी 1 बड़े ढेर के साथ काम करने के लिए तैनात है)। इस प्रकार, मैंने तीन कॉन्फ़िगरेशन का परीक्षण किया: सीएमएस, अपनी डिफ़ॉल्ट सेटिंग्स के साथ और MMapDirectory क्लास का उपयोग करते MMapDirectory , बेस स्तर के साथ-साथ सीएमएस और ज़िंग, RAMDirectory क्लास का उपयोग करके।

न्यूनतम भार (50 अनुरोधों / सेकंड) पर, ज़िंग ने अच्छा प्रदर्शन दिखाया, यहां तक ​​कि सबसे खराब मामलों के लिए भी न्यूनतम प्रतिक्रिया समय प्रदान किया, जबकि सीएमएस ने पर्याप्त रूप से बड़ी संख्या में मामलों के लिए काफी लंबी प्रतिक्रिया समय दिखाया, जबकि MMapDirectory का उपयोग करते हुए:



प्रत्येक कॉन्फ़िगरेशन की संतृप्ति सीमा का अनुमान लगाने के लिए, मैंने 99% मामलों के लिए और विभिन्न लोड स्तरों के लिए प्रतिक्रिया समय को दर्शाते हुए एक ग्राफ बनाया है:



इस ग्राफ से यह निष्कर्ष निकाला जा सकता है कि CMS + MMa पी CMS + MMa , शिखर प्रदर्शन 100 और 150 अनुरोधों / सेकंड के बीच कहीं न कहीं गिरता है, जबकि RAMDirectory का उपयोग करते RAMDirectory , यह शिखर 225 और 250 के बीच के स्तर पर कहीं गिरता है अनुरोध / सेकंड। यह एक अद्भुत प्रदर्शन को बढ़ावा देने वाला है! यह परिणाम सभी अधिक दिलचस्प है क्योंकि यदि आप औसत प्रतिक्रिया समय को मापते हैं, तो RAMDirectory और MMapDirectory बीच प्रदर्शन अंतर बहुत कम नजर आता है।

हम उसी ग्राफ का निर्माण करेंगे, लेकिन बिना CMS + MMapDirectory के परिणाम, और 275 अनुरोधों / सेकंड के भार के लिए परिणाम निकालें (क्योंकि यह स्पष्ट रूप से हमारे उपकरणों की क्षमताओं से परे है):



99% प्रतिशत के लिए, Zing का प्रदर्शन स्थिर रहता है, जबकि CMS 100 रिक्वेस्ट / सेकंड के भार के साथ शुरू होने वाले लंबे रिस्पांस टाइम को दिखाना शुरू करता है। आइए 225 अनुरोधों / सेकंड के भार के साथ संकेतक देखें, जो संतृप्ति सीमा के सबसे करीब है और जब सीएमएस और ज़िंग के साथ मिलकर RAMDirectory का उपयोग कर RAMDirectory हैं:



ठहराव पर खर्च किया गया समय पहले से ही 50 अनुरोधों / सेकंड के भार के साथ काफी लंबा है: पहले से ही 95% प्रतिशत के साथ शुरू हो रहा है, प्रतिक्रिया समय बहुत लंबा हो गया है: 4479 एमएस या अधिक।

ज़िंग काम करता है!

इन परीक्षणों से पता चलता है कि ज़िंग कचरा कलेक्टर का उपयोग करते समय, बहुत कम प्रतिक्रिया समय प्राप्त होता है, यहां तक ​​कि चरम भार पर भी, जब एप्लिकेशन को 140 जीबी का ढेर आवंटित किया जाता है, और ल्यूसीन इंडेक्स की क्षमता 78 जीबी होती है और पूरी तरह से RAMDirectory में लोड RAMDirectory । इसके अलावा, आवेदन का प्रदर्शन, प्रति सेकंड अनुरोधों की संख्या में मापा जाता है, यह भी काफी बढ़ जाता है (लगभग दो बार माना जाता है उदाहरण में), और आपको बड़ी अनुक्रमित के लिए भी RAMDirectory उपयोग करने की अनुमति देता है, भले ही वे Zing चला रहे हों।

सबसे विशेष रूप से, अज़ुल ने हाल ही में विकास और परीक्षण में उपयोग के लिए ओपन-सोर्स डेवलपर्स के लिए जेवीएम ज़िंग की उपलब्धता की घोषणा की।