Brendan Gregg की व्यावहारिक विधियाँ सीखें (USE, RED, फ्लेम ग्राफ़) ताकि आप लेटेंसी और प्रोडक्शन बॉटलनेक्स को अटकलों के बजाय डेटा से जांच सकें।

Brendan Gregg सिस्टम प्रदर्शन के सबसे प्रभावशाली वॉइसों में से एक हैं, खासकर Linux पारिस्थितिकी में। उन्होंने व्यापक रूप से उपयोग होने वाली किताबें लिखी हैं, व्यावहारिक टूलिंग बनाई है, और—सबसे महत्वपूर्ण—वास्तविक प्रोडक्शन समस्याओं की जांच के लिए स्पष्ट तरीके साझा किए हैं। टीमें उनकी विधि अपनाती हैं क्योंकि यह दबाव में काम करती है: जब लेटेंसी बढ़ती है और हर कोई जवाब चाहता है, तो आपको “शायद यह X है” से “यह निश्चित रूप से Y है” तक कम ड्रामा में पहुंचने का तरीका चाहिए।
प्रदर्शन पद्धति कोई एक उपकरण या चालाक कमांड नहीं है। यह जांच के लिए एक दोहराने योग्य तरीका है: पहले क्या देखना है, आप जो देख रहे हैं उसे कैसे व्याख्यायित करना है, और अगले कदम के रूप में क्या करना है—एक चेकलिस्ट।
यह दोहरावहीनता ही अटकलों को घटाती है। जिसकी सबसे अधिक समझ है या जिसकी आवाज़ सबसे तेज़ है, उस पर निर्भर होने के बजाय आप एक सुसंगत प्रक्रिया का पालन करते हैं जो:
कई लेटेंसी जांच पहले पांच मिनट में गलत हो जाती हैं। लोग सीधे फिक्स की ओर कूदते हैं: “CPU बढ़ाओ,” “सर्विस रिस्टार्ट करो,” “कैश बढ़ाओ,” “GC ट्यून करो,” “यह नेटवर्क होगा।” कभी-कभी ये काम कर जाते हैं—अक्सर वे सिग्नल छिपा देते हैं, समय बर्बाद करते हैं, या नया जोखिम जोड़ते हैं।
Gregg की विधियाँ आपको “समाधान” को तब तक टालने के लिए प्रेरित करती हैं जब तक आप सरल प्रश्नों का उत्तर दे न सकें: क्या संतृप्त है? क्या त्रुटि दे रहा है? क्या धीमा हुआ—थ्रूपुट, कतारबंदी, या व्यक्तिगत ऑपरेशंस?
यह गाइड आपको दायरा सीमित करने, सही सिग्नल मापने, और अनुकूलन से पहले बाधा की पुष्टि करने में मदद करता है। लक्ष्य प्रोडक्शन में लेटेंसी और प्रोफ़ाइलिंग मुद्दों की जाँच के लिए एक संरचित वर्कफ़्लो है ताकि परिणाम किस्मत पर निर्भर न हों।
लेटेंसी एक लक्षण है: उपयोगकर्ता काम खत्म होने तक ज्यादा इंतजार करते हैं। कारण आमतौर पर कहीं और होता है—CPU प्रतियोगिता, डिस्क या नेटवर्क वेट, लॉक प्रतियोगिता, गार्बेज कलेक्शन, कतारबंदी, या रिमोट डिपेंडेंसी देरी। केवल लेटेंसी मापना यह बताता है कि दर्द मौजूद है, न कि वह कहाँ से आ रहा है।
ये तीन सिग्नल आपस में जुड़े होते हैं:
ट्यून करने से पहले, उसी समय विंडो के लिए तीनों को कैप्चर करें। अन्यथा आप काम गिराकर या तेज़ फेल कर के लेटेंसी “ठीक” कर सकते हैं।
औसत लेटेंसी उन स्पाइक्स को छिपा देता है जिन्हें उपयोगकर्ता याद रखते हैं। 50 ms का औसत होने के बावजूद सेवा अक्सर 2 s के स्टॉल दे सकती है।
पर्सेंटाइल ट्रैक करें:
लेटेंसी के आकृति पर भी ध्यान दें: एक स्थिर p50 के साथ बढ़ता p99 अक्सर संकेत देता है कि बीच-बीच में स्टॉल्स हो रहे हैं (उदाहरण: लॉक प्रतियोगिता, I/O हिच, स्टॉप-दि-वर्ल्ड पोज़ेस) बजाय सामान्य स्लोडाउन के।
लेटेंसी बजट एक सरल लेखांकन मॉडल है: “यदि अनुरोध को 300 ms में खत्म होना है, तो समय कहां खर्च हो सकता है?” इसे बकेट में विभाजित करें जैसे:
यह बजट पहले माप कार्य को फ्रेम करता है: स्पाइक के दौरान कौन सा बकेट बढ़ा, उसे पहचानें, और फिर उसी क्षेत्र की जांच करें बजाय अंधाधुंध ट्यूनिंग के।
जब “सिस्टम धीमाँ है” जैसा रूप में समस्या बताई जाती है तो लेटेंसी का काम विफल हो जाता है। Gregg की विधियाँ पहले से ही शुरू होती हैं: मुद्दे को एक विशिष्ट, परखने योग्य प्रश्न में बदल दें।
किसी भी टूल को छुए बिना पहले दो वाक्य लिखें:
यह गलत लेयर का अनुकूलन करने से रोकता है—जैसे होस्ट CPU—जब दर्द केवल एक एंडपॉइंट या एक डाउनस्ट्रीम डिपेंडेंसी तक सीमित हो।
एक विंडो चुनें जो शिकायत से मेल खाती हो और यदि संभव हो एक “अच्छी” तुलना अवधि शामिल करे।
अपनी जाँच का दायरा स्पष्ट रूप से सीमित करें:
यहाँ सटीक होना बाद के चरणों (USE, RED, प्रोफ़ाइलिंग) को तेज़ बनाता है क्योंकि आप जानेंगे कि यदि आपकी परिकल्पना सही है तो डेटा को चालू होना चाहिए।
डेप्लॉय, कॉन्फ़िग परिवर्तन, ट्रैफ़िक शिफ्ट, और इन्फ्रा घटनाओं को नोट करें—लेकिन कारणत्व मानने से बचें। इन्हें इस रूप में लिखें: “यदि X हुआ, तो हमें Y देखना चाहिए,” ताकि आप तेजी से पुष्टि या अस्वीकृति कर सकें।
एक छोटा लॉग टीममेट्स के बीच डुप्लिकेट काम रोकता है और हैंडऑफ़ को सुचारु बनाता है।
Time | Question | Scope | Data checked | Result | Next step
यहाँ तक कि पाँच पंक्तियाँ भी एक तनावपूर्ण घटना को दोहराने योग्य प्रक्रिया में बदल सकती हैं।
USE विधि (Utilization, Saturation, Errors) Gregg की वह त्वरित चेकलिस्ट है जो “बड़े चार” संसाधनों—CPU, मेमोरी, डिस्क (स्टोरेज), और नेटवर्क—को स्कैन करती है, ताकि आप अटकलें छोड़ कर समस्या को संकुचित कर सकें।
दर्जनों डैशबोर्ड्स को घूरने के बजाय, हर संसाधन के लिए वही तीन प्रश्न पूछें:
लगातार लागू करने पर, यह बताता है कि कहाँ “प्रेशर” मौजूद है।
CPU के लिए, utilization CPU व्यस्त % है, saturation रन-क्यू प्रेशर या चलने के लिए प्रतीक्षारत थ्रेड्स के रूप में दिखाई देता है, और errors में कंटेनरों में थ्रॉटलिंग या समस्याग्रस्त इंटरप्ट्स शामिल हो सकते हैं।
मेमोरी के लिए, utilization उपयोग में मेमोरी है, saturation अक्सर पेजिंग या बार-बार GC के रूप में दिखता है, और errors में allocation विफलताएँ या OOM घटनाएँ हैं।
डिस्क के लिए, utilization डिवाइस व्यस्त समय है, saturation क्यू डेप्थ और रीड/राइट वेट टाइम है, और errors I/O त्रुटियाँ या टाइमआउट हैं।
नेटवर्क के लिए, utilization थ्रूपुट है, saturation ड्रॉप्स/क्यूज़/लेटेंसी है, और errors में रिट्रांसमिट्स, रिसेट्स, या पैकेट लॉस हैं।
जब उपयोगकर्ता स्लोनेस रिपोर्ट करते हैं, तो saturation सिग्नल अक्सर सबसे अधिक जानकारी देते हैं: कतारें, वेट समय, और प्रतियोगिता आमतौर पर लेटेंसी के साथ अधिक सीधे सहसम्बद्ध होते हैं बजाय कच्चे utilization के।
सेवा-स्तरीय मेट्रिक्स (जैसे अनुरोध लेटेंसी और त्रुटि दर) आपको प्रभाव बताते हैं। USE बताता है कि अगला कहां देखें—कौन सा संसाधन दबाव में है।
एक व्यावहारिक लूप:
RED विधि आपको होस्ट ग्राफ्स में उतरने से पहले उपयोगकर्ता अनुभव से जुड़े रहने में मदद करती है।
RED आपको उन “रोचक” सिस्टम मैट्रिक्स का पीछा करने से रोकता है जो उपयोगकर्ताओं को प्रभावित नहीं करते। यह एक संकुचित लूप बाध्य करता है: कौन सा एंडपॉइंट धीमा है, किसके लिए, और कब से? यदि Duration केवल एक मार्ग पर स्पाइक कर रहा है जबकि समग्र CPU सामान्य है, तो आपके पास पहले से एक तेज़ शुरुआत बिंदु है।
एक उपयोगी आदत: RED को सेवा और शीर्ष एंडपॉइंट्स (या प्रमुख RPC मेथड्स) के हिसाब से तोड़ कर रखें। इससे व्यापक गिरावट और स्थानीयकृत regressions के बीच अंतर करना आसान हो जाता है।
RED बताता है कहाँ दर्द है। USE मदद करता है यह परखने में कि कौन सा संसाधन जिम्मेदार है।
उदाहरण:
लेआउट को फोकस्ड रखें:
यदि आप एक सुसंगत घटना वर्कफ़्लो चाहते हैं, तो इस अनुभाग को /blog/use-method-overview में USE इन्वेंटरी के साथ पेयर करें ताकि आप “उपयोगकर्ता महसूस कर रहे हैं” से “यह संसाधन बाधा है” तक कम घुमाव के साथ जा सकें।
एक प्रदर्शन जांच मिनटों में दर्जनों चार्ट और परिकल्पनाओं में फैल सकती है। Gregg का माइंडसेट इसे संकुचित रखना है: आपका काम “अधिक डेटा एकत्र करना” नहीं है, बल्कि अगला वह प्रश्न पूछना है जो सबसे तेज़ी से अनिश्चितता को खत्म करे।
अधिकांश लेटेंसी समस्याएँ एकल लागत (या एक छोटा जोड़ा) से अधिक प्रभावित होती हैं: एक गर्म लॉक, एक धीमा डिपेंडेंसी, एक ओवरलोडेड डिस्क, एक GC पैटर्न। प्राथमिकता का अर्थ है पहले उस प्रमुख लागत की खोज करना, क्योंकि पाँच अलग-अलग जगहों पर 5% कम करना आमतौर पर उपयोगकर्ता-देखे जा सकने वाले लेटेंसी को नहीं बदलता।
एक व्यावहारिक परीक्षण: “क्या यह अधिकांश लेटेंसी परिवर्तन को समझा सकता है?” यदि एक परिकल्पना केवल एक छोटा हिस्सा समझा सकती है, तो वह कम प्राथमिकता वाला प्रश्न है।
टॉप-डाउन का उपयोग तब करें जब आप इसका उत्तर दे रहे हों: “क्या उपयोगकर्ता प्रभावित हैं?” एंडपॉइंट्स (RED-स्टाइल सिग्नल) से शुरू करें: लेटेंसी, थ्रूपुट, त्रुटियाँ। यह आपको उस बात से बचाता है कि आप किसी ऐसे चीज़ का अनुकूलन कर रहे हों जो क्रिटिकल पाथ में नहीं है।
बॉटम-अप का उपयोग तब करें जब होस्ट स्पष्ट रूप से बीमार हो (USE-अनुरूप लक्षण): CPU saturation, runaway मेमोरी प्रेशर, I/O वेट। यदि कोई नोड फुल है, तो आप एंडपॉइंट पर्सेंटाइल्स पर घूरते हुए समय बर्बाद कर देंगे बिना बाधा को समझे।
जब अलर्ट आ जाए, तो एक शाखा चुनें और तब तक उस पर बने रहें जब तक आप उसे पुष्टि या खंडन न कर दें:
खुद को एक छोटे शुरुआती सिग्नल सेट तक सीमित रखें, फिर केवल तब ड्रिल डाउन करें जब कुछ हिले। यदि आपको फोकस रखने के लिए चेकलिस्ट चाहिए, तो अपने स्टेप्स को /blog/performance-incident-workflow जैसे रनबुक से लिंक करें ताकि हर नया मेट्रिक एक उद्देश्य के लिए हो: एक विशेष प्रश्न का उत्तर देना।
प्रोडक्शन प्रोफ़ाइलिंग जोखिम भरा लग सकता है क्योंकि यह लाइव सिस्टम को छूता है—लेकिन अक्सर यह बहस को प्रमाण में बदलने का सबसे तेज़ तरीका है। लॉग और डैशबोर्ड यह बता सकते हैं कि कुछ धीमा है। प्रोफ़ाइलिंग यह बताती है कि कहाँ समय जा रहा है: कौन सी फ़ंक्शन ज़्यादा चल रही हैं, कौन सी थ्रेड्स वेट कर रही हैं, और किस कोड पथ का प्रभुत्व है।
प्रोफ़ाइलिंग एक “समय बजट” उपकरण है। सिद्धांतों की बहस (“यह DB है” बनाम “यह GC है”) के बजाय आपको साक्ष्य मिलता है जैसे “CPU सैंपलों का 45% JSON पार्सिंग में था” या “अधिकतर अनुरोध एक म्यूटेक्स पर ब्लॉक थे।” यह अगले कदम को एक या दो ठोस फिक्स तक सीमित कर देता है।
हर एक अलग प्रश्न का उत्तर देता है। कम CPU के साथ उच्च लेटेंसी अक्सर off-CPU या लॉक समय को दर्शाता है बजाय CPU हॉटस्पॉट के।
कई टीमें ऑन-डिमांड से शुरू करती हैं, फिर सुरक्षा देखकर और बार-बार मुद्दे मिलने पर हमेशा-ऑन की ओर बढ़ती हैं।
प्रोडक्शन-सेफ प्रोफ़ाइलिंग का मतलब लागत को नियंत्रित करना है। सैंपलिंग को प्राथमिकता दें (हर इवेंट को ट्रेस न करें), कैप्चर विंडो को छोटा रखें (उदाहरण: 10–30 सेकंड), और पहले किसी कनरी पर ओवरहेड मापें। यदि अनिश्चित हों, तो कम-फ़्रीक्वेंसी सैंपलिंग से शुरू करें और केवल तब बढ़ाएँ जब सिग्नल बहुत शोर हो।
फ्लेम ग्राफ़ यह विज़ुअलाइज़ करते हैं कि सैंपलिंग विंडो के दौरान समय कहाँ गया। हर “बॉक्स” एक फ़ंक्शन (या स्टैक फ़्रेम) है, और हर स्टैक दिखाता है कि उस फ़ंक्शन तक निष्पादन कैसे पहुँचा। वे पैटर्न जल्दी देखने के लिए शानदार हैं—लेकिन वे स्वचालित रूप से यह नहीं बताते कि “बग यहीं है।”
फ्लेम ग्राफ़ आमतौर पर on-CPU सैंपल्स का प्रतिनिधित्व करते हैं: वह समय जब प्रोग्राम वास्तव में CPU को चला रहा था। यह CPU-भारी कोड पाथ, अक्षम पार्सिंग, अत्यधिक सीरियलाइज़ेशन, या हॉटस्पॉट्स को उजागर कर सकता है जो वास्तव में CPU जलाते हैं।
यह सीधे डिस्क, नेटवर्क, शेड्यूलर डिले, या म्यूटेक्स पर ब्लॉक होने जैसे waiting को नहीं दिखाता (यह off-CPU समय है और अलग प्रोफ़ाइलिंग चाहिए)। यह उपयोगकर्ता-देखे जा सकने वाले लेटेंसी के लिए कारण साबित नहीं करता जब तक कि आप इसे एक सीमित लक्षण से न जोड़े।
सबसे चौड़ा बॉक्स दोषी ठहराने के लिए आकर्षक होता है, लेकिन पूछें: क्या यह एक हॉटस्पॉट है जिसे आप बदल सकते हैं, या बस malloc, GC, या लॉगिंग में “बिता समय” है क्योंकि असली समस्या अपस्ट्रीम है? JIT, इनलाइनिंग, या सिम्बल्स की कमी भी संदर्भ छीन सकती है और एक बॉक्स को गलती से अपराधी दिखा सकती है।
फ्लेम ग्राफ़ को एक सीमित प्रश्न का उत्तर मानें: कौन सा एंडपॉइंट, कौन सी टाइम विंडो, कौन से होस्ट, और क्या बदला। “पहले बनाम बाद” (या “स्वस्थ बनाम बिगड़ा”) फ्लेम ग्राफ़ की तुलना उसी अनुरोध पथ के लिए करें ताकि प्रोफ़ाइलिंग शोर से बचा जा सके।
जब लेटेंसी स्पाइक होती है, कई टीमें पहले CPU% पर घूरती हैं। यह समझने योग्य है—लेकिन यह अक्सर गलत दिशा में इशारा करता है। एक सेवा केवल 20% CPU पर हो सकती है और फिर भी दर्दनाक रूप से धीमी हो यदि उसकी थ्रेड्स अपना अधिकांश जीवन रन नहीं कर रही हों।
CPU% यह जवाब देता है कि “प्रोसेसर कितना व्यस्त है?” यह यह नहीं बताता कि “मेरा अनुरोध समय कहाँ गया?” अनुरोध उस समय की दीवार-क्लॉक अवधि में ऑन-CPU काम और ऑफ-CPU वेट दोनों शामिल होते हैं।
Off-CPU समय आमतौर पर डिपेंडेंसी और प्रतियोगिता के पीछे छिपा होता है:
कुछ सिग्नल अक्सर off-CPU बाधाओं से मिलते-जुलते होते हैं:
ये लक्षण बताते हैं “हम इंतजार कर रहे हैं,” पर यह नहीं बताते कि किस चीज़ का इंतजार कर रहे हैं।
Off-CPU प्रोफ़ाइलिंग उस कारण को जोड़ती है जिसकी वजह से आप रन नहीं कर रहे थे: syscalls में ब्लॉक, लॉक पर वेट, sleep, या descheduled होना। यह लेटेंसी वर्क के लिए शक्तिशाली है क्योंकि यह अस्पष्ट स्लोडाउन को क्रियान्वनीय श्रेणियों में बदल देती है: “म्यूटेक्स X पर ब्लॉक,” “डिस्क से read() पर इंतजार,” या “upstream को connect() में अटका।” एक बार जब आप वेट का नाम कर सकते हैं, तो आप उसे माप सकते हैं, पुष्टि कर सकते हैं, और ठीक कर सकते हैं।
प्रदर्शन काम अक्सर उसी क्षण विफल हो जाता है: कोई संदिग्ध मेट्रिक देखता है, उसे “समस्या” घोषित करता है, और ट्यून करना शुरू कर देता है। Gregg की विधियाँ आपको धीमा करने और यह साबित करने के लिए प्रेरित करती हैं कि क्या सिस्टम को वर्तमान में सीमित कर रहा है, उसके बिना कुछ बदलने से पहले।
एक बाधा वह संसाधन या घटक है जो वर्तमान में थ्रूपुट को सीमित करता है या लेटेंसी चला रहा है। यदि आप इसे दूर करते हैं, तो उपयोगकर्ताओं को सुधार दिखेगा।
एक हॉटस्पॉट वह जगह है जहाँ समय व्यतीत हो रहा है (उदा., प्रोफ़ाइल में बार-बार दिखने वाला फ़ंक्शन)। हॉटस्पॉट वास्तविक बाधा हो सकता है—या केवल व्यस्त काम जो स्लो पाथ को प्रभावित नहीं करता।
शोर वे सभी चीज़ें हैं जो महत्वपूर्व लगती हैं पर वास्तविक नहीं है: बैकग्राउंड जॉब्स, वन-ऑफ़ स्पाइक्स, सैंपलिंग आर्टिफैक्ट्स, कैशिंग प्रभाव, या “टॉप टॉकर्स” जो उपयोगकर्ता-देखे गए समस्या से सहसम्बद्ध नहीं हैं।
शुरू में एक साफ़ पहले स्नैपशॉट कैप्चर करें: उपयोगकर्ता-सामना लक्षण (लेटेंसी या त्रुटि दर) और प्रमुख उम्मीदवार सिग्नल (CPU saturation, क्यू डेप्थ, डिस्क I/O, लॉक प्रतियोगिता आदि)। फिर एक नियंत्रित परिवर्तन लागू करें जो केवल आपके संदेहास्पद कारण को प्रभावित करना चाहिए।
कारणात्मक परीक्षणों के उदाहरण:
सहसंबंध एक संकेत है, निर्णायक नहीं। यदि “CPU बढ़ता है जब लेटेंसी बढ़ती है,” तो CPU उपलब्धता बदल कर या CPU काम घटा कर सत्यापित करें कि क्या लेटेंसी उसके साथ चलती है।
लिखें: क्या मापा गया, किया गया सटीक परिवर्तन, पहले/बाद के नतीजे, और देखा गया सुधार। यह एक एक-बार की जीत को अगले घटना के लिए पुन: प्रयोज्य प्लेबुक में बदल देता है—और बाद में “अंतर्ज्ञान” इतिहास को गलत तरह से फिर से लिखने से रोकता है।
प्रदर्शन घटनाएँ तात्कालिक लगती हैं, और यही वह समय है जब अटकलें सबसे आसान होती हैं। एक हल्का, दोहराने योग्य वर्कफ़्लो आपको “कुछ धीमा है” से “हमें पता चल गया कि क्या बदला” तक बिना थ्रैश किए जाने में मदद करता है।
पता चलना: उपयोगकर्ता-देखे जा सकने वाले लेटेंसी और त्रुटि दर पर अलर्ट करें, सिर्फ CPU नहीं। p95/p99 लेटेंसी एक स्थायी विंडो के लिए थ्रेशहोल्ड पार करने पर पेज करें।
त्रियाज: तुरंत तीन प्रश्नों का उत्तर दें: क्या धीमा है, कब शुरू हुआ, और कौन प्रभावित है? यदि आप स्कोप (सेवा, एंडपॉइंट, क्षेत्र, कोहॉर्ट) नाम नहीं दे सकते, तो आप अनुकूलित करने के लिए तैयार नहीं हैं।
माप: उस बाधा को संकुचित करने वाले साक्ष्य इकट्ठा करें। तुलनात्मक कैप्चर को प्राथमिकता दें (उदा., 60–180 सेकंड) ताकि आप “बुरा” बनाम “अच्छा” तुलना कर सकें।
ठीक: एक बार में सिर्फ़ एक चीज़ बदलें, फिर सुधार की पुष्टि करने और प्लेसेबो को खारिज करने के लिए वही सिग्नल फिर मापें।
इंसिडेंट के दौरान हर कोई जो उपयोग करे ऐसा साझा डैशबोर्ड रखें। इसे नीरस और सुसंगत बनाएँ:
लक्ष्य सब कुछ ग्राफ़ करने का नहीं; लक्ष्य पहला तथ्य जानने का समय घटाना है।
उन एंडपॉइंट्स को इंस्ट्रूमेंट करें जो सबसे अधिक मायने रखते हैं (checkout, login, search), हर एंडपॉइंट के लिए सहमत हों: अपेक्षित p95, अधिकतम त्रुटि दर, और प्रमुख डिपेंडेंसी (DB, कैश, थर्ड-पार्टी)।
अगली आउटेज से पहले एक कैप्चर किट तय करें:
इसे एक छोटे रनबुक में डॉक्युमेंट करें (उदा., /runbooks/latency), जिसमें यह भी हो कि कौन कैप्चर चला सकता है और आर्टिफैक्ट्स कहाँ स्टोर होते हैं।
Gregg की पद्धति मूलतः नियंत्रित परिवर्तन और तेज़ सत्यापन के बारे में है। अगर आपकी टीम Koder.ai का उपयोग करके सर्विसेज बनाती है (एक चैट-ड्रिवन प्लेटफ़ॉर्म वेब, बैकेंड, और मोबाइल ऐप बनाने के लिए), तो दो सुविधाएँ उस माइंडसेट से साफ़ मेल खाती हैं:
भले ही आप घटना के दौरान नया कोड नहीं बना रहे हों, ये आदतें—छोटी डिफ़्स, मापनीय परिणाम, और तेज़ पलटाव—वही आदतें हैं जिन्हें Gregg बढ़ावा देते हैं।
सुबह 10:15 बजे आपका डैशबोर्ड दिखाता है कि API के लिए p99 लेटेंसी ~120ms से ~900ms तक चढ़ गया है पीक ट्रैफ़िक के दौरान। त्रुटि दर स्थिर है, पर ग्राहकों ने “धीमी” रिक्वेस्ट्स रिपोर्ट की हैं।
सेवा-प्रथम से शुरू करें: Rate, Errors, Duration।
आप Duration को एंडपॉइंट के अनुसार स्लाइस करते हैं और देखते हैं कि एक मार्ग p99 पर हावी है: POST /checkout। Rate 2× बढ़ा है, त्रुटियाँ सामान्य हैं, लेकिन जब concurrency बढ़ती है तब Duration स्पाइक होता है। यह कतारबंदी या प्रतियोगिता की ओर इशारा करता है, न कि साफ़ विफलता की।
अगले चरण में देखें कि लेटेंसी कंप्यूट समय है या वेट: application “handler time” बनाम total request time (या ट्रेसिंग हो तो अपस्ट्रीम बनाम डाउनस्ट्रीम स्पैन)। हैंडलर समय कम है, कुल समय ज़्यादा है—अनुरोध इंतजार कर रहे हैं।
संभावित बाधाओं की इन्वेंटरी बनाएं: CPU, मेमोरी, डिस्क, और नेटवर्क के लिए Utilization, Saturation, Errors।
CPU utilization केवल ~35% है, लेकिन CPU run queue और context switches बढ़ जाते हैं। डिस्क और नेटवर्क स्थिर दिखते हैं। यह मिसमैच (कम CPU%, उच्च वेट) क्लासिक हिंट है: थ्रेड्स CPU नहीं जला रहे—वे ब्लॉक हैं।
आप स्पाइक के दौरान off-CPU प्रोफ़ाइल कैप्चर करते हैं और shared “promotion validation” कैश के आसपास एक म्यूटेक्स में भारी समय पाते हैं।
आप ग्लोबल लॉक को प्रति-की लॉक (या लॉक-फ्री रीड पाथ) से बदलते हैं, डिप्लॉय करते हैं, और देखते हैं कि p99 बेसलाइन पर लौट आता है जबकि Rate उच्च रहता है।
पोस्ट-इंसिडेंट चेकलिस्ट: