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

Load average: तीन संख्याएँ और एक आम ग़लतफ़हमी

uptime
cat /proc/loadavg
nproc

ये तीन संख्याएँ एक, पाँच और पंद्रह मिनट के औसत हैं। इनकी तुलना शून्य से नहीं, बल्कि nproc द्वारा बताई गई कोर की संख्या से की जाती है। आठ कोर वाली मशीन पर 8 का मान पूरा लेकिन स्वस्थ भार है: काम ठीक उतना ही है जितना सर्वर निपटा सकता है। एक कोर वाले VPS पर 2 का मान क्षमता से दोगुनी लंबी क़तार है, और हर अनुरोध अपनी बारी का इंतज़ार करता है।

तीनों संख्याओं का आपसी अनुपात दिशा बताता है। एक मिनट का मान पंद्रह मिनट के मान से साफ़ ऊपर हो तो भार अभी बढ़ रहा है। इसका उल्टा हो तो शिखर बीत चुका है और आप उसकी पूँछ देख रहे हैं।

अब वह ग़लतफ़हमी जिसकी वजह से ये आँकड़े सबसे ज़्यादा ग़लत पढ़े जाते हैं। लिनक्स में load average «प्रोसेसर का उपयोग» नहीं है। दूसरे यूनिक्स सिस्टमों के विपरीत, लिनक्स इसमें केवल चल रही या चलने को तैयार प्रक्रियाएँ ही नहीं गिनता, बल्कि वे भी जो D अवस्था में हैं — अबाधित नींद में। यानी वे जो डिस्क या नेटवर्क फ़ाइल सिस्टम का इंतज़ार कर रही हैं। यहीं से वह सर्वर आता है जिसका भार 12 है और प्रोसेसर लगभग ख़ाली: काम आगे नहीं बढ़ रहा, सब क़तार में खड़े हैं।

प्रोसेसर या डिस्क

इन दोनों स्थितियों को अलग करना पहला काम है जो करने लायक़ है:

vmstat 1 5
iostat -x 1 3

vmstat के आउटपुट में तीन कॉलम मायने रखते हैं। r बताता है कि कितनी प्रक्रियाएँ प्रोसेसर की क़तार में हैं, b कितनी इनपुट-आउटपुट के इंतज़ार में रुकी हैं, और wa समय का वह हिस्सा है जो प्रोसेसर ने ख़ाली बैठकर डिस्क का इंतज़ार करते हुए बिताया। us और sy मामूली होते हुए भी wa लगातार 10–15 % से ऊपर रहे तो इसका मतलब है कि सर्वर डिस्क पर अटका है: कोर बढ़ाना बेकार है, मौजूदा वैसे भी ख़ाली हैं।

कौन-सी प्रक्रियाएँ इंतज़ार कर रही हैं, यह नाम से सूचीबद्ध किया जा सकता है:

ps -eo state,pid,comm,wchan:30 | awk '$1 ~ /^D/'

अपने अनुभव से एक उदाहरण। डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ Suricata लगभग तीस तरह की घटनाएँ लिखती है और उनके लिए कोई रोटेशन तय नहीं करती — एक चालू सर्वर पर इससे दो दिन में 15 GB लॉग बन गए। भार तब व्यस्त प्रोसेसर के रूप में नहीं, बल्कि ठीक I/O wait के रूप में दिखा: सिस्टम लगातार लिख रहा था और बाक़ी सब उसके पीछे क़तार में था। इलाज बड़ा प्लान नहीं, बल्कि घटनाओं की छोटी सूची और तय किया गया रोटेशन है।

उल्टा मामला, विशुद्ध रूप से प्रोसेसर का और कहीं कम स्पष्ट। एक वेब पेज apt को उस उपयोगकर्ता के नाम से चला रहा था जिसके तहत PHP-FPM चलता है। रूट एक बाइनरी कैश /var/cache/apt/pkgcache.bin में रखता है — दर्जन भर रिपॉज़िटरी वाले होस्ट पर यह 70 MB है — और उसे मुफ़्त में मेमोरी में मैप कर लेता है। सामान्य उपयोगकर्ता उस डायरेक्टरी में लिख नहीं सकता और हर कॉल पर कैश नए सिरे से बनाता है। एक ही मशीन पर मापा गया: रूट के रूप में 0.01 सेकंड प्रोसेसर समय बनाम बिना अधिकार वाले उपयोगकर्ता के रूप में 4.2 सेकंड। वही कमांड, चार सौ गुना अंतर, और यह अंतर पेज के हर बार खुलने से गुणा होता रहा।

दोनों मामलों का निष्कर्ष एक ही है: भार मापा जाता है, अनुमान नहीं लगाया जाता। हर संदिग्ध कमांड का अलग-अलग समय लेना आधा घंटा लेता है और आमतौर पर वहाँ इशारा करता है जहाँ से शक शुरू नहीं हुआ था।

मेमोरी: free वह नहीं दिखाता जो दिखता है

free -h

कॉलम used अपने आप में बहुत कम कहता है, और कॉलम free तो सीधे भ्रमित करता है: लिनक्स बिना इस्तेमाल की मेमोरी पेज कैश को दे देता है और पहली माँग पर एप्लिकेशनों को लौटा देता है। पढ़ने लायक़ कॉलम available है — यानी swap में गए बिना कितनी मेमोरी ली जा सकती है। बड़ा buff/cache समस्या नहीं, बल्कि इस बात का संकेत है कि सिस्टम ठीक चल रहा है।

swap में मौजूदा मान नहीं, आकार मायने रखता है। बढ़ा और शून्य पर लौट आया: छोटा शिखर था। एक बार बढ़ा और वहीं रह गया: शिखर आ चुका है, पन्ने बाहर धकेले जा चुके हैं और कोई उन्हें वापस नहीं लाता — सर्वर शांत दिखता है, हालाँकि किसी क्षण उसकी मेमोरी कम पड़ गई थी। अदला-बदली अभी चल रही है या नहीं, यह vmstat के si और so कॉलम दिखाते हैं; वहाँ शून्य से भिन्न मान सुस्ती का वही रूप हैं जिसे उपयोगकर्ता सबसे ज़्यादा महसूस करते हैं।

अगर रात की गिरावट के दौरान कोई प्रक्रिया बस ग़ायब हो गई, तो व्याख्या आमतौर पर यहाँ मिलती है:

journalctl -k --since yesterday | grep -i "out of memory"
dmesg -T | grep -i "killed process"

Out of memory: Killed process 1234 (mysqld) जैसी पंक्ति मामला किसी भी ग्राफ़ से बेहतर तय कर देती है: डेटाबेस «अपने आप नहीं गिरा», कर्नेल ने उसे रोका क्योंकि मेमोरी ख़त्म हो गई थी।

यह कौन कर रहा है

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10

एक चेतावनी: ps में %CPU प्रक्रिया के पूरे जीवनकाल का औसत है, इसलिए छोटा उछाल उस सूची में खो जाता है। उसके लिए top या pidstat 1 5 चाहिए, जो एक अंतराल पर मापते हैं।

भार कब सुरक्षा का सवाल बन जाता है

रात भर प्रोसेसर का सपाट 100 %, साथ में ऐसी प्रक्रिया जिसका नाम बेमतलब हो और कार्यशील डायरेक्टरी /tmp या /dev/shm में हो, माइनर की क्लासिक तस्वीर है, बढ़ी हुई साइट की नहीं। आने वाले ट्रैफ़िक में उछाल के साथ लॉग में लिखाई का बढ़ना जारी पासवर्ड हमला है। लॉग की मात्रा का अचानक उछलना आमतौर पर किसी फ़िल्टर के झूठे अलार्मों का तूफ़ान होता है।

सुरक्षा उपकरण ख़ुद एक अलग श्रेणी हैं। हमारे एक सर्वर पर बिना किसी विज़िटर के भार तीन के आसपास बना रहा, और जमा हुए प्रोसेसर समय के हिसाब से ps की सूची में सबसे ऊपर न साइट थी न डेटाबेस, बल्कि CrowdSec, fail2ban, Falco और Suricata थे। यह न ख़राबी है और न उन्हें बंद करने की वजह, लेकिन सुरक्षा की क़ीमत आँकड़ों में जानना उपयोगी है: छोटे VPS पर वह महसूस होती है।

निगरानी किसलिए

ऊपर कही गई हर बात इस सवाल का जवाब देती है कि «अभी क्या हो रहा है»। सुबह का सवाल — रात तीन बजे क्या हुआ — इन कमांडों से पूरा नहीं होता: बीती रात का कोई डेटा नहीं होता अगर किसी ने उसे दर्ज न किया हो। और सिर्फ़ एक VPS के लिए Prometheus और Grafana खड़ा करना संदिग्ध है, क्योंकि निगरानी करने वाला ढाँचा निगरानी में रखे सर्वर से भारी निकलता है।

हर पाँच मिनट में डेटाबेस की एक पंक्ति और एक ऐसा पेज काफ़ी है जो उससे पिछले चौबीस घंटे खींच दे: load average, प्रोसेसर का उपयोग और अलग से I/O wait, मेमोरी और swap, डिस्क की पढ़ाई-लिखाई, पार्टीशन का भराव, inodes, फ़ाइल डिस्क्रिप्टर, कनेक्शन। एक ही समय-अक्ष पर जोड़े खुली आँख से पढ़े जाते हैं: शांत प्रोसेसर के साथ ऊँचा wa, वह swap जो कभी शून्य पर नहीं लौटा, सीमा के क़रीब पहुँचते डिस्क्रिप्टर — आने वाली त्रुटि too many open files घटित होने से घंटों पहले दिखने लगती है। यह सब एक साथ कैसा दिखता है, नीचे दिया डेमो पेज दिखाता है।