जेवीएम मेमोरी आवंटन

सभी को नमस्कार! हम जावा डेवलपर पाठ्यक्रम में एक नए थ्रेड के लॉन्च के साथ आज की सामग्री के अनुवाद को संयोग करना चाहते हैं, जो कल से शुरू होता है। खैर, शुरू करते हैं।

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



दो तरह की मेमोरी

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

आउट-ऑफ-हीप मेमोरी कई क्षेत्रों में विभाजित है। हॉटस्पॉट में, आप इस मेमोरी के क्षेत्रों का पता लगाने के लिए नेटिव मेमोरी ट्रैकिंग (NMT) तंत्र का उपयोग कर सकते हैं। कृपया ध्यान दें कि यद्यपि NMT सभी मूल मेमोरी के उपयोग को ट्रैक नहीं करता है ( उदाहरण के लिए, तृतीय-पक्ष कोड द्वारा देशी मेमोरी के आवंटन की निगरानी नहीं की जाती है ), इसकी क्षमताएं अधिकांश विशिष्ट स्प्रिंग अनुप्रयोगों के लिए पर्याप्त हैं। NMT का उपयोग करने के लिए, एप्लिकेशन को -XX:NativeMemoryTracking=summary साथ -XX:NativeMemoryTracking=summary और उपयोग करना jcmd VM.native_memory सारांश उपयोग की गई मेमोरी के बारे में जानकारी देखें।

आइए NMT का उपयोग अपने पुराने मित्र पेटक्लिनिक से एक उदाहरण के रूप में देखें । नीचे दिए गए आरेख में एनएमटी डेटा के अनुसार जेवीएम मेमोरी का उपयोग दिखाया गया है (पेटीएमिक को शून्य से 48 -Xmx48M ( -Xmx48M ) अधिकतम आकार के साथ पेटक्लिनिक शुरू करते समय:



जैसा कि आप देख सकते हैं, जेवीएम की अधिकांश मेमोरी के लिए ढेर के बाहर की मेमोरी का उपयोग किया गया है, और हीप मेमोरी कुल का केवल एक छठा है। इस मामले में, यह लगभग 44 एमबी है (जिसमें से 33 एमबी का उपयोग कचरा संग्रहण के तुरंत बाद किया गया था)। ढेर स्मृति उपयोग में से कुल 223 एमबी है।

देशी स्मृति के क्षेत्र

कम्प्रेस्ड क्लास स्पेस : लोडेड क्लासेस के बारे में जानकारी स्टोर करने के लिए इस्तेमाल किया जाता है। MaxMetaspaceSize पैरामीटर तक सीमित। लोड की गई कक्षाओं की संख्या का एक फ़ंक्शन।

अनुवादक का नोट

किसी कारण से, लेखक कम्प्रेस्ड क्लास स्पेस के बारे में लिखता है, न कि पूरे क्लास एरिया के बारे में। कम्प्रेस्ड क्लास स्पेस एरिया क्लास एरिया का हिस्सा है, और MaxMetaspaceSize पैरामीटर कंप्रेस्ड क्लास स्पेस ही नहीं, बल्कि पूरे क्लास एरिया के साइज को सीमित करता है। "संपीड़ित वर्ग स्थान" को सीमित करने के लिए, CompressedClassSpaceSize पैरामीटर का उपयोग किया जाता है।

यहाँ से :
यदि UseCompressedOops चालू है और UseCompressedClassesPointers का उपयोग किया जाता है, तो कक्षा मेटाडेटा के लिए मूल स्मृति के दो अलग-अलग क्षेत्रों का उपयोग किया जाता है ...
इन संपीड़ित वर्ग पॉइंटर्स (32-बिट ऑफ़सेट) के लिए एक क्षेत्र आवंटित किया जाता है। इस क्षेत्र का आकार CompressedClassSpaceSize साथ सेट किया जा सकता है और डिफ़ॉल्ट रूप से 1 गीगाबाइट (GB) है ...
MaxMetaspaceSize प्रतिबद्ध संपीड़ित वर्ग स्थान और अन्य वर्ग मेटाडेटा के लिए स्थान के योग पर लागू होता है

यदि UseCompressedOops पैरामीटर UseCompressedOops और UseCompressedOops उपयोग किया जाता है, तो कक्षा मेटाडेटा के लिए मूल रूप से मेमोरी के दो अलग-अलग क्षेत्रों का उपयोग किया जाता है ...

संपीड़ित बिंदुओं के लिए, एक मेमोरी क्षेत्र आवंटित किया जाता है (32-बिट ऑफ़सेट)। इस क्षेत्र का आकार CompressedClassSpaceSize द्वारा निर्धारित किया जा सकता है और डिफ़ॉल्ट रूप से यह 1 जीबी है ...
MaxMetaspaceSize पैरामीटर संपीड़ित पॉइंटर क्षेत्र और अन्य वर्ग मेटाडेटा के क्षेत्र के योग को संदर्भित करता है।

• थ्रेड: JVM में थ्रेड द्वारा उपयोग की जाने वाली मेमोरी। रनिंग थ्रेड्स की संख्या का कार्य।
• कोड कैश: इसे चलाने के लिए JIT द्वारा उपयोग की जाने वाली मेमोरी। लोड की गई कक्षाओं की संख्या का एक फ़ंक्शन। लिमिटेड को ReservedCodeCacheSize । उदाहरण के लिए, tiered संकलन को अक्षम करके आप JIT की सेटिंग को कम कर सकते हैं।
• GC (कचरा संग्राहक): कचरा संग्राहक द्वारा उपयोग किए जाने वाले डेटा को संग्रहीत करता है। उपयोग किए गए कचरा कलेक्टर पर निर्भर करता है।
• प्रतीक: फ़ील्ड नाम, विधि हस्ताक्षर और इंटर्न स्ट्रिंग्स जैसे वर्ण संग्रहीत करता है। चरित्र स्मृति का अत्यधिक उपयोग यह संकेत दे सकता है कि लाइनें बहुत अधिक आंतरिक हैं।
• आंतरिक: अन्य आंतरिक डेटा को संग्रहीत करता है जो अन्य क्षेत्रों में शामिल नहीं है।

मतभेद

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

JVM को कॉन्फ़िगर करें

उपलब्ध रैम का कुशलता से उपयोग करने के लिए जेवीएम को कॉन्फ़िगर करना आसान नहीं है। यदि आप JVM को -Xmx16M पैरामीटर के साथ -Xmx16M हैं और 16 एमबी से अधिक मेमोरी का उपयोग करने की अपेक्षा करते हैं, तो आपको एक अप्रिय आश्चर्य मिलेगा।

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

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

सौभाग्य से, CloudFoundry टीम को JVM में मेमोरी आवंटन का व्यापक ज्ञान है। यदि आप CloudFoundry में एप्लिकेशन डाउनलोड करते हैं, तो बिल्ड पैक स्वचालित रूप से आपके लिए यह ज्ञान लागू करेगा। यदि आप CloudFoudry का उपयोग नहीं कर रहे हैं या JVM को कॉन्फ़िगर करने के तरीके के बारे में अधिक समझना चाहते हैं, तो जावा बिल्डपैक के मेमोरी कैलकुलेटर के तीसरे संस्करण के विवरण को पढ़ने की सिफारिश की जाती है ।

वसंत के लिए इसका क्या मतलब है

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

परंपरागत रूप से, हम सामग्री पर आपकी टिप्पणियों की प्रतीक्षा कर रहे हैं।