एक परियोजना के उदाहरण पर ट्यूनिंग जेवीएम

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

परियोजना का इतिहास

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

डेटा की एक बड़ी मात्रा को संसाधित करने की समस्याओं को आमतौर पर दो प्रसिद्ध प्रकार के स्केलिंग द्वारा हल किया जाता है: ऊर्ध्वाधर और क्षैतिज। ऊर्ध्वाधर के साथ, सब कुछ यथोचित स्वीकार्य था। हमारे पास हमारे निपटान में 16 कोर के साथ एक मशीन थी, जिसमें 16 जीबी रैम, रेड हैट और जावा 1.6 थे। ऐसे हार्डवेयर पर काफी अच्छी तरह से घूमना संभव था, जो कि वास्तव में, हमने कई महीनों तक सफलतापूर्वक किया है।

सब कुछ तब तक सही था जब तक कि ग्राहक ने हमारे सामने दस्तक नहीं दी और कहा कि आईटी बुनियादी ढांचे को संशोधित किया गया था और 16x16 के बजाय हमारे पास 4x1% है:

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

पहले प्रयास

सबसे पहले, मैं समझाता हूं कि मूल्य-पर-जोखिम कैलकुलेटर क्या है। यह एक "सरल" गणना के साथ एक कार्यक्रम है, जो बड़ी मात्रा में डेटा से गुजर रहा है।

अनुकूलन कुंजी जो सबसे उपयोगी थीं:

• -सर्वर एक अत्यंत उपयोगी कुंजी है, जेवीएम लूप का विस्तार करता है, कई कार्यों को रेखांकित करता है, आदि।
• स्ट्रिंग्स के साथ काम करें: -XX: + UseCompressedStrings, -XX: + UseStringCache, -XX: + OptimizeStringConcat

स्वाभाविक रूप से, इस तरह के एक सरल चाल ने वांछित परिणाम नहीं दिए, और हमने आवेदन को "सिकुड़ने" की आगे की संभावनाओं की दिशा में खोदना जारी रखा। पहली चीज जो करने का फैसला किया गया था, वह अनावश्यक कैश को हटाने और मौजूदा लोगों को अनुकूलित करने का था (जो कि 80 में से प्रदर्शन में 20% वृद्धि देते हैं)। अनावश्यक लोगों को जल्दी से हटा दिया गया था, और शेष लोगों पर काम करने के लिए, हमने जावा में विभिन्न प्रकार के लिंक को देखने का फैसला किया।

तो, हमारे पास निम्न लिंक प्रकार उपलब्ध हैं:

• कठोर / मजबूत
• मुलायम
• कमज़ोर
• प्रेत

उनके बीच निर्भरताएं कुछ इस तरह दिखती हैं:


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

हार्ड और फैंटम लिंक को इस तथ्य के कारण तुरंत हमारे विचार से हटा दिया गया था कि वे आवश्यक कार्यक्षमता और लचीलापन प्रदान नहीं करते हैं। सही समय पर हार्ड डिलीट नहीं किए जाते हैं, लेकिन फाइल सिस्टम के साथ सब कुछ क्रम में था।

उदाहरण के लिए, कमजोर लिंक कैसे इकट्ठा होते हैं, इस पर विचार करें:


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

परिणाम महत्वपूर्ण थे, लेकिन आवेदन 4GB प्रतिष्ठित में काम नहीं किया।

विस्तृत अध्ययन

विभिन्न प्रोफाइलिंग टूल्स का उपयोग करके आगे अनुसंधान किया गया:

• मानक JVM उपकरण: -XX: + PrintGCDetails, -XX: + PrintGC, -XX: PrintReetGC, आदि
• MXBean
• VisualVM

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

सबसे पहले, उत्पन्न वस्तुओं की संख्या को कम करना आवश्यक था। यह नोट किया गया था कि अधिकांश डेटा में एक समान संरचना है: "XXX1: XXX2: XXX3 और इसी तरह।" "XXX" प्रकार के सभी पैटर्न को पूल से वस्तुओं के संदर्भों द्वारा प्रतिस्थापित किया गया था, जिसके परिणामस्वरूप निर्मित वस्तुओं (लगभग पांच बार) की संख्या में उल्लेखनीय कमी आई, और अतिरिक्त मात्रा में कीमती मेमोरी को मुक्त कर दिया।

दूसरे, हमने कचरा संग्रहण रणनीतियों के साथ अधिक विस्तार से काम करने का फैसला किया। जैसा कि हम जानते हैं, हमारे पास निम्नलिखित कचरा संग्रह रणनीतियाँ उपलब्ध हैं:

• धारावाहिक
• समानांतर
• समानांतर कॉम्पैक्टिंग
• समवर्ती चिह्न-झाडू
• जी 1 कलेक्टर

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

समानांतर कॉम्पैक्टिंग और समवर्ती मार्क-स्वीप कलेक्टरों की तुलना करने के बाद, इसे दूसरे पर रोकने का फैसला किया गया, जो एक अच्छा समाधान निकला।

उपरोक्त सभी तकनीकों का एक मुकाबला परीक्षण करने के बाद, एप्लिकेशन नई आवश्यकताओं के साथ पूरी तरह से अनुकूल हो गया है और उत्पादन में सफलतापूर्वक लॉन्च किया गया है! सभी ने राहत की सांस ली!

सबक सीखा

• स्ट्रिंग्स के साथ काम करने की कुंजी ने मदद की: -XX: + UseCompressedStrings, -XX: + UseStringCache, -XX: + OptimizeStringConcat और स्ट्रिंग डेटा की बहुत बारीकियों
• प्रयुक्त वस्तुओं की संख्या को कम करना
• जेवीएम को फाइन-ट्यूनिंग करने में बहुत समय लगता है, लेकिन परिणाम उचित से अधिक हैं
• जितनी जल्दी हो सके अपनी आवश्यकताओं को जान लें! :)

समस्या का एक और अधिक विस्तृत संस्करण और समाधान के चरणों को आगामी JPoint सम्मेलन में सुना जा सकता है, जो सेंट पीटर्सबर्ग में आयोजित किया जाएगा।