Linux इंटरव्यू: जब CPU उपयोग कम हो तब Load Average अधिक क्यों होता है, और आप इसका निदान कैसे करते हैं?

प्रॉम्प्ट और लागू भूमिकाएं

16 लॉजिकल CPU वाला एक Linux सर्वर धीमा हो गया है। uptime 48 / 36 / 18 के लोड एवरेज की रिपोर्ट करता है, जबकि mpstat अभी भी 72% कुल CPU निष्क्रियता (idle) की रिपोर्ट करता है। तय करें कि क्या यह CPU ओवरलोड साबित करता है और बताएं कि टास्क वास्तव में किस रिसोर्स की प्रतीक्षा कर रहे हैं, इसकी पहचान कैसे करें।

उत्तर में Linux लोड अकाउंटिंग में runnable और uninterruptible टास्क को स्पष्ट किया जाना चाहिए, 1-, 5-, और 15-मिनट के मानों की सही व्याख्या की जानी चाहिए, और फिर इन मामलों में अंतर करने के लिए टास्क स्टेट्स, Pressure Stall Information (PSI), और सबसिस्टम मीट्रिक्स का उपयोग किया जाना चाहिए:

• CPU रन कतार वास्तव में कंजस्टेड (congested) है;
• स्थानीय स्टोरेज, एक नेटवर्क फाइलसिस्टम, एक ड्राइवर, या कोई अन्य कर्नल वेट टास्क को D स्टेट में रख रहा है;
• मेमोरी रिक्लेम या स्वैपिंग अप्रत्यक्ष प्रतीक्षाएं उत्पन्न कर रही है;
• होस्ट-स्तरीय मीट्रिक्स और कंटेनर- या सेवा-स्तरीय मीट्रिक्स अलग-अलग स्कोप को कवर करते हैं।

यह प्रश्न SRE, DevOps, इन्फ्रास्ट्रक्चर, सिस्टम्स और बैकएंड इंटरव्यू के लिए उपयुक्त है। 16, 48, 36, 18 और 72% मान काल्पनिक अभ्यास इनपुट हैं, सार्वभौमिक अलर्ट थ्रेशोल्ड नहीं। परिदृश्य यह मानता है कि मीट्रिक्स समान होस्ट और समय विंडो से आए हैं। यदि विभिन्न कलेक्टर्स या cgroups ने उन्हें जनरेट किया है, तो उनकी व्याख्या करने से पहले स्कोप को संरेखित (align) करें।

इंटरव्यूअर क्या जांच रहा है

पहला, उम्मीदवार को पता होना चाहिए कि लोड एवरेज CPU यूटिलाइज़ेशन नहीं है। Linux ग्लोबल लोड runnable टास्क और uninterruptible स्लीप में मौजूद टास्क का तेजी से घटता हुआ (exponentially decaying) औसत है। केवल पहला समूह सीधे CPU मांग को व्यक्त करता है; दूसरा समूह CPU के निष्क्रिय रहने पर भी लोड बढ़ा सकता है।

दूसरा, तीनों संख्याओं को एक सटीक व्याख्या की आवश्यकता है। वे पिछले 1, 5 और 15 मिनट के सैंपल्स के सरल अंकगणितीय औसत नहीं हैं। वे उन समय स्थिरांकों (time constants) के साथ तेजी से घटते हुए मान हैं। 48 > 36 > 18 इस दिशात्मक निष्कर्ष का समर्थन करता है कि हाल ही में लोड बढ़ा है, लेकिन यह पिछले मिनट में एक सटीक कतार लंबाई का पुनर्निर्माण नहीं कर सकता है या किसी मूल कारण को साबित नहीं कर सकता है।

तीसरा, एक मजबूत निदान कुल से उसकी संरचना और प्रतीक्षा स्थलों (wait sites) की ओर बढ़ता है। यह vmstat फ़ील्ड्स r और b की तुलना करता है, R और D में थ्रेड्स की गणना करता है, और फिर किसी रिसोर्स की पहचान करने के लिए wchan, कर्नल स्टैक, PSI, और स्टोरेज या नेटवर्क-फाइलसिस्टम मीट्रिक्स का उपयोग करता है। केवल top और iostat को सूचीबद्ध करना यह नहीं समझाता कि साक्ष्य निष्कर्ष को कैसे बदलते हैं।

चौथा, उम्मीदवार को विपरीत उदाहरणों (counterexamples) को संभालना चाहिए। टूल्स अक्सर D को डिस्क स्लीप के रूप में लेबल करते हैं, लेकिन uninterruptible प्रतीक्षा केवल स्थानीय डिस्क तक सीमित नहीं होती है। NFS, फाइलसिस्टम, डिवाइस ड्राइवर और कुछ कर्नल-रिसोर्स प्रतीक्षाएं भी दिखाई दे सकती हैं। %iowait CPU-टाइम अकाउंटिंग है, इसलिए कम iowait ब्लॉक किए गए टास्क को खारिज नहीं करता है।

अंत में, उत्तर को सुरक्षित शमन (mitigation) और एक सत्यापन लूप (verification loop) की आवश्यकता है। CPU जोड़ना, रीस्टार्ट करना, प्रोसेस को किल करना, या स्टोरेज को अपग्रेड करना केवल विशेष साक्ष्यों के लिए उपयुक्त है। समाधान के बाद, R/D टास्क संख्या, PSI, सबसिस्टम लेटेंसी और व्यावसायिक टेल लेटेंसी (tail latency) को एक साथ ठीक होना चाहिए। केवल लोड एवरेज के कम होने का इंतजार करना अपर्याप्त है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या मीट्रिक्स एक ही स्कोप को कवर करते हैं? लोड एवरेज आम तौर पर होस्ट-व्यापी होता है, जबकि एप्लिकेशन CPU केवल एक कंटेनर या प्रोसेस का वर्णन कर सकता है। पहले होस्ट, cgroup और सेवा मीट्रिक्स की तुलना करें; अन्यथा "उच्च लोड, कम CPU" एक स्कोप मिसमैच हो सकता है।
• क्या CPU निष्क्रियता (idle) एक समग्र या प्रति-CPU मान है? एक CPU, NUMA नोड, या एफिनिटी-बाधित वर्कलोड कतार में हो सकता है जबकि अन्य CPU निष्क्रिय हैं। mpstat -P ALL, एफिनिटी और cgroup CPU कोटा का निरीक्षण करें।
• कौन से अनुरोध धीमे हुए, और कब? लक्षण को परिनियोजन (deployments), ट्रैफ़िक, बैकअप, स्टोरेज लेटेंसी, माउंट परिवर्तन और मेमोरी रिक्लेम के साथ संरेखित करें ताकि होस्ट सिग्नल को उपयोगकर्ता प्रभाव से जोड़ा जा सके।
• क्या R या D टास्क का प्रभुत्व है? व्यस्त CPU के साथ कई R टास्क CPU विवाद (contention) का समर्थन करते हैं। निष्क्रिय CPU के साथ कई D टास्क uninterruptible प्रतीक्षा का समर्थन करते हैं। दोनों एक साथ मौजूद हो सकते हैं, इसलिए थ्रेड और वर्कलोड द्वारा समूहीकृत करें।
• कौन सा स्टोरेज पाथ शामिल है? लोकल NVMe, क्लाउड ब्लॉक स्टोरेज, FUSE, NFS और एक रिमोट डेटाबेस को अलग-अलग साक्ष्य की आवश्यकता होती है। iostat एक सामान्य नेटवर्क RPC को नहीं देख सकता है, और NFS को माउंट और नेटवर्क-फाइलसिस्टम मीट्रिक्स की आवश्यकता होती है।
• क्या मेमोरी या वर्चुअलाइजेशन का दबाव है? Swap-in/out, डायरेक्ट रिक्लेम, मेजर फॉल्ट्स, हाइपरवाइजर स्टील टाइम और cgroup सीमाएं जांच के क्रम को बदल देती हैं।
• क्या टास्क स्टैक को सुरक्षित रूप से पढ़ा जा सकता है? /proc/12345/stack, कुछ wchan मान और प्रोसेस I/O डेटा के लिए अतिरिक्त अनुमति की आवश्यकता हो सकती है। कम-ओवरहेड सैंपलिंग के साथ शुरुआत करें और केवल आवश्यक न्यूनतम प्रोडक्शन विशेषाधिकार का उपयोग करें।

30-सेकंड उत्तर रूपरेखा

"लोड एवरेज कोई CPU प्रतिशत नहीं है। Linux runnable टास्क और uninterruptible स्लीप में मौजूद टास्क की गणना करता है, फिर 1-, 5-, और 15-मिनट के समय स्थिरांक के साथ तेजी से घटते औसत की गणना करता है। 16 लॉजिकल CPU पर 48 का लोड बताता है कि कई टास्क सक्रिय हैं या uninterruptible प्रतीक्षा कर रहे हैं। 72% CPU निष्क्रियता के साथ, मैं यह निष्कर्ष नहीं निकाल सकता कि CPU संतृप्त (saturated) हैं।

मैं सबसे पहले मीट्रिक स्कोप को संरेखित करूंगा और प्रति-CPU उपयोग की जांच करूंगा। फिर मैं r में runnable टास्क की तुलना b में ब्लॉक किए गए टास्क से करने के लिए vmstat का उपयोग करूंगा, और R तथा D में थ्रेड्स की गणना करूंगा। कई R टास्क, उच्च CPU PSI और व्यस्त CPU, CPU कतारबद्धता का संकेत देते हैं। उच्च I/O PSI वाले कई D टास्क मुझे wchan, टास्क स्टैक, pidstat, iostat, NFS मीट्रिक्स और कर्नल लॉग की ओर ले जाते हैं। यदि मेमोरी PSI, स्वैपिंग और मेजर फॉल्ट्स एक साथ बढ़ते हैं, तो मैं मेमोरी प्रेशर की जांच करता हूं। समाधान के बाद, मैं केवल लोड संख्या के गिरने की प्रतीक्षा करने के बजाय व्यावसायिक p99, R/D काउंट्स, PSI और सबसिस्टम लेटेंसी को सत्यापित करता हूं।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: लोड एवरेज को उसके दो स्रोतों में विभाजित करें

Linux ग्लोबल लोड अकाउंटिंग के मुख्य इनपुट को संक्षेप में प्रस्तुत किया जा सकता है:

nr_running + nr_uninterruptible

nr_running में वर्तमान में CPU पर निष्पादित होने वाले टास्क और वे टास्क शामिल हैं जो runnable हैं लेकिन शेड्यूल होने की प्रतीक्षा कर रहे हैं। nr_uninterruptible uninterruptible स्लीप में मौजूद टास्क का प्रतिनिधित्व करता है। /proc/loadavg के पहले तीन फ़ील्ड इस सक्रिय-टास्क जनसंख्या के लिए 1-, 5- और 15-मिनट के लोड मान हैं। चौथा फ़ील्ड 7/1280 जैसा दिखता है: पहली संख्या वर्तमान में runnable शेड्यूलिंग इकाइयां (scheduling entities) हैं, और दूसरी वर्तमान में मौजूद सभी शेड्यूलिंग इकाइयां हैं। पांचवां फ़ील्ड सबसे हाल ही में बनाई गई PID है।

इसलिए, "लोड 48" का अर्थ "300% CPU यूटिलाइज़ेशन" नहीं है, और इसका मतलब यह नहीं है कि इस समय ठीक 48 प्रोसेस कतार में हैं। यह एक स्मूथ किया गया (smoothed) टास्क-काउंट सिग्नल है। लोड को लॉजिकल CPU की संख्या से विभाजित करना CPU-बाउंड वर्कलोड के लिए केवल एक मोटा संतृप्ति संकेत (saturation hint) है। एक बार जब D-स्टेट टास्क भौतिक रूप से योगदान करते हैं, तो वह अनुपात अब CPU कतार का वर्णन नहीं करता है।

कर्नल निश्चित अंतराल पर तेजी से घटते औसत को अपडेट करता है। नए सैंपल्स का वजन अधिक होता है, जबकि पुराने सैंपल्स क्षय (decay) हो जाते हैं। इस प्रकार 48 / 36 / 18 पहले की तुलना में हाल ही में अधिक सक्रिय टास्क को इंगित करता है। कारण समाप्त होने के बाद भी 15-मिनट का मान उच्च रह सकता है, इसलिए पुनर्प्राप्ति निर्णयों को वर्तमान टास्क स्थितियों, PSI और उपयोगकर्ता-सामना करने वाले मीट्रिक्स को प्राथमिकता देनी चाहिए।

चरण 2: स्कोप, प्रति-CPU उपयोग और वर्तमान कतार को संरेखित करें

कम-ओवरहेड, टाइमस्टैम्प वाले अवलोकनों से शुरुआत करें:

nproc
uptime
cat /proc/loadavg
vmstat 1 10
mpstat -P ALL 1 10

पहला vmstat रिपोर्ट आम तौर पर बूट के बाद का औसत होता है, इसलिए वर्तमान घटना के लिए बाद के सैंपल्स का उपयोग करें। महत्वपूर्ण फ़ील्ड्स में शामिल हैं:

• r: runnable टास्क; व्यस्त CPU के साथ उपलब्ध CPU से काफी ऊपर का एक निरंतर मान CPU कतारबद्धता का समर्थन करता है;
• b: uninterruptible स्लीप में टास्क; एक निरंतर वृद्धि जांच को उस रिसोर्स की ओर निर्देशित करती है जिसकी प्रतीक्षा की जा रही है;
• us, sy, id, wa, और st: उपयोगकर्ता, सिस्टम, निष्क्रिय, I/O-वेट, और हाइपरवाइजर स्टील टाइम;
• si और so: swap-in और swap-out गतिविधि, जिसे मेमोरी PSI और फॉल्ट्स के साथ समझा जाना चाहिए।

बहत्तर प्रतिशत कुल निष्क्रियता अभी भी एक हॉट CPU को छिपा सकती है। CPU 3 पर पिन किया गया एक सीरियल थ्रेड उस CPU को संतृप्त कर सकता है जबकि अन्य 15 अधिकतर निष्क्रिय रहते हैं। प्रति-CPU उपयोग, टास्क एफिनिटी, कंटेनर CPU कोटा, और थ्रॉटलिंग इसे पूरे होस्ट में अधिक CPU की आवश्यकता से अलग करते हैं।

चरण 3: थ्रेड द्वारा R और D की गणना करें और प्रतीक्षा स्थल का पता लगाएं

एक प्रोसेस के भीतर कई थ्रेड्स लोड में योगदान करते हैं, इसलिए थ्रेड-स्तरीय दृश्य का उपयोग करें:

ps -eLo state,pid,tid,ppid,wchan:32,comm --sort=state
ps -eLo state= | sort | uniq -c

R का अर्थ रनिंग या runnable है। D का अर्थ uninterruptible स्लीप है। एक सिग्नल सामान्य रूप से तब तक प्रभावी नहीं हो सकता जब तक कि टास्क उस प्रतीक्षा को छोड़ न दे, इसलिए बार-बार kill -9 जारी करने से न तो कर्नल रिसोर्स तुरंत मुक्त होता है और न ही उपयोगी साक्ष्य सुरक्षित रहता है।

D-स्टेट थ्रेड्स के क्लस्टर के लिए, कमांड, पैरेंट प्रोसेस, cgroup, और wchan द्वारा समूहीकृत करें। wchan दिखाता है कि कर्नल में एक थ्रेड कहाँ सो रहा है और यह खोज को ब्लॉक I/O, NFS, एक फाइलसिस्टम, या एक ड्राइवर पाथ तक सीमित कर सकता है। जब अनुमतियाँ अनुमति दें, तो प्रतिनिधि टास्क के कर्नल स्टैक का निरीक्षण करें:

cat /proc/12345/stack
cat /proc/12345/wchan

एक फंक्शन का नाम मूल कारण नहीं है। एक ही प्रतीक्षा स्थल पर समूहीकृत कई टास्क, जो समय में सबसिस्टम लेटेंसी और उपयोगकर्ता प्रभाव के साथ संरेखित होते हैं, मजबूत साक्ष्य बनाते हैं। D स्टेट यह भी साबित नहीं करता है कि किसी एप्लिकेशन ने जानबूझकर अत्यधिक I/O उत्पन्न किया है। एक विफल डिवाइस, पहुंच से बाहर का रिमोट माउंट, या फंसा हुआ कर्नल पाथ कम अनुरोध दर से भी कई प्रतीक्षा थ्रेड्स जमा कर सकता है।

चरण 4: प्रगति को रोकने वाले रिसोर्स की पहचान के लिए PSI का उपयोग करें

PSI CPU, मेमोरी या I/O विवाद के कारण बर्बाद हुए समय को मापता है:

for resource in cpu io memory; do
  echo "[$resource]"
  cat /proc/pressure/"$resource"
done

some समय का वह हिस्सा है जब कम से कम कुछ टास्क किसी रिसोर्स पर रुके (stalled) होते हैं। full वह हिस्सा है जब सभी गैर-निष्क्रिय टास्क एक साथ रुके होते हैं। सिस्टम-स्तरीय CPU full को शून्य के रूप में बनाए रखा जाता है और इसका उपयोग CPU संतृप्ति का अनुमान लगाने के लिए नहीं किया जाना चाहिए। avg10, avg60, और avg300 हाल के 10-, 60-, और 300-सेकंड के रुझानों का वर्णन करते हैं; total माइक्रोसेकंड में संचयी स्टाल समय है।

PSI और लोड एवरेज विभिन्न प्रश्नों का उत्तर देते हैं। लोड एवरेज बताता है कि कितने टास्क सक्रिय हैं या uninterruptibly प्रतीक्षा कर रहे हैं। PSI बताता है कि एक वर्कलोड कितने समय तक प्रगति करने में असमर्थ है। उन्हें संयोजित करने से "लोड अधिक होने के कारण CPU जोड़ें" जैसी त्वरित प्रतिक्रिया से बचाव होता है। cgroup v2 के साथ, होस्ट के शोर से सेवा के दबाव को अलग करने के लिए लक्षित cgroup में cpu.pressure, io.pressure, और memory.pressure भी पढ़ें।

साक्ष्य व्यवस्थित करने के लिए इस मैट्रिक्स का उपयोग करें:

यह मैट्रिक्स एक प्रारंभिक बिंदु है, कोई स्वचालित रूट-कॉज़ डिटेक्टर नहीं। CPU, मेमोरी और I/O दबाव एक फीडबैक लूप बना सकते हैं। मेमोरी रिक्लेम फ़ाइल रीड्स को ट्रिगर कर सकता है, उदाहरण के लिए, जो तब थ्रेड्स को D स्टेट में डाल सकता है।

चरण 5: हर प्रतीक्षा को "धीमी डिस्क" कहने के बजाय प्रासंगिक सबसिस्टम में प्रवेश करें

यदि साक्ष्य ब्लॉक डिवाइस की ओर संकेत करते हैं, तो थ्रूपुट, लेटेंसी, कतारबद्धता और त्रुटियों की जांच करें:

pidstat -d -p ALL 1 10
iostat -xz 1 10
dmesg -T | tail -200

pidstat I/O जारी करने वाली प्रक्रियाओं की पहचान करने में मदद करता है, जबकि iostat डिवाइस और पार्टीशन गतिविधि की रिपोर्ट करता है। डिवाइस के प्रकार और उसके बेसलाइन के आधार पर प्रत्येक फ़ील्ड की व्याख्या करें। उदाहरण के लिए, एक %util मान के पास सभी स्टोरेज आर्किटेक्चर में एक सार्वभौमिक संतृप्ति सीमा नहीं होती है। कर्नल लॉग में टाइमआउट, रीसेट, फाइलसिस्टम त्रुटियां, या एक अलग (detached) डिवाइस अकेले कतार गहराई की तुलना में विफलता के कारण के अधिक करीब हैं।

यदि wchan या माउंट पॉइंट NFS, FUSE, या नेटवर्क स्टोरेज का संकेत देते हैं, तो माउंट स्थिति, nfsiostat, क्लाइंट रीट्रांसमिशन, नेटवर्क लेटेंसी और सर्वर स्वास्थ्य का निरीक्षण करें। सामान्य HTTP या डेटाबेस RPC प्रतीक्षाएं आमतौर पर interruptible होती हैं और Linux लोड एवरेज में प्रवेश नहीं कर सकती हैं, इसलिए एप्लिकेशन ट्रेस, कनेक्शन पूल और निर्भरता लेटेंसी अभी भी उसी समयरेखा पर होनी चाहिए।

यदि मेमोरी PSI, स्वैपिंग, या मेजर फॉल्ट्स बढ़ते हैं, तो cgroup मेमोरी इवेंट्स, अज्ञात (anonymous) और फ़ाइल वर्किंग सेट, डायरेक्ट रिक्लेम और स्वैप डिवाइस का निरीक्षण करें। तेज़ स्टोरेज स्वैपिंग की लागत को कम कर सकता है बिना उस वर्किंग सेट को ठीक किए जो मेमोरी बजट से अधिक है।

चरण 6: साक्ष्य के आधार पर शमन करें और कार्य-कारण (Causality) को सत्यापित करें

शमन पुष्टि किए गए प्रतीक्षा रिसोर्स से मेल खाना चाहिए:

• CPU कतार विवाद: एडमिशन कम करें (shed admission), कॉनकरेंसी या बैच प्राथमिकता कम करें, गलत एफिनिटी हटाएं, और केवल एक मापे गए क्षमता मॉडल के आधार पर CPU जोड़ें;
• स्टोरेज या NFS विफलता: I/O को बढ़ाना बंद करें, एक स्वस्थ प्रतिकृति या माउंट पाथ पर स्विच करें, और डिवाइस, नेटवर्क या सर्वर की मरम्मत करें;
• मेमोरी प्रेशर: वर्किंग सेट और कॉनकरेंसी को सीमित करें, थ्रैशिंग वर्कलोड को रोकें, और संगत क्षमता सीमा के भीतर मेमोरी जोड़ें;
• स्कोप मिसमैच: यह तय करने से पहले कि क्या लक्षित सेवा को स्केलिंग की आवश्यकता है, शोर वाले वर्कलोड को अलग करें या cgroup कोटा को सही करें।

रीस्टार्ट संचित टास्क को साफ़ कर सकता है, लेकिन यह उपयोगी स्टैक और लॉग को भी मिटा सकता है। यदि अंतर्निहित रिसोर्स अनुपलब्ध रहता है, तो नई प्रक्रियाएं फिर से ब्लॉक हो जाएंगी। कार्रवाई करने से पहले, प्रतिनिधि PIDs, टास्क स्टेट्स, wchan, PSI और सबसिस्टम स्नैपशॉट को सुरक्षित रखें, और अपेक्षित मीट्रिक परिवर्तन बताएं।

स्वीकृति में व्यावसायिक p95/p99 और त्रुटि दर की पुनर्प्राप्ति, बेसलाइन पर वापस आए R/D काउंट्स, संबंधित PSI रिसोर्स में गिरता दबाव, पुनर्प्राप्त डिवाइस/NFS/मेमोरी/CPU मीट्रिक्स और सुरक्षित रूप से निकाला गया बैकलाग शामिल होना चाहिए। चूंकि लोड एवरेज धीरे-धीरे कम होता है, इसलिए यह केवल एक पुनर्प्राप्ति संकेत है न कि घटना को बंद करने का एकमात्र पैमाना।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं इसे केवल इसलिए CPU ओवरलोड नहीं कहूंगा क्योंकि 16 CPU पर लोड 48 है। Linux लोड एवरेज चल रहे या CPU की प्रतीक्षा कर रहे टास्क के साथ-साथ uninterruptible स्लीप में मौजूद टास्क की गणना को स्मूथ करता है। 72% CPU निष्क्रियता के साथ, लोड में कई D-स्टेट प्रतीक्षाएं हो सकती हैं, या समग्र मान प्रति-CPU, कोटा, या मीट्रिक-स्कोप समस्या को छिपा सकता है।

48 / 36 / 18 तेजी से घटते हुए औसत हैं। दिशात्मक रूप से, वे कहते हैं कि सक्रिय टास्क हाल ही में बढ़े हैं। वे तीन स्वतंत्र विंडो पर अंकगणितीय औसत नहीं हैं और कारण की पहचान नहीं करते हैं। मैं सबसे पहले यह सुनिश्चित करूंगा कि लोड, CPU और व्यावसायिक लेटेंसी एक ही होस्ट और समय विंडो से आए हैं, फिर हॉट CPU या स्टील टाइम के लिए mpstat -P ALL का निरीक्षण करूंगा।

इसके बाद मैं vmstat 1 के साथ r और b की तुलना करूंगा। निरंतर उच्च r, व्यस्त CPU, और उच्च CPU PSI एक CPU प्रोफ़ाइल, एफिनिटी, और cgroup थ्रॉटलिंग की ओर ले जाएंगे। उच्च b और कई D-स्टेट थ्रेड्स जबकि CPU निष्क्रिय रहते हैं, मुझे कमांड और wchan द्वारा थ्रेड्स को समूहीकृत करने, प्रतिनिधि टास्क के लिए /proc/12345/stack का निरीक्षण करने और परिणाम को I/O PSI के साथ संरेखित करने के लिए प्रेरित करेंगे।

मान लीजिए कि कई थ्रेड्स NFS-संबंधित पाथ में प्रतीक्षा कर रहे हैं, I/O PSI बढ़ता है, और स्थानीय ब्लॉक-डिवाइस iostat सामान्य रहता है। मैं स्थानीय क्लाउड डिस्क को अपग्रेड करने के बजाय माउंट्स, क्लाइंट रीट्रांसमिशन, नेटवर्क लेटेंसी और NFS सर्वर की जांच करूंगा। शमन प्रासंगिक बैच जॉब को रोकना, रीड्स को एक स्वस्थ प्रतिकृति पर स्विच करना, या प्रभावित नोड को हटाना हो सकता है। D-स्टेट प्रक्रियाओं को बार-बार किल करना आमतौर पर तुरंत प्रभावी नहीं होगा।

मरम्मत के बाद, मैं व्यावसायिक टेल लेटेंसी और त्रुटियों, R/D थ्रेड काउंट्स, होस्ट और cgroup PSI, NFS लेटेंसी और बैकलाग को सत्यापित करूंगा। 1-, 5-, और 15-मिनट के लोड मान समय के साथ कम होते हैं, इसलिए अभी भी उच्च 15-मिनट के मान को अधिक जोखिम भरे परिवर्तनों को ट्रिगर नहीं करना चाहिए जब वर्तमान प्रतीक्षाएं और उपयोगकर्ता परिणाम पहले से ही स्थिर हों।"

सामान्य गलतियाँ

• लोड एवरेज को CPU यूटिलाइज़ेशन मानना → यह टास्क की गणना करता है और uninterruptible स्लीप को शामिल करता है → CPU विवाद का निदान करने से पहले r को b से और R को D से अलग करें।
• जब भी लोड CPU संख्या से अधिक हो जाए तो ओवरलोड घोषित करना → वह नियम केवल CPU-बाउंड मांग के लिए एक मोटा संकेत है → CPU व्यस्तता, CPU PSI और runnable कतार को मिलाएं।
• 1, 5, और 15 को साधारण विंडो औसत मानना → Linux घातीय क्षय (exponential decay) का उपयोग करता है और पुराने सैंपल्स को बरकरार रखता है → दिशा के लिए तीन मानों का उपयोग करें और वर्तमान मीट्रिक्स के साथ वर्तमान की पुष्टि करें।
• प्रत्येक D टास्क को स्थानीय डिस्क का कारण बताना → NFS, फाइलसिस्टम, ड्राइवर और अन्य कर्नल प्रतीक्षाएं uninterruptible हो सकती हैं → wchan, स्टैक्स और मेल खाने वाले सबसिस्टम को ट्रेस करें।
• I/O को खारिज करना क्योंकि iowait कम है → iowait CPU-टाइम अकाउंटिंग है, ब्लॉक किए गए टास्क की संख्या नहीं → D टास्क, I/O PSI, डिवाइसेस और रिमोट-स्टोरेज लेटेंसी का निरीक्षण करें।
• केवल होस्ट-औसत CPU को देखना → एक हॉट CPU, एफिनिटी, कोटा, या अन्य cgroup औसत द्वारा छिपाया जा सकता है → प्रति-CPU, होस्ट और लक्षित-cgroup मीट्रिक्स की तुलना करें।
• अटके हुए टास्क को बार-बार kill -9 जारी करना → सिग्नल uninterruptible ऑपरेशन के वापस आने की प्रतीक्षा करता है और साक्ष्य खो सकता है → साक्ष्य सुरक्षित रखें और जिस रिसोर्स की प्रतीक्षा की जा रही है उसकी मरम्मत करें।
• एक wchan मान को मूल कारण कहना → यह केवल वर्तमान कर्नल स्लीप साइट की पहचान करता है → क्लस्टरिंग, समय सहसंबंध और सबसिस्टम साक्ष्य की आवश्यकता होती है।
• रिकवरी घोषित करने से पहले लोड एवरेज के शून्य तक पहुंचने का इंतजार करना → क्षय में समय लगता है और स्वस्थ सिस्टम को शून्य लोड की आवश्यकता नहीं होती है → उपयोगकर्ता परिणामों, वर्तमान टास्क, PSI और रिसोर्स मीट्रिक्स से पुनर्प्राप्ति स्वीकार करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: जब CPU निष्क्रियता अधिक हो तो %iowait भी कम क्यों हो सकता है?

%iowait CPU समय का वह अंश है जो निष्क्रिय है जबकि सिस्टम बकाया I/O का हिसाब रखता है। यह CPU-टाइम अकाउंटिंग है। टास्क NFS, एक ड्राइवर, या किसी अन्य uninterruptible कर्नल वेट में ब्लॉक हो सकते हैं जबकि CPU अन्य काम चलाते हैं या सामान्य निष्क्रिय रहते हैं। कई CPU में एकत्रीकरण एक स्थानीय लक्षण को भी पतला कर सकता है। D-स्टेट काउंट्स, I/O PSI, wchan और सबसिस्टम लेटेंसी का उपयोग करें; केवल कम iowait I/O या कर्नल वेट को बाहर नहीं कर सकता है।

फॉलो-अप 2: क्या कंटेनर के अंदर देखा गया लोड एवरेज उस कंटेनर का प्रतिनिधित्व करता है?

यह मान न लें कि यह करता है। दिखाई देने वाला लोड और /proc स्कोप होस्ट, PID नेमस्पेस, रनटाइम और मॉनिटरिंग कार्यान्वयन पर निर्भर करता है, जबकि एप्लिकेशन CPU cgroup-scoped हो सकता है। होस्ट और लक्षित-cgroup CPU, I/O, और मेमोरी PSI के साथ कोटा इवेंट्स पढ़ें, और थ्रेड्स को cgroups में असाइन करें। यदि होस्ट लोड अधिक है लेकिन लक्षित cgroup पर कोई दबाव नहीं है, तो उस सेवा को स्केल करने से मदद नहीं मिल सकती है।

फॉलो-अप 3: लोड 48 और 72% CPU निष्क्रियता के साथ, क्या कई D-स्टेट टास्क होने चाहिए?

नहीं। मीट्रिक्स असिंक्रनाइज़्ड हो सकते हैं, कुल निष्क्रियता एक हॉट CPU को छिपा सकती है, टास्क एफिनिटी या cgroup कोटा द्वारा बाधित हो सकते हैं, या लोड अभी गिरा हो सकता है जबकि घातीय औसत अभी भी पीक को बनाए रखते हैं। संरचना निर्धारित करने के लिए /proc/loadavg, vmstat r/b, प्रति-CPU उपयोग, R/D थ्रेड काउंट्स और कलेक्शन टाइमस्टैम्प में वर्तमान runnable संख्या की जांच करें।

फॉलो-अप 4: एक D-स्टेट प्रक्रिया कभी-कभी kill -9 से क्यों बच जाती है?

Uninterruptible स्लीप कुछ कर्नल परिचालनों को सामान्य सिग्नल रुकावट के बिना एक महत्वपूर्ण चरण पास करने देती है। SIGKILL पेंडिंग रह सकता है, लेकिन प्रोसेस गायब होने से पहले टास्क को आम तौर पर प्रतीक्षा से वापस लौटना चाहिए और ऐसे पाथ पर पहुंचना चाहिए जो बाहर निकल सके। डिवाइस, माउंट, नेटवर्क, या ड्राइवर प्रतीक्षा की मरम्मत करना अक्सर सिग्नल दोहराने से अधिक महत्वपूर्ण होता है। यदि आवश्यक हो, तो डेटा अखंडता और सेवा अतिरेक (redundancy) के विरुद्ध होस्ट रीस्टार्ट का मूल्यांकन किया जाना चाहिए।

फॉलो-अप 5: लोड-एवरेज अलर्ट कैसे कॉन्फ़िगर किए जाने चाहिए?

एक निश्चित "CPU संख्या से अधिक लोड" थ्रेशोल्ड की नकल न करें। CPU-बाउंड सेवाओं के लिए, लोड, runnable कतार, CPU PSI, उपयोगिता और cgroup थ्रॉटलिंग को मिलाएं। I/O-भारी सेवाओं के लिए, I/O PSI, D स्टेट्स, डिवाइस या रिमोट-स्टोरेज लेटेंसी और व्यावसायिक SLO को मिलाएं। सामान्य बेसलाइन, अवधि, स्केलिंग समय और उपयोगकर्ता प्रभाव से थ्रेशोल्ड सेट करें, और प्रत्येक मीट्रिक के स्कोप को लेबल करें।