लेटेंसी और प्रोफ़ाइलिंग के लिए Brendan Gregg की प्रदर्शन विधियाँ

Brendan Gregg की विधि क्यों अटकलों को घटाती है

Brendan Gregg सिस्टम प्रदर्शन के सबसे प्रभावशाली वॉइसों में से एक हैं, खासकर Linux पारिस्थितिकी में। उन्होंने व्यापक रूप से उपयोग होने वाली किताबें लिखी हैं, व्यावहारिक टूलिंग बनाई है, और—सबसे महत्वपूर्ण—वास्तविक प्रोडक्शन समस्याओं की जांच के लिए स्पष्ट तरीके साझा किए हैं। टीमें उनकी विधि अपनाती हैं क्योंकि यह दबाव में काम करती है: जब लेटेंसी बढ़ती है और हर कोई जवाब चाहता है, तो आपको “शायद यह X है” से “यह निश्चित रूप से Y है” तक कम ड्रामा में पहुंचने का तरीका चाहिए।

“प्रदर्शन पद्धति” का असली मतलब

प्रदर्शन पद्धति कोई एक उपकरण या चालाक कमांड नहीं है। यह जांच के लिए एक दोहराने योग्य तरीका है: पहले क्या देखना है, आप जो देख रहे हैं उसे कैसे व्याख्यायित करना है, और अगले कदम के रूप में क्या करना है—एक चेकलिस्ट।

यह दोहरावहीनता ही अटकलों को घटाती है। जिसकी सबसे अधिक समझ है या जिसकी आवाज़ सबसे तेज़ है, उस पर निर्भर होने के बजाय आप एक सुसंगत प्रक्रिया का पालन करते हैं जो:

• समस्या को एक विशिष्ट संसाधन, सेवा, या कोड पथ तक सीमित करती है
• उसी घटना की टाइम विंडो में जो हो रहा है उसे मापती है
• बदलाव करने से पहले प्रमाण के साथ बाधा की पुष्टि करती है

सामान्य विफलता मोड: मापने से पहले ठीक करना

कई लेटेंसी जांच पहले पांच मिनट में गलत हो जाती हैं। लोग सीधे फिक्स की ओर कूदते हैं: “CPU बढ़ाओ,” “सर्विस रिस्टार्ट करो,” “कैश बढ़ाओ,” “GC ट्यून करो,” “यह नेटवर्क होगा।” कभी-कभी ये काम कर जाते हैं—अक्सर वे सिग्नल छिपा देते हैं, समय बर्बाद करते हैं, या नया जोखिम जोड़ते हैं।

Gregg की विधियाँ आपको “समाधान” को तब तक टालने के लिए प्रेरित करती हैं जब तक आप सरल प्रश्नों का उत्तर दे न सकें: क्या संतृप्त है? क्या त्रुटि दे रहा है? क्या धीमा हुआ—थ्रूपुट, कतारबंदी, या व्यक्तिगत ऑपरेशंस?

यह गाइड आपको क्या करने में मदद करेगा

यह गाइड आपको दायरा सीमित करने, सही सिग्नल मापने, और अनुकूलन से पहले बाधा की पुष्टि करने में मदद करता है। लक्ष्य प्रोडक्शन में लेटेंसी और प्रोफ़ाइलिंग मुद्दों की जाँच के लिए एक संरचित वर्कफ़्लो है ताकि परिणाम किस्मत पर निर्भर न हों।

लेटेंसी बुनियादी बातें: ट्यून करने से पहले क्या मापें

लेटेंसी एक लक्षण है: उपयोगकर्ता काम खत्म होने तक ज्यादा इंतजार करते हैं। कारण आमतौर पर कहीं और होता है—CPU प्रतियोगिता, डिस्क या नेटवर्क वेट, लॉक प्रतियोगिता, गार्बेज कलेक्शन, कतारबंदी, या रिमोट डिपेंडेंसी देरी। केवल लेटेंसी मापना यह बताता है कि दर्द मौजूद है, न कि वह कहाँ से आ रहा है।

थ्रूपुट, लेटेंसी, और त्रुटियाँ एक साथ चलते हैं

ये तीन सिग्नल आपस में जुड़े होते हैं:

• थ्रूपुट (requests/second) बढ़ना कतारबंदी बढ़ा सकता है, जो लेटेंसी बढ़ाता है।
• त्रुटियाँ देखी गई लेटेंसी को कम कर सकती हैं (तेज़ फेलियर) या बढ़ा सकती हैं (रिट्राई और टाइमआउट)।
• थ्रूपुट को सीमित करना (रेट लिमिट, बैकप्रेशर) टेल लेटेंसी में सुधार कर सकता है जबकि कम अनुरोध सफल होते हैं।

ट्यून करने से पहले, उसी समय विंडो के लिए तीनों को कैप्चर करें। अन्यथा आप काम गिराकर या तेज़ फेल कर के लेटेंसी “ठीक” कर सकते हैं।

औसतों पर भरोसा न करें: पर्सेंटाइल और टेल लेटेंसी

औसत लेटेंसी उन स्पाइक्स को छिपा देता है जिन्हें उपयोगकर्ता याद रखते हैं। 50 ms का औसत होने के बावजूद सेवा अक्सर 2 s के स्टॉल दे सकती है।

पर्सेंटाइल ट्रैक करें:

• p50: सामान्य उपयोगकर्ता अनुभव
• p95/p99: टेल लेटेंसी (जहाँ अधिकतर समस्या रहती है)

लेटेंसी के आकृति पर भी ध्यान दें: एक स्थिर p50 के साथ बढ़ता p99 अक्सर संकेत देता है कि बीच-बीच में स्टॉल्स हो रहे हैं (उदाहरण: लॉक प्रतियोगिता, I/O हिच, स्टॉप-दि-वर्ल्ड पोज़ेस) बजाय सामान्य स्लोडाउन के।

लेटेंसी बजट: समय कहां खर्च होने की अनुमति है

लेटेंसी बजट एक सरल लेखांकन मॉडल है: “यदि अनुरोध को 300 ms में खत्म होना है, तो समय कहां खर्च हो सकता है?” इसे बकेट में विभाजित करें जैसे:

• आपकी सेवा में समय (कम्प्यूट + वेट)
• डाउनस्ट्रीम सेवाओं में समय
• डेटाबेस/कैश में समय
• नेटवर्क ट्रांज़िट और TLS
• कतार में बिताया समय (थ्रेड्स, कनेक्शन पूल, लोड बैलेंसर)

यह बजट पहले माप कार्य को फ्रेम करता है: स्पाइक के दौरान कौन सा बकेट बढ़ा, उसे पहचानें, और फिर उसी क्षेत्र की जांच करें बजाय अंधाधुंध ट्यूनिंग के।

स्पष्ट प्रश्न और दायरा के साथ शुरू करें

जब “सिस्टम धीमाँ है” जैसा रूप में समस्या बताई जाती है तो लेटेंसी का काम विफल हो जाता है। Gregg की विधियाँ पहले से ही शुरू होती हैं: मुद्दे को एक विशिष्ट, परखने योग्य प्रश्न में बदल दें।

“धीमा” का क्या मतलब है (और किसके लिए)

किसी भी टूल को छुए बिना पहले दो वाक्य लिखें:

• क्या धीमा है? (पेज लोड, API एंडपॉइंट, बैच जॉब, लॉगिन, चेकआउट, एक विशिष्ट SQL क्वेरी)
• कहाँ धीमा देखा गया है? (कस्टमर ब्राउज़र, मोबाइल ऐप, एक क्षेत्र, एक पॉड, एक होस्ट, एक इंटर्नल सर्विस)

यह गलत लेयर का अनुकूलन करने से रोकता है—जैसे होस्ट CPU—जब दर्द केवल एक एंडपॉइंट या एक डाउनस्ट्रीम डिपेंडेंसी तक सीमित हो।

एक टाइम विंडो और दायरा चुनें

एक विंडो चुनें जो शिकायत से मेल खाती हो और यदि संभव हो एक “अच्छी” तुलना अवधि शामिल करे।

अपनी जाँच का दायरा स्पष्ट रूप से सीमित करें:

• होस्ट बनाम सेवा बनाम एंडपॉइंट: “एक Kubernetes नोड” और “एक API रूट” अलग चीज़ें हैं।
• कौन-सा ट्रैफ़िक स्लाइस: क्षेत्र, ग्राहक टियर, केवल त्रुटि देने वाले अनुरोध, या सभी अनुरोध।
• कौन-सा सिग्नल रिपोर्ट को चला रहा है: p95 लेटेंसी, टाइमआउट, क्यू डेप्थ, या यूज़र टाइमिंग।

यहाँ सटीक होना बाद के चरणों (USE, RED, प्रोफ़ाइलिंग) को तेज़ बनाता है क्योंकि आप जानेंगे कि यदि आपकी परिकल्पना सही है तो डेटा को चालू होना चाहिए।

हालिया परिवर्तनों को परिकल्पनाओं के रूप में रखें, उत्तरों के रूप में नहीं

डेप्लॉय, कॉन्फ़िग परिवर्तन, ट्रैफ़िक शिफ्ट, और इन्फ्रा घटनाओं को नोट करें—लेकिन कारणत्व मानने से बचें। इन्हें इस रूप में लिखें: “यदि X हुआ, तो हमें Y देखना चाहिए,” ताकि आप तेजी से पुष्टि या अस्वीकृति कर सकें।

एक हल्का जांच लॉग रखें

एक छोटा लॉग टीममेट्स के बीच डुप्लिकेट काम रोकता है और हैंडऑफ़ को सुचारु बनाता है।

Time | Question | Scope | Data checked | Result | Next step

यहाँ तक कि पाँच पंक्तियाँ भी एक तनावपूर्ण घटना को दोहराने योग्य प्रक्रिया में बदल सकती हैं।

USE विधि: संसाधन बाधाओं की तेज़ इन्वेंटरी

USE विधि (Utilization, Saturation, Errors) Gregg की वह त्वरित चेकलिस्ट है जो “बड़े चार” संसाधनों—CPU, मेमोरी, डिस्क (स्टोरेज), और नेटवर्क—को स्कैन करती है, ताकि आप अटकलें छोड़ कर समस्या को संकुचित कर सकें।

यह क्या है: प्रति-संसाधन चेकलिस्ट

दर्जनों डैशबोर्ड्स को घूरने के बजाय, हर संसाधन के लिए वही तीन प्रश्न पूछें:

• Utilization: यह अभी कितना व्यस्त है?
• Saturation: क्या कार्य बंट रहा है (क्यूज़, वेट टाइम), भले ही उपयोग अधिक न हो?
• Errors: क्या यह विफल हो रहा है या रिट्राई कर रहा है जिससे देरी होती है?

लगातार लागू करने पर, यह बताता है कि कहाँ “प्रेशर” मौजूद है।

व्यावहारिक तरीके से लागू कैसे करें

CPU के लिए, utilization CPU व्यस्त % है, saturation रन-क्यू प्रेशर या चलने के लिए प्रतीक्षारत थ्रेड्स के रूप में दिखाई देता है, और errors में कंटेनरों में थ्रॉटलिंग या समस्याग्रस्त इंटरप्ट्स शामिल हो सकते हैं।

मेमोरी के लिए, utilization उपयोग में मेमोरी है, saturation अक्सर पेजिंग या बार-बार GC के रूप में दिखता है, और errors में allocation विफलताएँ या OOM घटनाएँ हैं।

डिस्क के लिए, utilization डिवाइस व्यस्त समय है, saturation क्यू डेप्थ और रीड/राइट वेट टाइम है, और errors I/O त्रुटियाँ या टाइमआउट हैं।

नेटवर्क के लिए, utilization थ्रूपुट है, saturation ड्रॉप्स/क्यूज़/लेटेंसी है, और errors में रिट्रांसमिट्स, रिसेट्स, या पैकेट लॉस हैं।

लेटेंसी घटनाओं के दौरान सबसे उपयोगी सिग्नल

जब उपयोगकर्ता स्लोनेस रिपोर्ट करते हैं, तो saturation सिग्नल अक्सर सबसे अधिक जानकारी देते हैं: कतारें, वेट समय, और प्रतियोगिता आमतौर पर लेटेंसी के साथ अधिक सीधे सहसम्बद्ध होते हैं बजाय कच्चे utilization के।

USE सेवा-स्तरीय मेट्रिक्स की पूरक है (बदलाव नहीं)

सेवा-स्तरीय मेट्रिक्स (जैसे अनुरोध लेटेंसी और त्रुटि दर) आपको प्रभाव बताते हैं। USE बताता है कि अगला कहां देखें—कौन सा संसाधन दबाव में है।

एक व्यावहारिक लूप:

1. उपयोगकर्ता प्रभाव की पुष्टि करें (Duration/Errors)
2. USE इन्वेंटरी चलाएँ
3. संदेहास्पद संसाधन पर गहरी टूलिंग (प्रोफ़ाइल, ट्रेस, कर्नेल स्टेट) के साथ ज़ूम इन करें

RED विधि: सेवा-प्रथम सिग्नल जो प्रभाव की ओर इशारा करते हैं

RED विधि आपको होस्ट ग्राफ्स में उतरने से पहले उपयोगकर्ता अनुभव से जुड़े रहने में मदद करती है।

• Rate: आपकी सेवा या एंडपॉइंट कितने अनुरोध प्रति सेकंड संभाल रहा है
• Errors: कितने अनुरोध विफल हो रहे हैं (और आपकी ऐप में “फेल” का क्या मतलब है)
• Duration: सफल अनुरोध कितना समय लेते हैं (पर्सेंटाइल के रूप में ट्रैक करें, औसत के रूप में नहीं)

RED आपको प्राथमिकता क्यों देने में मदद करता है

RED आपको उन “रोचक” सिस्टम मैट्रिक्स का पीछा करने से रोकता है जो उपयोगकर्ताओं को प्रभावित नहीं करते। यह एक संकुचित लूप बाध्य करता है: कौन सा एंडपॉइंट धीमा है, किसके लिए, और कब से? यदि Duration केवल एक मार्ग पर स्पाइक कर रहा है जबकि समग्र CPU सामान्य है, तो आपके पास पहले से एक तेज़ शुरुआत बिंदु है।

एक उपयोगी आदत: RED को सेवा और शीर्ष एंडपॉइंट्स (या प्रमुख RPC मेथड्स) के हिसाब से तोड़ कर रखें। इससे व्यापक गिरावट और स्थानीयकृत regressions के बीच अंतर करना आसान हो जाता है।

RED लक्षणों को USE चेक्स से मैप करना

RED बताता है कहाँ दर्द है। USE मदद करता है यह परखने में कि कौन सा संसाधन जिम्मेदार है।

उदाहरण:

• Duration बढ़ा + Rate स्थिर → saturation/कतारबंदी जांचें: CPU रन क्यू, स्टोरेज लेटेंसी, DB कनेक्शन पूल।
• Errors बढ़े + Duration बढ़ा → टाइमआउट और रिट्राई जांचें: ओवरलोडेड डाउनस्ट्रीम, थ्रेड पूल, नेटवर्क ड्रॉप्स।
• Rate बढ़ा + Duration बढ़ा → क्षमता सीमाओं की जाँच करें: CPU उपयोग, लोड बैलेंसर व्यवहार, ऑटोस्केलिंग देरी।

एक न्यूनतम “क्या बदल गया?” डैशबोर्ड

लेआउट को फोकस्ड रखें:

1. RED ओवरव्यू: सेवा के लिए Rate, Errors, और p50/p95/p99 Duration।
2. टॉप एंडपॉइंट्स: प्रति एंडपॉइंट वही RED सिग्नल, ट्रैफ़िक या सबसे खराब p95 के आधार पर सॉर्ट किया हुआ।
3. डिपेंडेंसीज़: मुख्य डाउनस्ट्रीम (DB, कैश, बाहरी APIs) के लिए RED-शैली पैनल।
4. एक कोरिलेशन रो: कुछ सिस्टम मैट्रिक्स (CPU, मेमोरी प्रेशर, डिस्क I/O लेटेंसी, नेटवर्क रिट्रांसमिट्स) ताकि सेवा व्यू से रूट-कारण परीक्षण तक की छलांग तेज़ हो सके।

यदि आप एक सुसंगत घटना वर्कफ़्लो चाहते हैं, तो इस अनुभाग को /blog/use-method-overview में USE इन्वेंटरी के साथ पेयर करें ताकि आप “उपयोगकर्ता महसूस कर रहे हैं” से “यह संसाधन बाधा है” तक कम घुमाव के साथ जा सकें।

प्राथमिकता: अगले सर्वश्रेष्ठ प्रश्न चुनना

एक प्रदर्शन जांच मिनटों में दर्जनों चार्ट और परिकल्पनाओं में फैल सकती है। Gregg का माइंडसेट इसे संकुचित रखना है: आपका काम “अधिक डेटा एकत्र करना” नहीं है, बल्कि अगला वह प्रश्न पूछना है जो सबसे तेज़ी से अनिश्चितता को खत्म करे।

बाधाओं के लिए 80/20 नियम

अधिकांश लेटेंसी समस्याएँ एकल लागत (या एक छोटा जोड़ा) से अधिक प्रभावित होती हैं: एक गर्म लॉक, एक धीमा डिपेंडेंसी, एक ओवरलोडेड डिस्क, एक GC पैटर्न। प्राथमिकता का अर्थ है पहले उस प्रमुख लागत की खोज करना, क्योंकि पाँच अलग-अलग जगहों पर 5% कम करना आमतौर पर उपयोगकर्ता-देखे जा सकने वाले लेटेंसी को नहीं बदलता।

एक व्यावहारिक परीक्षण: “क्या यह अधिकांश लेटेंसी परिवर्तन को समझा सकता है?” यदि एक परिकल्पना केवल एक छोटा हिस्सा समझा सकती है, तो वह कम प्राथमिकता वाला प्रश्न है।

टॉप-डाउन बनाम बॉटम-अप: कहाँ से शुरू करें

टॉप-डाउन का उपयोग तब करें जब आप इसका उत्तर दे रहे हों: “क्या उपयोगकर्ता प्रभावित हैं?” एंडपॉइंट्स (RED-स्टाइल सिग्नल) से शुरू करें: लेटेंसी, थ्रूपुट, त्रुटियाँ। यह आपको उस बात से बचाता है कि आप किसी ऐसे चीज़ का अनुकूलन कर रहे हों जो क्रिटिकल पाथ में नहीं है।

बॉटम-अप का उपयोग तब करें जब होस्ट स्पष्ट रूप से बीमार हो (USE-अनुरूप लक्षण): CPU saturation, runaway मेमोरी प्रेशर, I/O वेट। यदि कोई नोड फुल है, तो आप एंडपॉइंट पर्सेंटाइल्स पर घूरते हुए समय बर्बाद कर देंगे बिना बाधा को समझे।

एक सरल निर्णय वृक्ष जो थ्रैश रोकता है

जब अलर्ट आ जाए, तो एक शाखा चुनें और तब तक उस पर बने रहें जब तक आप उसे पुष्टि या खंडन न कर दें:

• लेटेंसी स्पाइक + त्रुटियाँ स्पाइक → “क्या यह डिपेंडेंसी या क्षमता घटना है?” (टाइमआउट, कनेक्शन पूल एक्स्हॉस्टेड, डाउनस्ट्रीम 5xx)
• लेटेंसी स्पाइक + CPU स्पाइक → “क्या CPU उपयोगी काम कर रहा है या फसा हुआ है?” (on-CPU बनाम off-CPU समय)
• लेटेंसी स्पाइक + उच्च I/O वेट → “कौन सा डिवाइस या फाइलसिस्टम क्यू बैक कर रहा है?”
• लेटेंसी स्पाइक बिना संसाधन स्पाइक्स के → “समय कहाँ वेट में जा रहा है?” (लॉक्स, शेड्यूलर, नेटवर्क, रिमोट कॉल)

मैट्रिक ओवरलोड से बचें, व्यवस्थित बने रहें

खुद को एक छोटे शुरुआती सिग्नल सेट तक सीमित रखें, फिर केवल तब ड्रिल डाउन करें जब कुछ हिले। यदि आपको फोकस रखने के लिए चेकलिस्ट चाहिए, तो अपने स्टेप्स को /blog/performance-incident-workflow जैसे रनबुक से लिंक करें ताकि हर नया मेट्रिक एक उद्देश्य के लिए हो: एक विशेष प्रश्न का उत्तर देना।

प्रोडक्शन में बिना सिस्टम डाउन किए प्रोफ़ाइलिंग

प्रोडक्शन प्रोफ़ाइलिंग जोखिम भरा लग सकता है क्योंकि यह लाइव सिस्टम को छूता है—लेकिन अक्सर यह बहस को प्रमाण में बदलने का सबसे तेज़ तरीका है। लॉग और डैशबोर्ड यह बता सकते हैं कि कुछ धीमा है। प्रोफ़ाइलिंग यह बताती है कि कहाँ समय जा रहा है: कौन सी फ़ंक्शन ज़्यादा चल रही हैं, कौन सी थ्रेड्स वेट कर रही हैं, और किस कोड पथ का प्रभुत्व है।

प्रोफ़ाइलिंग असल में किसका उत्तर देती है

प्रोफ़ाइलिंग एक “समय बजट” उपकरण है। सिद्धांतों की बहस (“यह DB है” बनाम “यह GC है”) के बजाय आपको साक्ष्य मिलता है जैसे “CPU सैंपलों का 45% JSON पार्सिंग में था” या “अधिकतर अनुरोध एक म्यूटेक्स पर ब्लॉक थे।” यह अगले कदम को एक या दो ठोस फिक्स तक सीमित कर देता है।

प्रोडक्शन में उपयोग करने योग्य सामान्य प्रकार

• CPU प्रोफ़ाइलिंग: दिखाती है कि कौन सा कोड on-CPU निष्पादित हो रहा है।
• Off-CPU (wait) प्रोफ़ाइलिंग: दिखाती है कि थ्रेड्स कहाँ ब्लॉक हैं (I/O वेट, शेड्यूलर डिले, sleep, नेटवर्क, डिस्क)।
• लॉक प्रोफ़ाइलिंग: प्रतियोगिता दिखाती है—लॉक्स, म्यूटेक्स और रीड/राइट लैच पर खोया समय।

हर एक अलग प्रश्न का उत्तर देता है। कम CPU के साथ उच्च लेटेंसी अक्सर off-CPU या लॉक समय को दर्शाता है बजाय CPU हॉटस्पॉट के।

हमेशा-ऑन बनाम ऑन-डिमांड

• हमेशा-ऑन प्रोफ़ाइलिंग (कॉन्टिन्यूअस, कम ओवरहेड) उन “यह रात में 3 बजे हुआ” रहस्यों के लिए मददगार है क्योंकि आप पीछे देख सकते हैं।
• ऑन-डिमांड प्रोफ़ाइलिंग स्पाइक के दौरान लक्षित कैप्चर है। यह अपनाने में सरल है, लेकिन आपको इसे जल्दी ट्रिगर करने के लिए तैयार रहना चाहिए।

कई टीमें ऑन-डिमांड से शुरू करती हैं, फिर सुरक्षा देखकर और बार-बार मुद्दे मिलने पर हमेशा-ऑन की ओर बढ़ती हैं।

सुरक्षा: ओवरहेड, सैंपलिंग, और छोटे विंडो

प्रोडक्शन-सेफ प्रोफ़ाइलिंग का मतलब लागत को नियंत्रित करना है। सैंपलिंग को प्राथमिकता दें (हर इवेंट को ट्रेस न करें), कैप्चर विंडो को छोटा रखें (उदाहरण: 10–30 सेकंड), और पहले किसी कनरी पर ओवरहेड मापें। यदि अनिश्चित हों, तो कम-फ़्रीक्वेंसी सैंपलिंग से शुरू करें और केवल तब बढ़ाएँ जब सिग्नल बहुत शोर हो।

फ्लेम ग्राफ़: उन्हें कैसे पढ़ें और गलत निष्कर्षों से कैसे बचें

फ्लेम ग्राफ़ यह विज़ुअलाइज़ करते हैं कि सैंपलिंग विंडो के दौरान समय कहाँ गया। हर “बॉक्स” एक फ़ंक्शन (या स्टैक फ़्रेम) है, और हर स्टैक दिखाता है कि उस फ़ंक्शन तक निष्पादन कैसे पहुँचा। वे पैटर्न जल्दी देखने के लिए शानदार हैं—लेकिन वे स्वचालित रूप से यह नहीं बताते कि “बग यहीं है।”

एक फ्लेम ग्राफ़ क्या दिखाता है (और क्या नहीं)

फ्लेम ग्राफ़ आमतौर पर on-CPU सैंपल्स का प्रतिनिधित्व करते हैं: वह समय जब प्रोग्राम वास्तव में CPU को चला रहा था। यह CPU-भारी कोड पाथ, अक्षम पार्सिंग, अत्यधिक सीरियलाइज़ेशन, या हॉटस्पॉट्स को उजागर कर सकता है जो वास्तव में CPU जलाते हैं।

यह सीधे डिस्क, नेटवर्क, शेड्यूलर डिले, या म्यूटेक्स पर ब्लॉक होने जैसे waiting को नहीं दिखाता (यह off-CPU समय है और अलग प्रोफ़ाइलिंग चाहिए)। यह उपयोगकर्ता-देखे जा सकने वाले लेटेंसी के लिए कारण साबित नहीं करता जब तक कि आप इसे एक सीमित लक्षण से न जोड़े।

चौड़ाई और स्टैक डेप्थ पढ़ना

• चौड़ाई: उस फ़्रेम का सैंपलों में कितनी बार प्रकट होना। चौड़ा होने का अर्थ है “ज़्यादा CPU समय,” लेकिन केवल चुनी हुई टाइम विंडो के भीतर।
• स्टैक डेप्थ: कॉल की गहराई। गहरी स्टैक्स अपने आप में बुरी नहीं हैं; मायने यह रखते हैं कि कौन से पाथ प्रभुत्व रखते हैं और क्या वे आपके काम से मेल खाते हैं।

सामान्य जालों से बचें

सबसे चौड़ा बॉक्स दोषी ठहराने के लिए आकर्षक होता है, लेकिन पूछें: क्या यह एक हॉटस्पॉट है जिसे आप बदल सकते हैं, या बस malloc, GC, या लॉगिंग में “बिता समय” है क्योंकि असली समस्या अपस्ट्रीम है? JIT, इनलाइनिंग, या सिम्बल्स की कमी भी संदर्भ छीन सकती है और एक बॉक्स को गलती से अपराधी दिखा सकती है।

फ्लेम ग्राफ़ को एक सटीक प्रश्न के साथ पेयर करें

फ्लेम ग्राफ़ को एक सीमित प्रश्न का उत्तर मानें: कौन सा एंडपॉइंट, कौन सी टाइम विंडो, कौन से होस्ट, और क्या बदला। “पहले बनाम बाद” (या “स्वस्थ बनाम बिगड़ा”) फ्लेम ग्राफ़ की तुलना उसी अनुरोध पथ के लिए करें ताकि प्रोफ़ाइलिंग शोर से बचा जा सके।

Off-CPU समय: लेटेंसी का छिपा स्रोत

जब लेटेंसी स्पाइक होती है, कई टीमें पहले CPU% पर घूरती हैं। यह समझने योग्य है—लेकिन यह अक्सर गलत दिशा में इशारा करता है। एक सेवा केवल 20% CPU पर हो सकती है और फिर भी दर्दनाक रूप से धीमी हो यदि उसकी थ्रेड्स अपना अधिकांश जीवन रन नहीं कर रही हों।

CPU% अकेला क्यों भ्रामक है

CPU% यह जवाब देता है कि “प्रोसेसर कितना व्यस्त है?” यह यह नहीं बताता कि “मेरा अनुरोध समय कहाँ गया?” अनुरोध उस समय की दीवार-क्लॉक अवधि में ऑन-CPU काम और ऑफ-CPU वेट दोनों शामिल होते हैं।

सामान्य off-CPU कारण

Off-CPU समय आमतौर पर डिपेंडेंसी और प्रतियोगिता के पीछे छिपा होता है:

• डिस्क I/O: सिंक्रोनस रीड/राइट, fsyncs, धीमा स्टोरेज, पेज कैश मिसेस।
• नेटवर्क वेट: DNS लुकअप, TCP रिट्रांसमिट्स, ओवरलोडेड अपस्ट्रीम सेवाएँ।
• लॉक्स और म्यूटेक्स प्रतियोगिता: थ्रेड्स लॉक पर ब्लॉक।
• कतारबंदी: थ्रेड पूल, कनेक्शन पूल, या आंतरिक वर्क कतारों में इंतजार।

देखने लायक लक्षण

कुछ सिग्नल अक्सर off-CPU बाधाओं से मिलते-जुलते होते हैं:

• बढ़ता क्यू टाइम (अनुरोध शुरू होने से पहले इंतजार)
• बढ़ती रनएबल थ्रेड्स (CPU समय के लिए ज्यादा प्रतियोगिता)
• बढ़ा हुआ I/O वेट और लंबी डिस्क/नेटवर्क लेटेंसी

ये लक्षण बताते हैं “हम इंतजार कर रहे हैं,” पर यह नहीं बताते कि किस चीज़ का इंतजार कर रहे हैं।

off-CPU प्रोफ़ाइलिंग कैसे दिखाती है "समय कहाँ गया"

Off-CPU प्रोफ़ाइलिंग उस कारण को जोड़ती है जिसकी वजह से आप रन नहीं कर रहे थे: syscalls में ब्लॉक, लॉक पर वेट, sleep, या descheduled होना। यह लेटेंसी वर्क के लिए शक्तिशाली है क्योंकि यह अस्पष्ट स्लोडाउन को क्रियान्वनीय श्रेणियों में बदल देती है: “म्यूटेक्स X पर ब्लॉक,” “डिस्क से read() पर इंतजार,” या “upstream को connect() में अटका।” एक बार जब आप वेट का नाम कर सकते हैं, तो आप उसे माप सकते हैं, पुष्टि कर सकते हैं, और ठीक कर सकते हैं।

प्रतिभूति के साथ बाधा की पुष्टि करें, अंतर्ज्ञान के साथ नहीं

प्रदर्शन काम अक्सर उसी क्षण विफल हो जाता है: कोई संदिग्ध मेट्रिक देखता है, उसे “समस्या” घोषित करता है, और ट्यून करना शुरू कर देता है। Gregg की विधियाँ आपको धीमा करने और यह साबित करने के लिए प्रेरित करती हैं कि क्या सिस्टम को वर्तमान में सीमित कर रहा है, उसके बिना कुछ बदलने से पहले।

बाधा, हॉटस्पॉट, और शोर

एक बाधा वह संसाधन या घटक है जो वर्तमान में थ्रूपुट को सीमित करता है या लेटेंसी चला रहा है। यदि आप इसे दूर करते हैं, तो उपयोगकर्ताओं को सुधार दिखेगा।

एक हॉटस्पॉट वह जगह है जहाँ समय व्यतीत हो रहा है (उदा., प्रोफ़ाइल में बार-बार दिखने वाला फ़ंक्शन)। हॉटस्पॉट वास्तविक बाधा हो सकता है—या केवल व्यस्त काम जो स्लो पाथ को प्रभावित नहीं करता।

शोर वे सभी चीज़ें हैं जो महत्वपूर्व लगती हैं पर वास्तविक नहीं है: बैकग्राउंड जॉब्स, वन-ऑफ़ स्पाइक्स, सैंपलिंग आर्टिफैक्ट्स, कैशिंग प्रभाव, या “टॉप टॉकर्स” जो उपयोगकर्ता-देखे गए समस्या से सहसम्बद्ध नहीं हैं।

तुलना और नियंत्रित परिवर्तन से साबित करें

शुरू में एक साफ़ पहले स्नैपशॉट कैप्चर करें: उपयोगकर्ता-सामना लक्षण (लेटेंसी या त्रुटि दर) और प्रमुख उम्मीदवार सिग्नल (CPU saturation, क्यू डेप्थ, डिस्क I/O, लॉक प्रतियोगिता आदि)। फिर एक नियंत्रित परिवर्तन लागू करें जो केवल आपके संदेहास्पद कारण को प्रभावित करना चाहिए।

कारणात्मक परीक्षणों के उदाहरण:

• संदेहास्पद संसाधन में क्षमता जोड़ें (एक और वर्कर, अधिक CPU शेयर, बड़ा कनेक्शन पूल) और देखें कि क्या लेटेंसी सुधरती है।
• मांग अस्थायी रूप से घटाएं (शोर करने वाले एंडपॉइंट को लिमिट करें, कम वर्कलोड रीयप्ले करें) और देखें कि क्या संदेहास्पद बाधा ढीली पड़ती है।

सहसंबंध एक संकेत है, निर्णायक नहीं। यदि “CPU बढ़ता है जब लेटेंसी बढ़ती है,” तो CPU उपलब्धता बदल कर या CPU काम घटा कर सत्यापित करें कि क्या लेटेंसी उसके साथ चलती है।

आपने क्या साबित किया, इसे डॉक्युमेंट करें

लिखें: क्या मापा गया, किया गया सटीक परिवर्तन, पहले/बाद के नतीजे, और देखा गया सुधार। यह एक एक-बार की जीत को अगले घटना के लिए पुन: प्रयोज्य प्लेबुक में बदल देता है—और बाद में “अंतर्ज्ञान” इतिहास को गलत तरह से फिर से लिखने से रोकता है।

प्रदर्शन घटनाओं के लिए दोहराने योग्य वर्कफ़्लो बनाएं

प्रदर्शन घटनाएँ तात्कालिक लगती हैं, और यही वह समय है जब अटकलें सबसे आसान होती हैं। एक हल्का, दोहराने योग्य वर्कफ़्लो आपको “कुछ धीमा है” से “हमें पता चल गया कि क्या बदला” तक बिना थ्रैश किए जाने में मदद करता है।

घटना लूप: पता चलना → त्रियाज → माप → ठीक

पता चलना: उपयोगकर्ता-देखे जा सकने वाले लेटेंसी और त्रुटि दर पर अलर्ट करें, सिर्फ CPU नहीं। p95/p99 लेटेंसी एक स्थायी विंडो के लिए थ्रेशहोल्ड पार करने पर पेज करें।

त्रियाज: तुरंत तीन प्रश्नों का उत्तर दें: क्या धीमा है, कब शुरू हुआ, और कौन प्रभावित है? यदि आप स्कोप (सेवा, एंडपॉइंट, क्षेत्र, कोहॉर्ट) नाम नहीं दे सकते, तो आप अनुकूलित करने के लिए तैयार नहीं हैं।

माप: उस बाधा को संकुचित करने वाले साक्ष्य इकट्ठा करें। तुलनात्मक कैप्चर को प्राथमिकता दें (उदा., 60–180 सेकंड) ताकि आप “बुरा” बनाम “अच्छा” तुलना कर सकें।

ठीक: एक बार में सिर्फ़ एक चीज़ बदलें, फिर सुधार की पुष्टि करने और प्लेसेबो को खारिज करने के लिए वही सिग्नल फिर मापें।

छोटे सेट के ग्राफ़ स्टैण्डर्डाइज़ करें

इंसिडेंट के दौरान हर कोई जो उपयोग करे ऐसा साझा डैशबोर्ड रखें। इसे नीरस और सुसंगत बनाएँ:

• लेटेंसी: p50 / p95 / p99 (प्रत्येक महत्वपूर्ण एंडपॉइंट के लिए)
• RED सिग्नल: Rate, Errors, Duration (सेवा-प्रथम व्यू)
• कुछ USE मेट्रिक्स: CPU, डिस्क, नेटवर्क के लिए utilization, saturation, errors

लक्ष्य सब कुछ ग्राफ़ करने का नहीं; लक्ष्य पहला तथ्य जानने का समय घटाना है।

प्रत्येक महत्वपूर्ण एंडपॉइंट के लिए “गोल्डन सिग्नल” पर निर्णय लें

उन एंडपॉइंट्स को इंस्ट्रूमेंट करें जो सबसे अधिक मायने रखते हैं (checkout, login, search), हर एंडपॉइंट के लिए सहमत हों: अपेक्षित p95, अधिकतम त्रुटि दर, और प्रमुख डिपेंडेंसी (DB, कैश, थर्ड-पार्टी)।

घटनाओं के दौरान क्या कैप्चर करना है तय करें

अगली आउटेज से पहले एक कैप्चर किट तय करें:

• प्रोफ़ाइल्स (CPU और off-CPU), साथ में फ्लेम ग्राफ़
• धीमे एंडपॉइंट्स के लिए ट्रेसेस
• त्रुटियों/टाइमआउट्स के लिए लॉग्स (सैंपल किए हुए)

इसे एक छोटे रनबुक में डॉक्युमेंट करें (उदा., /runbooks/latency), जिसमें यह भी हो कि कौन कैप्चर चला सकता है और आर्टिफैक्ट्स कहाँ स्टोर होते हैं।

Koder.ai एक Gregg-शैली वर्कफ़्लो में कहाँ बैठता है

Gregg की पद्धति मूलतः नियंत्रित परिवर्तन और तेज़ सत्यापन के बारे में है। अगर आपकी टीम Koder.ai का उपयोग करके सर्विसेज बनाती है (एक चैट-ड्रिवन प्लेटफ़ॉर्म वेब, बैकेंड, और मोबाइल ऐप बनाने के लिए), तो दो सुविधाएँ उस माइंडसेट से साफ़ मेल खाती हैं:

• Planning Mode आपको “शायद यह X है” को एक स्पष्ट परिकल्पना और छोटे, परखने योग्य परिवर्तन सेट में बदलने में मदद करता है।
• Snapshots and rollback सुरक्षित, सिंगल-वेरीएबल प्रयोगों का समर्थन करते हैं: एक बदलाव लागू करें, RED/USE सिग्नल फिर मापें, और यदि साक्ष्य “नहीं” कहें तो तेज़ी से रोलबैक करें।

भले ही आप घटना के दौरान नया कोड नहीं बना रहे हों, ये आदतें—छोटी डिफ़्स, मापनीय परिणाम, और तेज़ पलटाव—वही आदतें हैं जिन्हें Gregg बढ़ावा देते हैं।

एक व्यावहारिक वॉकथ्रू: लेटेंसी स्पाइक से सत्यापित फिक्स तक

परिदृश्य: पी99 पीक ट्रैफ़िक पर कूदता है

सुबह 10:15 बजे आपका डैशबोर्ड दिखाता है कि API के लिए p99 लेटेंसी ~120ms से ~900ms तक चढ़ गया है पीक ट्रैफ़िक के दौरान। त्रुटि दर स्थिर है, पर ग्राहकों ने “धीमी” रिक्वेस्ट्स रिपोर्ट की हैं।

चरण 1 — उपयोगकर्ता प्रभाव पता करने के लिए RED से शुरू करें

सेवा-प्रथम से शुरू करें: Rate, Errors, Duration।

आप Duration को एंडपॉइंट के अनुसार स्लाइस करते हैं और देखते हैं कि एक मार्ग p99 पर हावी है: POST /checkout। Rate 2× बढ़ा है, त्रुटियाँ सामान्य हैं, लेकिन जब concurrency बढ़ती है तब Duration स्पाइक होता है। यह कतारबंदी या प्रतियोगिता की ओर इशारा करता है, न कि साफ़ विफलता की।

अगले चरण में देखें कि लेटेंसी कंप्यूट समय है या वेट: application “handler time” बनाम total request time (या ट्रेसिंग हो तो अपस्ट्रीम बनाम डाउनस्ट्रीम स्पैन)। हैंडलर समय कम है, कुल समय ज़्यादा है—अनुरोध इंतजार कर रहे हैं।

चरण 2 — संदेहास्पद होस्ट(स) पर USE लागू करें

संभावित बाधाओं की इन्वेंटरी बनाएं: CPU, मेमोरी, डिस्क, और नेटवर्क के लिए Utilization, Saturation, Errors।

CPU utilization केवल ~35% है, लेकिन CPU run queue और context switches बढ़ जाते हैं। डिस्क और नेटवर्क स्थिर दिखते हैं। यह मिसमैच (कम CPU%, उच्च वेट) क्लासिक हिंट है: थ्रेड्स CPU नहीं जला रहे—वे ब्लॉक हैं।

चरण 3 — लक्षणों के आधार पर प्रोफ़ाइलिंग चुनें

• यदि CPU उच्च है: CPU प्रोफ़ाइलिंग (on-CPU फ्लेम ग्राफ़) का उपयोग करें ताकि यह देखें कि समय कहाँ जा रहा है।
• यदि अनुरोध इंतजार कर रहे हैं: off-CPU प्रोफ़ाइलिंग का उपयोग करें ताकि देखें थ्रेड्स किस पर ब्लॉक हैं (लॉक्स, I/O, शेड्यूलिंग)।

आप स्पाइक के दौरान off-CPU प्रोफ़ाइल कैप्चर करते हैं और shared “promotion validation” कैश के आसपास एक म्यूटेक्स में भारी समय पाते हैं।

चरण 4 — ठीक करें, फिर सत्यापित करें

आप ग्लोबल लॉक को प्रति-की लॉक (या लॉक-फ्री रीड पाथ) से बदलते हैं, डिप्लॉय करते हैं, और देखते हैं कि p99 बेसलाइन पर लौट आता है जबकि Rate उच्च रहता है।

पोस्ट-इंसिडेंट चेकलिस्ट:

• सटीक RED लक्षण और संकुचित एंडपॉइंट रिकॉर्ड करें।
• प्रोफ़ाइल और टाइम विंडो सहेजें।
• विशिष्ट saturation सिग्नल (उदा., लॉक वेट / रन क्यू) के लिए अलर्ट जोड़ें।
• लिखें कि अगले बार होने पर “अगला प्रश्न” क्या होगा।