हर दो दिन में एक service मेमोरी खत्म हो जाने पर मार दी जाती है। आप जांच कैसे करेंगे?

पहले metrics से पैटर्न की पुष्टि करें: लगातार बढ़त leak या बिना सीमा वाले cache की तरफ इशारा करती है, जबकि तीखा उछाल किसी एक request के एक साथ बहुत कुछ लोड करने की तरफ। बढ़त वाले दौर से पहले और बाद में heap profile लें और retained allocations की तुलना करें। आम वजहें हैं बिना eviction वाले caches, लंबी उम्र वाले objects से जुड़े बढ़ते collections, बिना बंद किए गए resources, और ऐसे endpoints जो पूरा result set मेमोरी में उठा लेते हैं।

ग्राफ का आकार ही बता देता है कि कहां देखना है। कई दिनों में धीमी चढ़ाई जो शांत दौर में भी नहीं गिरती, वह leak है या बिना सीमा वाला cache। जो आरी जैसा ग्राफ खास requests पर उछलता है, उसका मतलब है कुछ एक साथ बहुत ज़्यादा लोड कर रहा है। पहले वाले मामले में मैं मिलते जुलते ट्रैफ़िक पर कुछ घंटों के अंतर से heap profiles लेता हूं और retained size से उनका फर्क निकालता हूं, फिर देखता हूं कि सबसे बड़े objects को कौन पकड़े हुए है। व्यवहार में वजह आमतौर पर कोई नीरस सी बात निकली है: cache की तरह इस्तेमाल हो रहा एक map जिसमें न eviction है न कोई अधिकतम, कोई metrics label जो यूज़र के दिए गए मान से बनता था इसलिए cardinality हमेशा बढ़ती रही, या किसी लंबी उम्र वाले object पर रजिस्टर किए गए listeners जो कभी हटाए नहीं गए। उछाल के लिए मैं ऐसे endpoints ढूंढता हूं जो streaming की जगह पूरी टेबल एक list में पढ़ लेते हैं, या ऐसा batch job जो लिखने से पहले हर row लोड कर लेता है। ठीक यही मुझे एक CSV export में मिला था जो दस लाख rows मेमोरी में उतार रहा था; उसे पेजों में stream करने से मेमोरी सपाट हो गई। बाद में मैं सिर्फ crash पर नहीं, memory के रुझान पर alert लगाता हूं, ताकि restart से पहले मुझे खबर हो जाए।