कैसे हम अपने स्वयं के जावा ऑफ-हाइप भंडारण समाधान के साथ जीसी पॉज़ से छुटकारा पा गए

हेलो, हेब्र!

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

चयनित समाधान का औचित्य

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

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

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

कार्यान्वयन

ढेर के बाहर स्मृति के साथ एक जावा अनुप्रयोग का संचार कई तरीकों से लागू किया जा सकता है । एक समय में सहपाठियों ने कक्षा sun.misc.Unsafe के उपयोग के आधार पर एक दृष्टिकोण चुना, जो निजी पैकेज हॉटस्पॉट का हिस्सा है, और अब OpenJDK। यह वर्ग आपको जेएनआई का उपयोग किए बिना, स्पष्ट रूप से मेमोरी के साथ सीधे काम करने की अनुमति देता है, जो हमारे समाधान क्रॉस-प्लेटफ़ॉर्म को छोड़ देता है, और हम मुख्य बायनेरिज़ के साथ-साथ डेवलपर के कंप्यूटर पर भी चल सकते हैं, और यह महत्वपूर्ण नहीं है कि डेवलपर विंडोज के नीचे बैठा है या नहीं। उबंटू या मैक। उदाहरण के लिए, एक जटिल मेमोरी मैनेजमेंट एल्गोरिथ्म न लिखने के लिए, हमने DirectMemory में करने का फैसला किया, प्रत्येक वस्तु के लिए जिसे हम स्टोरेज में रखना चाहते हैं या इससे डिलीट करना चाहते हैं, हम अलग से मेमोरी या फ्री मेमोरी आवंटित करते हैं। ऑपरेटिंग सिस्टम को मेमोरी प्रबंधन से निपटने दें, यह इसे बहुत अच्छी तरह से करता है। इस तथ्य के कारण कि हमें अक्सर स्मृति को आवंटित करने और मुक्त करने की आवश्यकता होती है, हम मानक java.nio.ByteBuffer वर्ग का उपयोग नहीं करते हैं, जो कि JDK का हिस्सा है, एक खुला एपीआई है और ढेर के बाहर स्मृति के साथ काम करने की अनुमति देता है। हमारे मामले में बाइटबफ़र के साथ समस्या यह है कि यह अतिरिक्त कचरा बनाता है और आपको सीधे मुक्त मेमोरी की अनुमति नहीं देता है, लेकिन क्या यह प्रेत लिंक पर आधारित है। उत्तरार्द्ध इस तथ्य की ओर जाता है कि, ढेर के बाहर बहुत सारी मेमोरी आवंटित की गई है, इसे तब तक मुक्त नहीं किया जा सकता है जब तक कि जीसी काम नहीं करता है, भले ही बाइटबफ़र ऑब्जेक्ट जो इस मेमोरी को आवंटित करते हैं, अब उपयोग नहीं किए जाते हैं। हालाँकि एक ध्वज है -XX: MaxDirectMemorySize = इस समस्या को हल करने के लिए, जो कूड़े के संग्रह की शुरुआत करता है जब आवंटित मेमोरी ढेर से बाहर निर्दिष्ट मूल्य तक पहुँचती है, फिर भी बड़ी संख्या में प्रेत लिंक GC को नकारात्मक रूप से प्रभावित कर सकते हैं। बाइटबफ़र का यह व्यवहार इस तथ्य के कारण सबसे अधिक संभावना है कि यह बड़ी मात्रा में स्मृति आवंटित करने और उनका पुन: उपयोग करने के लिए डिज़ाइन किया गया था। हम काम के विपरीत पैटर्न का उपयोग करते हैं। बेशक, बाइटबफर की अस्वीकृति ने हमें अपने दम पर कुछ चीजें करने के लिए बनाया, जैसे कि, उदाहरण के लिए, बाइट ऑर्डर का ख्याल रखना।

एक जिज्ञासु पाठक के पास एक प्रश्न हो सकता है: क्या हम अपनी कार्यक्षमता के लिए निजी हॉटस्पॉट तंत्र (sun.misc.Unsafe) का उपयोग करने में शर्माते नहीं हैं, क्योंकि वे एक ही पल में बदल सकते हैं या गायब हो सकते हैं। नहीं, बिलकुल नहीं। आखिरकार, नए संस्करण का यह वही हॉटस्पॉट हमारे कामकाजी संस्करणों में अप्रत्याशित रूप से नहीं दिखाई देगा, अर्थात्। हम इसके लिए तैयार होंगे। Unsafe से हम जो कुछ भी उपयोग करते हैं वह पहले से ही उल्लेख किए गए बाइटबफ़र का उपयोग करता है। यानी अगर अगले संस्करण में कुछ बदलता है, तो यह हमारे लिए पर्याप्त होगा कि हम स्रोतों पर गौर करें और हमारे ढांचे में, या बल्कि, उसी वर्ग में बदलाव करें, जो स्मृति को आवंटित / मुक्त करने और डेटा की बचत के लिए जिम्मेदार है।

हमारे ढांचे की विशेषताएं

किसी वस्तु को बाइट्स के एक सरणी में क्रमबद्ध करने और ढेर के बाहर डालने के बारे में कुछ भी जटिल नहीं है। Odnoklassniki में हमें और क्या मदद मिल सकती है?

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

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

डेटाबेस के साथ सिंक्रनाइज़ेशन। मामले में जब रिपॉजिटरी डेटाबेस के शीर्ष पर चलती है, तो हम पृष्ठभूमि की प्रक्रिया शुरू करते हैं, जो किसी भी कारण से कैश को दरकिनार करते हुए डेटाबेस में सभी परिवर्तनों को लोड करेगा।

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

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

कमियां और समझौता

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

जैसा कि पहले ही उल्लेख किया गया है, कुछ मौजूदा समाधानों के विपरीत, हम प्रत्येक ऑब्जेक्ट के लिए अलग से मेमोरी आवंटित करते हैं। हालाँकि यह मेमोरी डीफ़्रैग्मेन्टेशन को प्रभावित नहीं कर सकता, लेकिन हमने एक जटिल मेमोरी मैनेजमेंट एल्गोरिथम के बिना किया।

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

सहपाठियों के अंदर उपयोग

ऊपर वर्णित रूपरेखा का उपयोग करते हुए, हम उपयोगकर्ता प्रोफाइल, समूह प्रोफाइल, फोटो मेटा-सूचना, वर्ग सूचना (जैसे), दोस्तों और समूहों के संबंध में उपयोगकर्ता कार्यों के आंकड़े, टेप के टुकड़े और कुछ और स्टोर करते हैं। उदाहरण के लिए, एक वितरित आँकड़ों की दुकान, जिसके आधार पर उपयोगकर्ताओं के फीड में आने की गणना की जाती है, जिसमें लगभग 300GB डेटा होता है। एक बॉक्स पर स्टोरेज मेमोरी में डेटा का अधिकतम आकार 90 जीबी तक पहुंच जाता है। चोटी पर प्रत्येक में 4 कोर के साथ लोहे के 2-प्रोसेसर के टुकड़े पर औसत भार लगभग 20K अनुरोध प्रति सेकंड है।

यह ध्यान देने योग्य है कि किसी भी तरह से हमारी रिपॉजिटरी हमें RDBMS या NoSQL समाधान की तरह कुछ के लिए एक प्रतिस्थापन के रूप में कार्य करती है। अधिक बार, हम इसे डेटाबेस के लिए कैश के रूप में उपयोग करते हैं। शायद उपयोग के कुछ स्थानों में, हम मौजूदा कैश प्लस RDBMS बंडल के बजाय NoSQL पर स्विच कर सकते हैं, लेकिन इसके लिए व्यवसाय तर्क का एक मजबूत संशोधन आवश्यक है, जो RDBMS द्वारा प्रदान की गई लेन-देन पर भरोसा कर सकता है।

इस प्रकार, वर्णित रूपरेखा हमें जावा में सभी कोड लिखने, ढेर में डेटा की मात्रा को संग्रहीत करने की अनुमति देती है, जिसमें कार्य की आवश्यकता होती है, जीसी सेटिंग्स के साथ सिरदर्द नहीं होता है, और नए डेटा के भंडारण या कैशिंग को जल्दी से लागू करता है।

ढेर के बड़े संस्करणों पर जीसी पॉज़ की समस्याओं को हल करने में आपके अनुभव के बारे में सीखना हमारे लिए भी बहुत दिलचस्प होगा।