मेमोरी: कितनी दें और सारी क्यों नहीं

कंट्रोल पैनल में मेमोरी ग्राफ़ नए लोगों को डराता है: यह लगभग हमेशा ऊँचा रहता है। यह Java का सामान्य व्यवहार है।

इसे कैसे पढ़ें

Java मेमोरी पहले से आवंटित करता है और उसे केवल garbage collection के दौरान मुक्त करता है। ग्राफ़ पर दिखने वाला sawtooth — बढ़ता उपयोग और collection के बाद तेज़ गिरावट — एक स्वस्थ सर्वर का संकेत है।

समस्या अलग दिखती है: लाइन ऊपर की सीमा पर टिकी रहती है और गिरावट के बाद नीचे नहीं आती। इसका मतलब है कि garbage मुक्त नहीं हो रहा — या तो मेमोरी वाकई बहुत कम है, या कोई leak है।

कमी के संकेत

• लॉग में OutOfMemoryError — विश्लेषण।
• कई सेकंड तक फ़्रीज़ होना, जो uptime के साथ बढ़ता जाता है।
• रीस्टार्ट के बाद सर्वर ठीक चलता है और शाम तक खराब हो जाता है।

Leak

अगर खपत रैखिक रूप से बढ़ती है और घटती नहीं, तो दोषी खोजें:

spark heapsummary

आमतौर पर यह कोई प्लगइन होता है जो डेटा जमा करता रहता है, या chunk loaders वाला कोई मॉड — Spark।

अस्थायी उपाय है दिन में एक बार auto-restart। स्थायी समाधान है दोषी को ढूँढकर अपडेट करना।

सब कुछ आवंटित न करें

heap के अलावा, प्रोसेस को metadata, threads और buffers के लिए मेमोरी चाहिए, और कंटेनर को सिस्टम के लिए मेमोरी चाहिए। Millida कंट्रोल पैनल इसे खुद ध्यान में रखता है और प्लान के अनुसार heap सीमाएँ सेट करता है — आपको इसे मैन्युअल रूप से छूने की ज़रूरत नहीं है।

प्लान कब बदलें

जब सामान्य संचालन के दौरान peak खपत लगातार सीमा तक पहुँच जाए और प्रोफ़ाइल में leak न दिखे — प्लान बदलना।