Linux साक्षात्कार: आप उच्च I/O wait का निदान कैसे करेंगे?

प्रॉम्प्ट और संदर्भ

एक Linux होस्ट रिपोर्ट करता है कि %iowait 3% से बढ़कर 38% हो रहा है, जबकि एप्लिकेशन p99 लेटेंसी दोगुनी हो जाती है और कुल CPU उपयोग 30% बना रहता है। बताएं कि आप स्थानीय ब्लॉक डिवाइस, NFS या किसी अन्य रिमोट स्टोर, मेमोरी रिक्लेम, हाइपरवाइजर स्टील (steal), और होस्ट व सेवा मापों के बीच बेमेल होने में कैसे अंतर करेंगे।

/proc/stat में iowait के अर्थ और सीमाओं से शुरुआत करें। फिर vmstat, iostat, pidstat, PSI, टास्क स्टेट्स, cgroup मेट्रिक्स और कर्नेल लॉग के साथ साक्ष्य बनाएं। ये संख्याएँ काल्पनिक अभ्यास डेटा हैं, सार्वभौमिक चेतावनी सीमाएँ (alert thresholds) नहीं।

साक्षात्कारकर्ता क्या परीक्षण कर रहा है

लेखांकन सीमा (Accounting boundary)

उम्मीदवार को पता होना चाहिए कि iowait एक CPU लेखांकन क्षेत्र है, न कि डिवाइस उपयोग या सभी कार्यों द्वारा प्रतीक्षा में बिताया गया कुल समय। मल्टीकोर शेड्यूलिंग एट्रिब्यूशन को अपूर्ण बना देती है।

साक्ष्य स्तर (Evidence layers)

एक मजबूत उत्तर होस्ट औसत से प्रति-CPU, थ्रेड, cgroup, डिवाइस और व्यावसायिक टेल-लेटेंसी साक्ष्य की ओर बढ़ता है, और बताता है कि प्रत्येक अवलोकन क्या बदलता है।

प्रतीक्षा पथ (Wait paths)

उत्तर में स्थानीय ब्लॉक I/O, NFS/FUSE, डेटाबेस RPC, मेमोरी रिक्लेम और हाइपरवाइजर स्टील को अलग किया जाना चाहिए। प्रत्येक पथ के अलग-अलग साक्ष्य और शमन होते हैं।

सुरक्षित समाधान (Safe closure)

उम्मीदवार साक्ष्य सुरक्षित रखता है, परिकल्पना से जुड़े कम जोखिम वाले शमन का चयन करता है, और डिफ़ॉल्ट रूप से पुनरारंभ (restart) करने या समवर्तीता (concurrency) बढ़ाने के बजाय सुधार की पुष्टि करता है।

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

• क्या iowait होस्ट से है या कंटेनर से? होस्ट /proc/stat और सेवा cgroup मेट्रिक्स विभिन्न आबादियों (populations) को कवर कर सकते हैं।
• क्या प्रत्येक CPU उच्च है, या केवल एक? औसत मान एफ़िनिटी, NUMA, और कोटा-प्रेरित स्थानीय संतृप्ति (saturation) को छिपाते हैं।
• क्या अनुरोध किसी फ़ाइल, ब्लॉक डिवाइस या नेटवर्क RPC पर प्रतीक्षा कर रहा है? NFS, डेटाबेस और HTTP प्रतीक्षाओं के अलग-अलग साक्ष्य होते हैं।
• क्या p99 और I/O सिग्नल बिल्कुल समान विंडो साझा करते हैं? नमूनाकरण (sampling), परिनियोजन (deployment), बैकअप और ट्रैफ़िक परिवर्तनों को संरेखित करें।
• क्या स्वैप, मेजर फॉल्ट, मेमोरी PSI, या स्टील टाइम बढ़ रहे हैं?
• क्या आप थ्रेड स्टैक और cgroup फ़ाइलें पढ़ सकते हैं? उत्पादन जांच के दौरान न्यूनतम विशेषाधिकार (least privilege) का उपयोग करें।

30 सेकंड का उत्तर

"अड़तीस प्रतिशत iowait एक सुराग है, डिस्क विफलता का प्रमाण नहीं। मैं होस्ट, सेवा और p99 विंडो को संरेखित करूँगा, फिर प्रति-CPU mpstat, vmstat r/b, CPU/IO/मेमोरी PSI, cgroup कोटा और स्टील टाइम का निरीक्षण करूँगा।

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

चरण-दर-चरण विस्तृत उत्तर

चरण 1: iowait सीमा को परिभाषित करें

/proc/stat iowait, I/O पूर्णता की प्रतीक्षा से जुड़ा CPU-समय लेखांकन है। जब एक कार्य प्रतीक्षा करता है तो दूसरा कार्य चल सकता है, और मल्टीकोर लेखांकन हमेशा प्रतीक्षा को सटीक रूप से विशेषता नहीं दे सकता है। कम iowait रिमोट स्टोरेज या कर्नेल प्रतीक्षाओं से इनकार नहीं करता है; उच्च iowait डिस्क विफलता को साबित नहीं करता है।

चरण 2: प्रति-CPU डेटा और कतारों की जाँच करें

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

व्यस्त CPU के साथ निरंतर r CPU कतारबद्धता का समर्थन करता है; निरंतर b निर्बाध प्रतीक्षाओं (uninterruptible waits) की ओर इशारा करता है। प्रति-CPU डेटा, एफ़िनिटी, cgroup कोटा और थ्रॉटलिंग "कुल मिलाकर 30%, स्थानीय रूप से संतृप्त" को प्रकट कर सकते हैं।

चरण 3: PSI के साथ स्टाल समय को मापें

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

PSI some उस समय को मापता है जब कम से कम कुछ कार्य स्टाल हो जाते हैं; full उस समय को मापता है जब सभी गैर-निष्क्रिय कार्य स्टाल हो जाते हैं। avg10/60/300 रुझान दिखाते हैं। सेवा दबाव को होस्ट शोर से अलग करने के लिए लक्षित cgroup की दबाव फ़ाइलों को पढ़ें।

चरण 4: थ्रेड और प्रतीक्षा बिंदुओं का पता लगाएं

ps -eLo state,pid,tid,wchan:32,comm --sort=state
pidstat -d -p ALL 1 10

R/D स्थिति, कमांड, cgroup और wchan द्वारा समूहीकृत करें। यदि अनुमति हो, तो प्रतिनिधि थ्रेड्स के लिए /proc/PID/stack का निरीक्षण करें। एक wchan केवल एक वर्तमान स्लीप लोकेशन है; इसे कारण बताने से पहले अस्थायी सहसंबंध (temporal correlation), PSI और व्यावसायिक लेटेंसी की आवश्यकता होती है।

चरण 5: प्रासंगिक सबसिस्टम में प्रवेश करें

iostat -xz 1 10
dmesg -T | tail -200
cat /proc/meminfo | egrep 'Swap|Dirty|Major'

ब्लॉक डिवाइसों के लिए, await, कतार की गहराई, थ्रूपुट और त्रुटियों का निरीक्षण करें। NFS/FUSE के लिए, माउंट, रिट्रांसमिट, नेटवर्क और सर्वर स्वास्थ्य का निरीक्षण करें। मेमोरी के लिए, मेमोरी PSI, स्वैप और मेजर फॉल्ट को सहसंबंधित करें। डेटाबेस या HTTP RPC प्रतीक्षाओं के लिए ट्रेसिंग और पूल मेट्रिक्स की आवश्यकता होती है; iostat अकेले उन्हें नहीं देख सकता।

चरण 6: शमन करें और सत्यापित करें

थ्रेड, PSI, डिवाइस और लॉग स्नैपशॉट कैप्चर करें, फिर साक्ष्य के अनुसार दर-सीमित (rate-limit) करें, बैच कार्य को रोकें, स्वस्थ प्रतिकृति (replica) पर स्विच करें, या माउंट की मरम्मत करें। D-स्थिति कार्यों को बार-बार kill -9 न करें; उन्हें आमतौर पर सिग्नल को संभालने से पहले निर्बाध प्रतीक्षा छोड़ने की आवश्यकता होती है। p99, त्रुटियों, R/D गणनाओं, PSI, संसाधन लेटेंसी और बैकलॉग को एक साथ सत्यापित करें।

आदर्श उत्तर

"अड़तीस प्रतिशत iowait एक सुराग है, कोई निष्कर्ष नहीं। यह मल्टीकोर शेड्यूलिंग से प्रभावित CPU लेखांकन है, इसलिए मैं इसे तुरंत डिस्क विफलता नहीं कहूँगा। मैं स्कोप और समय विंडो को संरेखित करूँगा, फिर प्रति-CPU mpstat, vmstat r/b, CPU/IO/मेमोरी PSI, cgroup कोटा और स्टील टाइम का निरीक्षण करूँगा।

यदि D-स्थिति थ्रेड और I/O PSI बढ़ते हैं, wchan ब्लॉक I/O की ओर इशारा करता है, और iostat उच्च लेटेंसी और कतारें दिखाता है, तो मैं डिवाइस, फ़ाइल सिस्टम और कर्नेल त्रुटियों का निरीक्षण करूँगा। यदि स्थानीय डिवाइस स्वस्थ हैं लेकिन थ्रेड NFS प्रतीक्षाओं में क्लस्टर होते हैं, तो मैं माउंट, रिट्रांसमिट, नेटवर्क और सर्वर का निरीक्षण करूँगा। यदि मेमोरी PSI, स्वैप या मेजर फॉल्ट बढ़ते हैं, तो मैं वर्किंग सेट को नियंत्रित करूँगा; यदि स्टील बढ़ता है, तो मैं हाइपरवाइजर की जांच करूँगा।

मैं साक्ष्य को सुरक्षित रखते हुए I/O-एम्प्लीफाइंग बैच कार्य को रोकूँगा, दर-सीमित करूँगा, या एक स्वस्थ प्रतिकृति पर स्विच करूँगा। पुनर्प्राप्ति का अर्थ यह है कि व्यावसायिक p99 और त्रुटियां, R/D वेटर्स, PSI, संसाधन लेटेंसी और बैकलॉग बेसलाइन की ओर लौटते हैं, न कि केवल iowait का गिरना।"

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

• iowait को डिस्क उपयोग मानना; इसे iostat और डिवाइस बेसलाइन के साथ सहसंबंधित करें।
• जैसे ही iowait बढ़ता है CPU जोड़ना; पहले प्रति-CPU डेटा, R/D स्थितियां और PSI की जांच करें।
• I/O को खारिज करना क्योंकि iowait कम है; D स्थितियों, रिमोट स्टोरेज और I/O PSI का निरीक्षण करें।
• प्रत्येक D स्थिति को स्थानीय-डिस्क समस्या कहना; NFS, फ़ाइल सिस्टम और ड्राइवर भी ब्लॉक कर सकते हैं।
• केवल होस्ट मेट्रिक्स देखना; सेवा cgroup की अलग-अलग सीमाएँ और दबाव हो सकते हैं।
• एक ही नमूना लेना; अनुरोध वक्र के साथ संरेखित निरंतर, टाइमस्टैम्प वाले नमूनों का उपयोग करें।
• तुरंत पुनरारंभ करना या समाप्त (kill) करना; साक्ष्य सुरक्षित रखें और डेटा सुरक्षा का आकलन करें।
• केवल iowait घटने की प्रतीक्षा करना; उपयोगकर्ता लेटेंसी और संसाधन कतारों को सत्यापित करें।

अनुवर्ती प्रश्न

अनुवर्ती 1: डिस्क उपयोग कम होने पर भी iowait अधिक क्यों हो सकता है?

प्रतीक्षा NFS, FUSE, डेटाबेस या नेटवर्क RPC में हो सकती है, या डिवाइस मैपिंग और विंडो भिन्न हो सकते हैं। थ्रेड प्रतीक्षा बिंदु, ट्रेसिंग, I/O PSI, माउंट और नेटवर्क संकेतों का पालन करें।

अनुवर्ती 2: अनुरोध अटके होने पर भी iowait कम क्यों हो सकता है?

कार्य लॉक, पूल, CPU कोटा, मेमोरी रिक्लेम या रिमोट RPC पर प्रतीक्षा कर सकते हैं। R/D स्थितियों, स्टैक, CPU/मेमोरी PSI और निर्भरता लेटेंसी की तुलना करें; CPU लेखांकन प्रत्येक प्रतीक्षा को iowait के रूप में वर्गीकृत नहीं करता है।

अनुवर्ती 3: आप कैसे बता सकते हैं कि किसी कंटेनर पर उसका अपना I/O दबाव है?

लक्षित cgroup के io.pressure, I/O सांख्यिकी, और थ्रॉटलिंग घटनाओं को पढ़ें, फिर उनकी तुलना होस्ट /proc/pressure/io और सेवा p99 से करें। कम सेवा दबाव के साथ उच्च होस्ट दबाव का यह अर्थ नहीं है कि सेवा को स्केल करने से मदद मिलेगी।

अनुवर्ती 4: क्या आप D-स्थिति थ्रेड को किल कर सकते हैं?

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

अनुवर्ती 5: आप iowait पर अलर्ट कैसे सेट करेंगे?

एक सार्वभौमिक प्रतिशत से बचें। कार्यभार की आधार रेखा के अनुसार कैलिब्रेट किए गए I/O PSI, स्थानीय या रिमोट स्टोरेज लेटेंसी, D-स्थिति गणना, व्यावसायिक SLO और अवधि के साथ iowait को संयोजित करें।