Load average: तीन नंबरों का मतलब

अपने VPS टियर पर load average को सही तरीके से कैसे पढ़ें, CPU खाली होने पर भी लोड ज़्यादा क्यों दिख सकता है, और कब नंबरों पर सच में ध्यान देने की ज़रूरत होती है।

23 अगस्त 2026 को अपडेट किया गया

uptime कमांड और htop की सबसे ऊपर वाली लाइन तीन नंबर दिखाती है — 1, 5 और 15 मिनट का औसत लोड। यह Linux का सबसे गलत समझा जाने वाला मेट्रिक है: इसे अक्सर CPU लोड समझ लिया जाता है।

असल में यह क्या है

लोड एवरेज उन प्रोसेस का औसत नंबर है जो या तो CPU पर कंप्यूट कर रही हैं या डिस्क का इंतज़ार कर रही हैं। दूसरा हिस्सा ही उलझन पैदा करता है: एक मशीन 12 का लोड दिखा सकती है, जबकि CPU लगभग खाली हो — अगर वे बारहों प्रोसेस डिस्क के इंतज़ार में कतार में लगी हों।

uptime
# 14:22:03 up 9 days,  2:41,  1 user,  load average: 3.41, 2.02, 1.15
cat /proc/loadavg
nproc          # how many cores your plan has

क्या नॉर्मल है, यह कोर की संख्या पर निर्भर करता है

अंगूठे का नियम आसान है: कोर की संख्या के बराबर लोड का मतलब है पूरी तरह व्यस्त मशीन, बिना किसी कतार के।

टियर	कोर	आरामदायक	व्यस्त	कतार में
VDS-1	1	0.7 तक	लगभग 1	2 से ज़्यादा
VDS-2	2	1.4 तक	लगभग 2	4 से ज़्यादा
VDS-3	4	2.8 तक	लगभग 4	8 से ज़्यादा
VDS-4	6	4 तक	लगभग 6	12 से ज़्यादा
VDS-5	8	5.5 तक	लगभग 8	16 से ज़्यादा
VDS-6	10	7 तक	लगभग 10	20 से ज़्यादा

तीनों नंबरों को एक ट्रेंड की तरह पढ़ें। 5.0, 2.0, 1.0 — लोड अभी-अभी बढ़ा है, हो सकता है आपने खुद कुछ शुरू किया हो। 1.0, 2.0, 5.0 — पीक बीत चुका है और मशीन अनलोड हो रही है। तीनों नंबर एक जैसे बड़े हों — लगातार ओवरलोड, और यही वह है जिसे ठीक करने की ज़रूरत है।

आगे कहाँ देखें

ज़्यादा लोड एक लक्षण है, निदान नहीं। कारणों को अलग-अलग करें:

vmstat 2 5

बड़ा r कॉलम (एक्ज़ीक्यूशन के लिए कतार में लगी प्रोसेस) और ज़्यादा us/sy — आप CPU लिमिट पर पहुँच रहे हैं। दोषी को htop में ढूँढें।
बड़ा b कॉलम और ज़्यादा wa — आप डिस्क लिमिट पर पहुँच रहे हैं। अगला कदम: iostat और iotop।
si/so बढ़ रहे हैं — स्वैपिंग चल रही है, यानी मेमोरी खत्म हो रही है, देखें मेमोरी और स्वैप।

htop में state D वाली प्रोसेस ही वे हैं जो I/O का इंतज़ार कर रही हैं और लोड एवरेज को ऊपर धकेल रही हैं।

ऊँचे टियर पर कब जाना चाहिए

प्रोजेक्ट बिल्ड, पैकेज अपडेट या रात के बैकअप के दौरान आने वाले एक-बार के स्पाइक्स को नज़रअंदाज़ करें। असली संकेत ऐसा दिखता है: पैनल /hosting/vds/m/<id> के साप्ताहिक CPU ग्राफ़ पर एक पठार बना रहता है, लोड एवरेज लगातार कोर की संख्या से ऊपर है, और दोषी आपका प्रोडक्शन एप्लिकेशन है, कोई भूला हुआ स्क्रिप्ट नहीं। तब ऊँचे टियर पर जाना समझ में आता है: आप सिर्फ़ ऊपर जा सकते हैं, पेड टर्म के बचे दिनों के लिए अतिरिक्त भुगतान के साथ।

आम गलतियाँ

लोड की तुलना 100% से करना। लोड एवरेज प्रतिशत नहीं है। VDS-3 पर 4 का मान पूरी तरह व्यस्त मशीन है, कोई आपदा नहीं।
सिर्फ़ पहला नंबर देखना। एक मिनट का औसत ज़रा-सी बात पर उछल जाता है। फ़ैसले 15 मिनट वाले पर होते हैं।
नोड पर पड़ोसियों को भूल जाना। vmstat में st (steal) कॉलम hypervisor द्वारा छीना गया समय दिखाता है। लगातार ज़्यादा मान सपोर्ट को लिखने की वजह है — यह आपकी समस्या नहीं है।

लोड एवरेज मेमोरी के बारे में कुछ नहीं बताता। एक मशीन 0.2 दिखा सकती है और फिर भी OOM killer चलने से एक कदम दूर हो सकती है।