CPU 100% पर है

“Overview” टैब में CPU ग्राफ़ पर दिखने वाला पठार अपने आप में कोई आपातकाल नहीं है: कोई प्रोजेक्ट बनाने या आर्काइव बनाने पर सभी कोर ईमानदारी से इस्तेमाल होते हैं और फिर छोड़ दिए जाते हैं। चिंता तब होती है जब पठार घंटों तक बना रहे और मशीन जवाब देना बंद कर दे। आइए पता करें कि इसमें किसका दोष है।

चरण 1. देखें कि संसाधन कौन खा रहा है

फ़ुल-स्क्रीन प्रोग्रामों के साथ काम करने के लिए “Screen” (VNC) टैब सुविधाजनक है:

btop
htop

सीरियल कंसोल विंडो का साइज़ पास नहीं करता; वहाँ हमेशा 80×24 ही रहता है, इसलिए इंटरफ़ेस कट जाएगा। टेक्स्ट कंसोल के लिए मानक कमांड इस्तेमाल करें:

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

गणित याद रखें: %CPU प्रति कोर गिना जाता है। VDS-3 पर 400% का मतलब है सभी चार कोर, जबकि VDS-4 पर 100% सिर्फ़ छह में से एक कोर है।

चरण 2. CPU और डिस्क में फ़र्क़ करें

औसत लोड (load average) सिर्फ़ गणना से नहीं, I/O वेट से भी बढ़ता है:

uptime
vmstat 1 5

vmstat के आउटपुट में us (यूज़र कोड), sy (कर्नेल), wa (डिस्क वेट) और st (स्टोलन टाइम) कॉलम देखें। बड़ा wa मतलब CPU डिस्क का इंतज़ार करते हुए बेकार बैठा है — अड़चन राइट स्पीड है, गणना नहीं। हमारे टियर पर डिस्क का पठार एक नियम से तय होता है: प्रति कोर 60 MB/s राइट, 60 से कम नहीं और 400 MB/s से ज़्यादा नहीं, रीड इससे दोगुना, और पठार से तीन गुना ऊपर का बर्स्ट 30 सेकंड चलता है। अगर कोई टास्क लगातार लिखता रहे, तो बर्स्ट ख़त्म हो जाएगा और आप पठार पर पहुँच जाएँगे।

चरण 3. किसी ख़ास प्रोसेस की जाँच करें

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

आम तौर पर ये चीज़ें मिलती हैं:

• कोई वेब एप्लिकेशन फेल हुई रिक्वेस्ट के बाद अनंत लूप में घूम रहा है;
• डेटाबेस बिना इंडेक्स के क्वेरी चला रहा है — उसका अपना स्लो क्वेरी लॉग देखें;
• कोई cron जॉब पूरा होने से पहले ही दोबारा शुरू हो जाता है और इंस्टेंस जमा होते जाते हैं: ps aux | grep <name> एक दर्जन कॉपियाँ दिखाएगा;
• कमज़ोर root पासवर्ड के ज़रिए मशीन पर घुसा कोई माइनर। पहचान है — बेतुके नाम वाली प्रोसेस जो किसी ग़ैर-मानक यूज़र के तहत चल रही हो और आउटगोइंग बैंडविड्थ बहुत ज़्यादा हो। ऐसे में साफ़ करने की बजाय “Access” टैब से मशीन को रीइंस्टॉल करना आसान है।

चरण 4. सीमित करें, मारें नहीं

अगर प्रोसेस ज़रूरी है लेकिन बाकी काम में रुकावट नहीं डालनी चाहिए:

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% मतलब दो पूरे कोर। systemd की सीमा सर्विस रीस्टार्ट होने पर भी बनी रहती है; renice नहीं।

किसी प्रोसेस को kill -9 से मारने से पहले सामान्य systemctl stop आज़माएँ। डेटाबेस को ज़बरदस्ती मारने पर फ़ाइलें ख़राब होती हैं और अगली बार शुरू होने पर लंबा रिकवरी का इंतज़ार करना पड़ता है।

जब दोष कोड का न हो

अगर लोड जायज़ और लगातार है, तो Ryzen 9 7950X CPU अपना काम कर रहा है — बस टास्क के लिए कोर काफ़ी नहीं हैं। टियर सिर्फ़ ऊपर की ओर बदला जा सकता है, पेड पीरियड के बाकी दिनों के लिए अतिरिक्त भुगतान के साथ: लेख अपना प्लान अपग्रेड करें और अंतर का भुगतान करें देखें। वापस नीचे करना उपलब्ध नहीं है, इसलिए पहले हफ़्ते और महीने के ग्राफ़ से पक्का कर लें कि पठार एक बार की घटना नहीं है।