हम AWS इलास्टिक कंटेनर सर्विस (ECS) फ़ार्गेट पर कई जावा सेवाएँ (Corretto JDK21) चलाते हैं। प्रत्येक सेवा का अपना कंटेनर होता है और हम उन सभी संभावित संसाधनों का उपयोग करना चाहते हैं जिनका हम प्रत्येक प्रक्रिया के लिए भुगतान कर रहे हैं। लेकिन चरणों को EC2 और अन्य बादलों पर लागू किया जा सकता है।

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

ढेर डंप ने दिलचस्प विवरण दिखाया, वास्तविक ढेर का आकार MaxHeapSize से कम था, और युवा पीढ़ी का ढेर पुरानी पीढ़ी की तुलना में छोटा था।

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

पहले चरण थे:

• पैरामीटर और डिफ़ॉल्ट मानों के बारे में जानकारी प्रिंट करें: (-XX: PrintFlagsFinal),
• InitialHeapSize को MaxHeapSize के समान मान पर सेट करें (-XX:InitialRAMPercentage=100 या बस -XX:InitialHeapSize को MaxHeapSize के समान मान पर सेट करें)। हम वैसे भी सभी कंटेनर मेमोरी के लिए भुगतान कर रहे हैं, तो इसे शुरू से ही आवंटित क्यों न करें?
• लॉग जीसी और ढेर जानकारी (-एक्सलॉग:जीसी*).

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

अगला कदम कंटेनर मेमोरी आकार के बीच इष्टतम अंतर का पता लगाना था। डिफ़ॉल्ट रूप से, भले ही InitialRAMPercentage=100, JDK केवल मेमोरी आवंटित करता है और इसका उपयोग नहीं करता है, इसलिए इसे मैप नहीं किया जाता है। लिनक्स इसे भौतिक मेमोरी की तुलना में अधिक वर्चुअल मेमोरी आवंटित करने की अनुमति देता है। और कंटेनर बाद में विफल हो जाता है जब मेमोरी वास्तव में मैप की जाती है (जेडीके इसे लिखता है)। -XX: ऑलवेज़प्रेटच इस व्यवहार को बदल देता है। दुर्भाग्य से कुछ मेमोरी अभी भी मैप नहीं की गई है लेकिन OOM समाप्ति बहुत तेजी से होती है। कई प्रयासों के बाद मैंने अगले फार्मूले कंटेनर मेमोरी साइज - 8 जीबी या अधिक मेमोरी वाले कंटेनरों के लिए 1024 एमबी पर निष्कर्ष निकाला। उदाहरण के लिए, 8192 कंटेनर मेमोरी आकार के लिए हम -XX:MaxHeapSize=7168m का उपयोग करते हैं।

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