आपकी 99वें percentile की latency में ऐसे उछाल हैं जिन्हें application कोड से नहीं समझाया जा सकता। आप कैसे जांचेंगे कि इसके पीछे garbage collection है?

garbage collection logging चालू करें और pause के timestamps को धीमी requests के सामने रखकर मिलाएं। अगर उछाल pauses से मेल खाते हैं, तो कोई flag छूने से पहले allocation rate, promotion और heap की गुंजाइश देखें, क्योंकि ज्यादातर pauses हद से ज्यादा allocate करने या बहुत छोटे heap से आते हैं। अगर मेल नहीं खाते, तो time to safepoint देखें, क्योंकि लंबा safepoint हर थ्रेड को रोक देता है और बिल्कुल garbage collection pause जैसा दिखता है।

मुझे दो timelines चाहिए। unified logging मुझे हर pause उसकी वजह और अवधि के साथ देती है, और मेरे traces मुझे धीमी requests देते हैं, तो पहला सवाल बस यह है कि दोनों मेल खाते हैं या नहीं। अगर खाते हैं, तो मैं flags बदलने से खुद को रोकता हूं और वजह देखता हूं। आमतौर पर service हर request पर बहुत ज्यादा allocate करती है, जैसे loop में बीच के lists बनाना या हर call पर serialized payload लॉग करना, तो उपाय है कम allocate करना। कभी heap बहुत तंग होता है और collections लगातार चलती रहती हैं, या G1 में कोड इतनी बड़ी arrays बनाता है कि वे humongous objects बन जाती हैं और बुरी तरह बर्ताव करती हैं। उसके बाद ही मैं low pause collector पर जाने के बारे में सोचूंगा, और उसे मुफ्त की जीत नहीं, एक ट्रेडऑफ मानूंगा। अगर pauses मेल नहीं खाते, तो मैं कहीं और देखता हूं: collection खुद छोटा होने पर भी time to safepoint लंबा हो सकता है, तो counted loop में फंसा एक थ्रेड सबको रोक देता है। मैंने एक मामला ऐसा भी खोजा है जो निकला container CPU throttling, जहां process को पूरी तरह schedule से हटा दिया गया था और कोई भी JVM tuning काम न आती।