हमने डॉकर में जावा का शोषण करना कैसे सीखा

हुड के तहत, hh.ru में बड़ी संख्या में जावा सेवाएँ हैं जो डॉकटर कंटेनरों में चल रही हैं। उनके संचालन के दौरान, हमें बहुत सी गैर-तुच्छ समस्याओं का सामना करना पड़ा। कई मामलों में, समाधान की तह तक जाने के लिए, मुझे लंबे समय तक Google करना पड़ा, OpenJDK स्रोतों को पढ़ा और यहां तक ​​कि उत्पादन पर सेवाओं को भी प्रोफाइल किया। इस लेख में मैं इस प्रक्रिया में प्राप्त ज्ञान के बारे में बताने की कोशिश करूंगा।

• सीपीयू की सीमा
• डॉकर और सर्वर क्लास मशीन
• सीपीयू सीमा (हाँ, फिर से) और मेमोरी विखंडन
• हम Java-OOM प्रोसेस करते हैं
• स्मृति की खपत का अनुकूलन
• मेमोरी की खपत को सीमित करना: हीप, नॉन-हीप, डायरेक्ट मेमोरी
• मेमोरी की खपत को सीमित करना: नेटिव मेमोरी ट्रैकिंग
• जावा और ड्राइव
• हर चीज पर नज़र कैसे रखें?

सीपीयू की सीमा

हम सीपीयू और मेमोरी सीमाओं के साथ kvm आभासी मशीनों में रहते थे और, डॉकर में जाकर, cgroups में समान प्रतिबंध लगाते थे। और पहली समस्या जिसका हमें सामना करना पड़ा, वह ठीक सीपीयू की सीमा थी। मुझे तुरंत यह कहना होगा कि यह समस्या जावा 8 और जावा of 10. के हाल के संस्करणों के लिए प्रासंगिक नहीं है। यदि आप समय रहते हैं, तो आप सुरक्षित रूप से इस अनुभाग को छोड़ सकते हैं।

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

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

सबसे पहले, जैसे ही यह समस्या सामने आई, हमने निम्नलिखित काम के दौर का उपयोग करने की कोशिश की:
- कुछ सेवाओं का उपयोग करने की कोशिश की libnumcpus - एक पुस्तकालय जो आपको उपलब्ध प्रोसेसर की एक अलग संख्या निर्धारित करके "ट्रिक" जावा की अनुमति देता है;
- स्पष्ट रूप से जीसी थ्रेड्स की संख्या का संकेत दिया गया है,
- प्रत्यक्ष बाइट बफ़र्स के उपयोग पर स्पष्ट रूप से सीमा निर्धारित करें।

लेकिन, ज़ाहिर है, ऐसी बैसाखियों के साथ घूमना बहुत सुविधाजनक नहीं है, और जावा 10 (और फिर जावा 11) की चाल, जिसमें ये सभी समस्याएं अनुपस्थित हैं , एक वास्तविक समाधान था। निष्पक्षता में, यह कहने योग्य है कि आठ में भी, अक्टूबर 198 में जारी 191 अपडेट के साथ सब कुछ ठीक था। उस समय तक यह हमारे लिए पहले से ही अप्रासंगिक था, जिसकी मैं आपके लिए भी कामना करता हूं।

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

डॉकर और सर्वर क्लास मशीन

तो, जावा 10 में, -XX:ActiveProcessorCount और -XX:+UseContainerSupport विकल्प दिखाई दिए (और जावा 8 को -XX:+UseContainerSupport दिए गए), डिफ़ॉल्ट cgroups सीमा को ध्यान में रखते हुए। अब सब कुछ अद्भुत था। या नहीं?

जावा 10/11 में स्थानांतरित होने के कुछ समय बाद, हमने कुछ विषमताओं को नोटिस करना शुरू किया। किसी कारण से, कुछ सेवाओं में, GC ग्राफिक्स ऐसे दिखते थे जैसे वे G1 का उपयोग नहीं करते हैं:



यह, इसे मामूली रूप से रखना, थोड़ा अप्रत्याशित था, क्योंकि हम यह सुनिश्चित करने के लिए जानते थे कि G1 डिफ़ॉल्ट कलेक्टर है, जावा 9 से शुरू होता है। साथ ही, कुछ सेवाओं में ऐसी कोई समस्या नहीं है - G1 चालू है, जैसा कि अपेक्षित था।

हम एक दिलचस्प चीज को समझना और ठोकर खाना शुरू करते हैं। यह पता चला है कि यदि जावा 3 से कम प्रोसेसर और 2 जीबी से कम की मेमोरी सीमा के साथ चल रहा है, तो यह अपने आप को ग्राहक मानता है और SerialGC के अलावा कुछ भी उपयोग करने की अनुमति नहीं देता है।

वैसे, यह केवल जीसी की पसंद को प्रभावित करता है और इसका -क्लाइंट / -सर्वर और जेआईटी संकलन विकल्पों के साथ कोई लेना-देना नहीं है।

जाहिर है, जब हमने जावा 8 का उपयोग किया था, तो यह डॉकटर सीमा को ध्यान में नहीं रखता था और सोचा था कि इसमें बहुत सारे प्रोसेसर और मेमोरी हैं। जावा 10 में अपग्रेड करने के बाद, सीमाएं कम करने वाली कई सेवाएं अचानक ही सीरियलियल का उपयोग करने लगीं। सौभाग्य से, यह बहुत सरलता से व्यवहार किया जाता है - स्पष्ट रूप से -XX:+AlwaysActAsServerClassMachine सेट -XX:+AlwaysActAsServerClassMachine ।

सीपीयू सीमा (हाँ, फिर से) और मेमोरी विखंडन

निगरानी में रेखांकन को देखते हुए, हमने किसी तरह देखा कि कंटेनर का निवासी सेट आकार बहुत बड़ा है - अधिकतम कूल्हे के आकार का तीन गुना जितना। क्या यह कुछ अगले मुश्किल तंत्र में हो सकता है जो सिस्टम में प्रोसेसर की संख्या के अनुसार मापता है और डॉकटर की सीमाओं के बारे में नहीं जानता है?

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

64-बिट सिस्टम पर, एरेनास की डिफ़ॉल्ट संख्या 8 * सीपीयू की संख्या पर सेट है। जाहिर है, यह हमारे लिए बहुत बड़ा उपरि है, क्योंकि सभी सीपीयू कंटेनर के लिए उपलब्ध नहीं हैं। इसके अलावा, जावा-आधारित अनुप्रयोगों के लिए, एरेनास के लिए प्रतियोगिता इतनी प्रासंगिक नहीं है, क्योंकि अधिकांश आवंटन जावा-हीप में किए जाते हैं, जिसके लिए मेमोरी पूरी तरह से स्टार्टअप पर आवंटित की जा सकती है।

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



RSS चार्ट पर दो उदाहरण हैं: एक (नीला) में हम MALLOC_ARENA_MAX चालू करते हैं, दूसरा (लाल) हम बस पुनः आरंभ करते हैं। अंतर स्पष्ट है।

लेकिन उसके बाद, यह पता लगाने की एक उचित इच्छा है कि जावा आम तौर पर स्मृति पर क्या खर्च करता है। क्या 300-400 मेगाबाइट की मेमोरी सीमा के साथ जावा पर एक माइक्रो-सर्विस चलाना संभव है और यह डर नहीं है कि यह जावा-ओओएम से गिर जाएगा या सिस्टम ओओएम हत्यारे द्वारा नहीं मारा जाएगा?

हम Java-OOM प्रोसेस करते हैं

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

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

इसलिए, हम इस विकल्प पर आए:

-XX:+HeapDumpOnOutOfMemoryError
-XX:+ExitOnOutOfMemoryError
-XX:HeapDumpPath=/var/crash/java.hprof
-XX:OnOutOfMemoryError="mv /var/crash/java.hprof /var/crash/heapdump.hprof"

यह काफी सरल है और कुछ सुधारों के साथ आप इसे न केवल नवीनतम हिप-डंप स्टोर करना सिखा सकते हैं, बल्कि हमारी जरूरतों के लिए यह पर्याप्त से अधिक है।

जावा ओओएम केवल एक चीज नहीं है जिसका हमें सामना करना है। प्रत्येक कंटेनर में मेमोरी की एक सीमा होती है जो वह व्याप्त होता है, और इसे पार किया जा सकता है। यदि ऐसा होता है, तो कंटेनर को restart_policy: always किलर सिस्टम द्वारा मार दिया जाता है और पुनरारंभ होता है (हम पुनरारंभ_पॉलिसी का उपयोग restart_policy: always )। स्वाभाविक रूप से, यह अवांछनीय है, और हम सीखना चाहते हैं कि जेवीएम द्वारा उपयोग किए जाने वाले संसाधनों पर सीमाएं कैसे सही ढंग से निर्धारित की जाएं।

स्मृति की खपत का अनुकूलन

लेकिन सीमा निर्धारित करने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि जेवीएम संसाधनों को बर्बाद नहीं कर रहा है। हम पहले से ही CPU और चर MALLOC_ARENA_MAX की संख्या पर एक सीमा का उपयोग करके मेमोरी खपत को कम करने में कामयाब रहे हैं। क्या ऐसा करने के लिए कोई अन्य "लगभग मुफ्त" तरीके हैं?

यह पता चला है कि कुछ और चालें हैं जो थोड़ी याददाश्त को बचाएंगी।

पहला -Xss (or -XX:ThreadStackSize ) -XX:ThreadStackSize , जो थ्रेड्स के लिए स्टैक आकार को नियंत्रित करता है। 64-बिट JVM के लिए डिफ़ॉल्ट 1 MB है। हमें पता चला कि 512 केबी हमारे लिए पर्याप्त है। इस वजह से, एक StackOverflowException पहले कभी नहीं पकड़ा गया है, लेकिन मैं मानता हूं कि यह सभी के लिए उपयुक्त नहीं है। और इससे होने वाला लाभ बहुत कम है।

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

और अंत में, एक विधि जो सभी के लिए उपयुक्त नहीं है (लेकिन यह हमारे लिए उपयुक्त है) देशी मॉलॉक के बजाय जेमलॉक का उपयोग करना है। यह कार्यान्वयन ग्लिबेक से मॉलॉक की तुलना में स्मृति विखंडन और बेहतर मल्टीथ्रेडिंग समर्थन को कम करने की दिशा में सक्षम है। हमारी सेवाओं के लिए, जेमॉलॉक ने प्रदर्शन को प्रभावित किए बिना MALLOC_ARENA_MAX=4 साथ मॉलॉक की तुलना में थोड़ा अधिक मेमोरी लाभ दिया।

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

इस बीच, चलिए अगले विषय पर चलते हैं और अंत में, यह जानने की कोशिश करते हैं कि मेमोरी की खपत कैसे सीमित करें और सही सीमा का चयन करें।

मेमोरी की खपत को सीमित करना: हीप, नॉन-हीप, डायरेक्ट मेमोरी

सब कुछ सही करने के लिए, आपको याद रखना होगा कि जावा में सामान्य रूप से कौन सी मेमोरी होती है। पहले, आइए उन पूलों को देखें जिनकी स्थिति पर जेएमएक्स के माध्यम से नजर रखी जा सकती है।

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

उसी समय -Xms == -Xmx रूप में हम सेट -Xms == -Xmx । हमारे पास मेमोरी ओवरसेलिंग नहीं है, इसलिए यह हमारे हितों में है कि सेवा उन संसाधनों का उपयोग करती है जो हमने इसे अधिकतम दिया था। इसके अलावा, साधारण सेवाओं में हम शामिल हैं -XX:+AlwaysPreTouch और पारदर्शी विशाल पृष्ठ तंत्र: -XX:+UseTransparentHugePages -XX:+UseLargePagesInMetaspace । हालांकि, THP को सक्षम करने से पहले, ध्यान से प्रलेखन पढ़ें और परीक्षण करें कि सेवाएं लंबे समय तक इस विकल्प के साथ कैसे व्यवहार करती हैं। अपर्याप्त रैम के साथ मशीनों पर आश्चर्य से इनकार नहीं किया जाता है (उदाहरण के लिए, हमें परीक्षण बेंच पर टीएचपी को बंद करना पड़ा)।

अगला गैर-ढेर है । गैर-हीप मेमोरी में शामिल हैं:
- मेटास्पैस और कम्प्रेस्ड क्लास स्पेस,
- कोड कैश।

क्रम में इन पूलों पर विचार करें।

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

संपीड़ित क्लास स्पेस , मेटास्पैस का हिस्सा है और तब दिखाई देता है जब -XX:+UseCompressedClassPointers विकल्प सक्षम होता है (32 जीबी से कम के लिए डिफ़ॉल्ट रूप से सक्षम होता है, यानी जब यह वास्तविक मेमोरी गेन दे सकता है)। इस पूल का आकार -XX:CompressedClassSpaceSize विकल्प द्वारा सीमित किया जा सकता है, लेकिन इसमें बहुत अधिक समझदारी नहीं है, क्योंकि Compressed Class Space Metaspace में शामिल है और Metaspace और Compass क्लास स्पेस के लिए लॉक मेमोरी की कुल मात्रा अंततः एक -XX:MaxMetaspaceSize तक सीमित है -XX:MaxMetaspaceSize ।

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

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

यह महत्वपूर्ण है कि यहां गलती न करें, क्योंकि अपर्याप्त कोड कैश कैश से ठंडा और पुराना कोड हटा देता है ( -XX:+UseCodeCacheFlushing डिफ़ॉल्ट रूप -XX:+UseCodeCacheFlushing सक्षम है), और यह बदले में, सीपीयू की खपत और प्रदर्शन में गिरावट का कारण बन सकता है। । यह बहुत अच्छा होगा यदि आप कोड कैश को ओवरफ्लो होने पर OOM फेंक सकते हैं, इसके लिए भी -XX:+ExitOnFullCodeCache , लेकिन, दुर्भाग्य से, यह केवल JVM के विकास संस्करण में उपलब्ध है।

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

तो अब तक हमें क्या मिला?

  जावा प्रक्रिया मेमोरी = 
     हीप + मेटस्पेस + कोड कैश + डायरेक्ट मेमोरी =
         -एक्सएमएक्स +
         -एक्सएक्स: मैक्समैटेसैसेज़ +
         -XX: आरक्षितकोडचैकेज +
         -XX: MaxDirectMemorySize 

आइए चार्ट पर सब कुछ खींचने की कोशिश करें और इसकी तुलना आरएसएस डॉकटर कंटेनर से करें।



ऊपर की पंक्ति कंटेनर का आरएसएस है और यह जेवीएम की मेमोरी खपत से डेढ़ गुना अधिक है, जिसे हम जेएमएक्स के माध्यम से मॉनिटर कर सकते हैं।

आगे की खुदाई!

मेमोरी की खपत को सीमित करना: नेटिव मेमोरी ट्रैकिंग

बेशक, ढेर, गैर-ढेर और प्रत्यक्ष मेमोरी के अलावा, जेवीएम अन्य मेमोरी पूल का एक पूरा गुच्छा उपयोग करता है। -XX:NativeMemoryTracking=summary ध्वज हमें उनसे -XX:NativeMemoryTracking=summary मदद करेगा -XX:NativeMemoryTracking=summary । इस विकल्प को सक्षम करके, हम JVM को ज्ञात पूलों के बारे में जानकारी प्राप्त करने में सक्षम होंगे, लेकिन JMX में उपलब्ध नहीं हैं। आप दस्तावेज़ में इस विकल्प का उपयोग करने के बारे में अधिक पढ़ सकते हैं।

आइए सबसे स्पष्ट से शुरू करें - थ्रेड के ढेर द्वारा कब्जा की गई स्मृति। हमारी सेवा के लिए NMT कुछ इस तरह का उत्पादन करता है:

  थ्रेड (आरक्षित = 32166KB, प्रतिबद्ध = 5358KB)
     (धागा # 52)
     (स्टैक: आरक्षित = 31920KB, प्रतिबद्ध = 5112KB)
     (मॉलोक = 185KB # 270) 
     (अखाड़ा = ६१ केबी # १०२) 

वैसे, इसका आकार नेटिव मेमोरी ट्रैकिंग के बिना भी पाया जा सकता है, jstack का उपयोग करके और /proc/<pid>/smaps में थोड़ा /proc/<pid>/smaps । एंड्री पैंगिन ने इसके लिए एक विशेष उपयोगिता रखी।

साझा क्लास स्पेस का आकार मूल्यांकन करना और भी आसान है:

  साझा वर्ग स्थान (आरक्षित = 17084KB, प्रतिबद्ध = 17084KB)
     (mmap: आरक्षित = 17084KB, प्रतिबद्ध = 17084KB) 

यह क्लास डेटा शेयरिंग तंत्र है, -Xshare और -XX:+UseAppCDS -Xshare । जावा 11 में, -Xshare विकल्प को डिफ़ॉल्ट रूप से ऑटो पर सेट किया जाता है, जिसका अर्थ है कि अगर आपके पास $JAVA_HOME/lib/server/classes.jsa (यह आधिकारिक OpenJDK docker छवि में है), यह मेमोरी मैप को लोड करेगा- JVM के स्टार्टअप पर ओम, स्टार्टअप के समय में तेजी। तदनुसार, साझा वर्ग स्थान का आकार यह निर्धारित करना आसान है कि क्या आप जेएसए-अभिलेखागार के आकार को जानते हैं।

देशी कचरा कलेक्टर संरचना निम्नलिखित हैं:

  जीसी (आरक्षित = 42137KB, प्रतिबद्ध = 41801KB)
     (मालोक = 5705KB # 9460) 
     (मिमीप: आरक्षित = 36432KB, प्रतिबद्ध = 36096KB) 

नेटिव मेमोरी ट्रैकिंग पर पहले से बताए गए मैनुअल में एलेक्सी शिपिलेव का कहना है कि वे ढेर के आकार के लगभग 4-5% हिस्से पर कब्जा कर लेते हैं, लेकिन छोटे ढेर के लिए हमारे सेटअप में (कई सौ मेगाबाइट तक) ओवरहेड ढेर के आकार का 50% तक पहुंच गया।

बहुत सारे स्थान पर प्रतीक तालिकाओं द्वारा कब्जा किया जा सकता है:

  प्रतीक (आरक्षित = 16421KB, प्रतिबद्ध = 16421KB)
     (मालॉक = 15261KB # 203089) 
     (अखाड़ा = 1159 केबी # 1) 

वे विधियों, हस्ताक्षरों के नाम, साथ ही साथ आंतरिक तार के लिंक संग्रहीत करते हैं। दुर्भाग्य से, यह संभव है कि प्रतीक तालिका के आकार का अनुमान केवल मूल मेमोरी ट्रैकिंग का उपयोग करके पोस्ट फैक्टम द्वारा किया जाए।

क्या बचा है? नेटिव मेमोरी ट्रैकिंग के अनुसार, बहुत सारी चीजें:

  संकलक (आरक्षित = 509KB, प्रतिबद्ध = 509KB)
 आंतरिक (आरक्षित = 1647KB, प्रतिबद्ध = 1647KB)
 अन्य (आरक्षित = 2110KB, प्रतिबद्ध = 2110KB)
 एरिना चंक (आरक्षित = 1712KB, प्रतिबद्ध = 1712KB)
 लॉगिंग (आरक्षित = 6KB, प्रतिबद्ध = 6KB)
 तर्क (आरक्षित = 19KB, प्रतिबद्ध = 19KB)
 मॉड्यूल (आरक्षित = 227KB, प्रतिबद्ध = 227KB)
 अज्ञात (आरक्षित = 32KB, प्रतिबद्ध = 32KB) 

लेकिन यह सब काफी जगह लेता है।

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

फिर भी, रुचि के लिए, आइए ग्राफ़ पर उस सब कुछ को प्रतिबिंबित करने का प्रयास करें जो मूल मेमोरी ट्रैकिंग रिपोर्ट:



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

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

सीपीयू और मेमोरी से निपटने के बाद, हम अगले संसाधन पर जाते हैं जिसके लिए एप्लिकेशन प्रतिस्पर्धा कर सकते हैं - डिस्क को।

जावा और ड्राइव

और उनके साथ, सब कुछ बहुत खराब है: वे धीमे हैं और आवेदन की मूर्त मंदता को जन्म दे सकते हैं। इसलिए, हम जावा को यथासंभव डिस्क से हटाते हैं:

• हम UDP के माध्यम से स्थानीय syslog में सभी एप्लिकेशन लॉग लिखते हैं। यह कुछ मौका छोड़ता है कि आवश्यक लॉग रास्ते में कहीं खो जाएंगे, लेकिन, जैसा कि अभ्यास से पता चला है, ऐसे मामले बहुत दुर्लभ हैं।
• हम जेवीएम लॉग को tmpfs में लिखेंगे, इसके लिए हमें डॉकटर को /dev/shm साथ वांछित स्थान पर माउंट करने की आवश्यकता है।

यदि हम syslog या tmpfs में लॉग लिखते हैं, और एप्लिकेशन स्वयं डिस्क पर हिप-डंप के अलावा कुछ नहीं लिखता है, तो यह पता चलता है कि डिस्क के इतिहास को इस पर बंद माना जा सकता है?

बिल्कुल नहीं।

हम स्टॉप-द-वर्ल्ड पॉज़ की अवधि के ग्राफ पर ध्यान देते हैं और हम एक उदास तस्वीर देखते हैं - होस्ट पर स्टॉप-द-वर्ल्ड-पॉज़ेस सैकड़ों मिलीसेकंड हैं, और एक मेजबान पर वे एक सेकंड तक पहुंच सकते हैं:



यह कहने की आवश्यकता नहीं है कि यह आवेदन को नकारात्मक रूप से प्रभावित करता है? यहाँ, उदाहरण के लिए, एक ग्राफ है जो ग्राहकों के अनुसार सेवा के प्रतिक्रिया समय को दर्शाता है:



कैश्ड रिस्पॉन्स देने वाले अधिकांश भाग के लिए यह एक बहुत ही सरल सेवा है, इसलिए 95 प्रतिशत प्रतिशत के साथ शुरू होने वाले ऐसे निषेधात्मक समय कहां से हैं? अन्य सेवाओं में एक समान तस्वीर है, इसके अलावा, समय-समय पर एविएबल कॉन्स्टेंसी के साथ बारिश हो रही है जब कनेक्शन पूल से डेटाबेस में कनेक्शन ले रहे हैं, जब अनुरोधों को निष्पादित कर रहे हैं, और इसी तरह।

ड्राइव को इसके साथ क्या करना है? - आप पूछें। यह इसके साथ बहुत कुछ करता है।
समस्या के एक विस्तृत विश्लेषण से पता चला है कि लंबे समय तक एसटीडब्ल्यू-पॉज़ इस तथ्य के कारण उत्पन्न होते हैं कि थ्रेड लंबे समय तक सुरक्षित स्थान पर जाते हैं। जेवीएम कोड को पढ़ने के बाद, हमने महसूस किया कि सेफपॉइंट पर थ्रेड्स के सिंक्रनाइज़ेशन के दौरान, जेवीएम मेमोरी मैप के माध्यम से फाइल /tmp/hsperfdata* लिख सकता है, जिसमें यह कुछ आंकड़े निर्यात करता है। jstat और jps जैसी उपयोगिताएँ jstat jps उपयोग jstat jps ।

विकल्प -XX:+PerfDisableSharedMem साथ एक ही मशीन पर इसे अक्षम करें -XX:+PerfDisableSharedMem और ...



जेट्टी ट्रेडमिल मैट्रिक्स स्थिर:



(, ):



, , , .

?

Java- , , , .

Nuts and Bolts , . , . , , JMX.

, . .

statsd JVM, (heap, non-heap ):



, , .

— , , , , ? . () -, , RPS .

: , . . ammo- . . . :



.

, . , , - , , .

निष्कर्ष में

, Java Docker — , . .