लोड (कंप्यूटिंग)
यूनिक्स कम्प्यूटिंग में, सिस्टम लोड कंप्यूटर सिस्टम द्वारा किए जाने वाले कम्प्यूटेशनल कार्य की मात्रा का माप है। जिससे लोड औसतन समय की अवधि में औसतन सिस्टम लोड का प्रतिनिधित्व करता है। अतः यह परंपरागत रूप से तीन संख्याओं के रूप में प्रकट होता है जो की अंतिम एक, पांच और पंद्रह मिनट की अवधि के समय सिस्टम लोड का प्रतिनिधित्व करता हैं।
यूनिक्स-शैली लोड गणना
इस प्रकार से सभी यूनिक्स और यूनिक्स जैसी सिस्टम कर्नेल (ऑपरेटिंग सिस्टम) में तीन लोड औसतन संख्याओं का आयामहीन सॉफ्टवेयर मीट्रिक उत्पन्न करती हैं। उपयोगकर्ता अपटाइमकमांड इसे चलाकर यूनिक्स शैल से वर्तमान परिणाम को सरलता से क्वेरी कर सकते हैं:
$ uptime
14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09
w और top कमांड समान तीन लोड औसत संख्याएं दिखाते हैं, जैसा कि ग्राफिकल यूज़र इंटरफ़ेस उपयोगिताओं की एक श्रृंखला होती है। लिनक्स में, उन्हें /proc/loadavg फ़ाइल को पढ़कर भी एक्सेस किया जा सकता है।
इस प्रकार से निष्क्रिय कंप्यूटर की लोड संख्या 0 होती है (निष्क्रिय प्रक्रिया की गणना नहीं की जाती है)। सेंट्रल प्रोसेसिंग यूनिट (तैयार क्रम या रन क्रम ) का उपयोग या प्रतीक्षा करने वाली प्रत्येक प्रक्रिया (कंप्यूटिंग) लोड संख्या को 1 से बढ़ाती है। प्रत्येक प्रक्रिया जो समाप्त होती है वह इसे 1 से घटाती है। और अधिकांश राज्य यूनिक्स सिस्टम केवल चलने वाली प्रक्रियाओं (सीपीयू पर) की गणना करते हैं या चलाने योग्य (सीपीयू की प्रतीक्षा कर रही) स्थिति में प्रक्रियाओं की गणना करते हैं। चूंकि , लिनक्स में अबाधित स्लीप स्टेट्स (सामान्यतः हार्ड डिस्क ड्राइव गतिविधि की प्रतीक्षा) में प्रक्रियाएँ भी सम्मिलित होती हैं, जो कि व्यस्त या रुके हुए I/O सिस्टम के कारण इनपुट/आउटपुट I/O में कई प्रक्रियाएँ अवरुद्ध रहने पर स्पष्ट रूप से भिन्न परिणाम हो सकते हैं।[1] इस प्रकार उदाहरण के लिए, इसमें नेटवर्क फ़ाइल सिस्टम सर्वर विफलता या अधिक धीमी आधार कंटेंट संचयन (उदाहरण के लिए, यूएसबी 1.x स्टोरेज डिवाइस) के कारण अवरुद्ध होने वाली प्रक्रियाएं सम्मिलित हैं। इस प्रकार की परिस्थितियों के परिणामस्वरूप लोड औसतन अधिक हो सकता है जो की सीपीयू उपयोग में वास्तविक वृद्धि को नहीं दर्शाता है (किन्तु अब तक यह अनुमान देता है कि उपयोगकर्ताओं को कितने समय तक प्रतीक्षा करना होगा)
सिस्टम लोड औसतन की गणना लोड संख्या के मूविंग एवरेज या एक्सपोनेंशियल मूविंग एवरेज एक्सपोनेंशियली डैम्प्ड/वेटेड मूविंग एवरेज के रूप में करते हैं। किन्तु लोड औसतन के तीन मान सिस्टम ऑपरेशन के पिछले एक, पांच और पंद्रह मिनट को संदर्भित करते हैं।[2]
चूंकि गणितीय रूप से कहें तो, सिस्टम प्रारंभ होने के पश्चात से सभी तीन मान सदैव पूर्ण सिस्टम लोड का औसत रखते हैं। वे सभी तीव्र से क्षय करते हैं किन्तु वे अलग-अलग गति से क्षय करते हैं: वे क्रमशः 1 5 और 15 मिनट के पश्चात ई द्वारा तीव्र से क्षय करते हैं। इसलिए, 1 मिनट के लोड औसत में अंतिम मिनट के लोड का 63% (अधिक स्पष्ट रूप से: 1 - 1/ई) और अंतिम मिनट को छोड़कर प्रारंभ के पश्चात से औसत लोड का 37% (1/ई) सम्मिलित है। अतः 5- और 15 मिनट के लोड औसत के लिए समान 63%/37% अनुपात की गणना क्रमशः 5 मिनट और 15 मिनट में की जाती है। इसलिए, यह विधियों के रूप से स्पष्ट नहीं है कि 1 मिनट के लोड औसत में केवल अंतिम 60 सेकंड की गतिविधि सम्मिलित की गई है क्योंकि इसमें अतीत की 37% गतिविधि सम्मिलित है किन्तु यह तथ्य सही है कि इसमें अधिकतर अंतिम मिनट सम्मिलित हैं।
व्याख्या
इस प्रकार से एकल-सीपीयू सिस्टम के लिए जो सीपीयू से जुड़े होते हैं, अनेक संबंधित समय अवधि के समय सिस्टम उपयोग के माप के रूप में लोड औसतन के अतिरिक्त में विचार कर सकता है। एकाधिक सीपीयू वाले सिस्टम के लिए, तुलनीय माप प्राप्त करने के लिए लोड को प्रोसेसर की संख्या से विभाजित करना होता है ।
अतः उदाहरण के लिए, कोई एकल-सीपीयू सिस्टम पर 1.73 0.60 7.98 के लोड औसतन की व्याख्या इस प्रकार कर सकते है:
- अंतिम मिनट के समय , सिस्टम औसतनन 73% ओवरलोड हो गया था (1.73 चलने योग्य प्रक्रियाएं, जिससे 0.73 प्रक्रियाओं को औसतनन एकल सीपीयू सिस्टम के लिए बारी का प्रतीक्षा करना पड़ा)।
- पिछले 5 मिनट के समय , सीपीयू औसतनन 40% समय निष्क्रिय रहा।
- पिछले 15 मिनटों के समय , सिस्टम औसतनन 698% ओवरलोड हो गया था (7.98 चलने योग्य प्रक्रियाएं, जिससे 6.98 प्रक्रियाओं को औसतनन एकल सीपीयू सिस्टम के लिए बारी का प्रतीक्षा करना पड़ा)।
इसका तथ्य यह है कि यह सिस्टम (सीपीयू, डिस्क, मेमोरी इत्यादि) यदि 1.73 गुना तीव्र होता तो अंतिम मिनट के लिए निर्धारित सभी कार्यों को संभाल सकता था।
चुकी चार सीपीयू वाले सिस्टम में, 3.73 का लोड औसतन इंगित करेगा कि औसतनन 3.73 प्रक्रियाएं चलने के लिए तैयार थीं, और प्रत्येक को सीपीयू में शेड्यूल किया जा सकता था।
अतः आधुनिक यूनिक्स प्रणालियों पर, लोड औसत के संबंध में थ्रेड (कंप्यूटिंग) का उपचार भिन्न होता है। कुछ सिस्टम लोड औसत गणना के प्रयोजनों के लिए थ्रेड्स को प्रक्रियाओं के रूप में मानते हैं: चलने की प्रतीक्षा कर रहा प्रत्येक थ्रेड लोड में 1 जोड़ देगा। चूंकि , अन्य सिस्टम, विशेष रूप से तथाकथित एम:एन थ्रेडिंग प्रयुक्त करने वाली सिस्टम, विभिन्न रणनीतियों का उपयोग करती हैं जैसे लोड के उद्देश्य के लिए प्रक्रिया को एक बार गिनना (थ्रेड्स की संख्या की परवाह किए बिना), या केवल वर्तमान में उपयोगकर्ता द्वारा उजागर किए गए थ्रेड्स की गिनती करना- कर्नेल के लिए थ्रेड शेड्यूलर, जो प्रक्रिया पर निर्धारित समवर्ती स्तर पर निर्भर हो सकता है। ऐसा प्रतीत होता है कि लिनक्स प्रत्येक थ्रेड को लोड में 1 जोड़कर अलग से गिनता है[3]
सीपीयू लोड बनाम सीपीयू उपयोग
इस प्रकार से फेरारी एट अल द्वारा किए गए विभिन्न लोड सूचकांकों का तुलनात्मक अध्ययन किया गया था।[4] जिसमे बताया गया कि सीपीयू क्रम की लंबाई के आधार पर सीपीयू लोड सूचना सीपीयू उपयोग की तुलना में लोड संतुलन में अधिक श्रेष्ट करती है। और सीपीयू क्रम की लंबाई श्रेष्ट होने का कारण कदाचित् यह है कि जब होस्ट भारी लोड होता है, तब इसका सीपीयू उपयोग 100% के समीप होने की संभावना होती है और यह उपयोग के स्पष्ट लोड स्तर को प्रतिबिंबित करने में असमर्थ होता है। इसके विपरीत, सीपीयू क्रम की लंबाई सीधे सीपीयू पर लोड की मात्रा को प्रतिबिंबित कर सकती है। इस प्रकार उदाहरण के लिए , दो सिस्टम, 3 के साथ और दूसरी क्रम में 6 प्रक्रियाओं के साथ, दोनों में 100% के समीप उपयोग होने की अधिक संभावना है, चूंकि वे स्पष्ट रूप से भिन्न होते हैं।
सीपीयू लोड की गणना
लिनक्स सिस्टम पर, लोड-औसतन की गणना प्रत्येक क्लॉक टिक पर नहीं की जाती है, किन्तु वैरिएबल मान द्वारा संचालित होती है जो एचजेड आवृत्ति सेटिंग पर आधारित होती है और प्रत्येक क्लॉक टिक पर परीक्षण की जाती है। यह सेटिंग हेटर्स (प्रति सेकंड समय) में कर्नेल क्लॉक टिक दर को परिभाषित करती है, और यह 10एमएस टिक के लिए 100 पर डिफ़ॉल्ट होती है। कर्नेल गतिविधियाँ स्वयं समय निर्धारित करने के लिए इस संख्या में टिक का उपयोग करती हैं। विशेष रूप से, टाइमर.सी::कैल्क_लोड() फ़ंक्शन, जो लोड औसतन की गणना करता है, और प्रत्येक समय चलता रहता है LOAD_FREQ = (5*HZ+1) टिक, या लगभग हर पांच सेकंड में चलता है:
unsigned long avenrun[3];
static inline void calc_load(unsigned long ticks)
{
unsigned long active_tasks; /* fixed-point */
static int count = LOAD_FREQ;
count -= ticks;
if (count < 0) {
count += LOAD_FREQ;
active_tasks = count_active_tasks();
CALC_LOAD(avenrun[0], EXP_1, active_tasks);
CALC_LOAD(avenrun[1], EXP_5, active_tasks);
CALC_LOAD(avenrun[2], EXP_15, active_tasks);
}
}
अतः एवनरून सरणी में 1-मिनट, 5-मिनट और 15-मिनट का औसतन होता है। CALC_LOAD}AD मैक्रो और उससे संबंधित मान शेड्यूल.h में परिभाषित हैं:
#define FSHIFT 11 /* nr of bits of precision */
#define FIXED_1 (1<<FSHIFT) /* 1.0 as fixed-point */
#define LOAD_FREQ (5*HZ+1) /* 5 sec intervals */
#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */
#define EXP_5 2014 /* 1/exp(5sec/5min) */
#define EXP_15 2037 /* 1/exp(5sec/15min) */
#define CALC_LOAD(load,exp,n) \
load *= exp; \
load += n*(FIXED_1-exp); \
load >>= FSHIFT;
इस प्रकार से लोड औसतन की नमूना गणना कुछ सीमा तक सामान्य व्यवहार है; फ्रीबीएसडी भी प्रत्येक पांच सेकंड में केवल मूल्य को ताज़ा करता है। सामान्यतः अंतराल को स्पष्ट नहीं माना जाता है जिससे वे उन प्रक्रियाओं को एकत्र न करें जो निश्चित समय पर सक्रिय होने के लिए निर्धारित हैं।[5]
चूंकि लिनक्स मेलिंग सूची पर पोस्ट इस प्रकार के संग्रह से मोइर कलाकृतियों से बचने के लिए इसके +1 टिक को अपर्याप्त मानता है, और इसके अतिरिक्त 4.61 सेकंड के अंतराल का सुझाव देता है।[6] यह परिवर्तन एंड्रॉइड सिस्टम कर्नेल के मध्य समान होते है, चूंकि उपयोग की गई स्पष्ट अभिव्यक्ति 100 के एचजेड को मानती है।[7]
अन्य सिस्टम प्रदर्शन आदेश
सिस्टम प्रदर्शन का आकलन करने के लिए अन्य आदेशों में सम्मिलित हैं:
uptime– सिस्टम विश्वसनीयता और लोड औसतन- शीर्ष (यूनिक्स)|
top– समग्र सिस्टम दृश्य के लिए - वीएमस्टैट (यूनिक्स)|
vmstat– vmstat चलने योग्य या अवरुद्ध प्रक्रियाओं, मेमोरी, पेजिंग, ब्लॉक I/O, ट्रैप्स और CPU के अतिरिक्त में सूचना रिपोर्ट करता है। - एचटॉप (यूनिक्स)|
htop– इंटरैक्टिव प्रक्रिया दर्शक dool(पूर्व मेंdstat),[8]atop– प्रक्रियाओं, मेमोरी, पेजिंग, ब्लॉक I/O, ट्रैप्स और सीपीयू गतिविधि के लिए सभी मौजूदा संसाधन डेटा को सहसंबंधित करने में सहायता करता है।- iftop|
iftop– इंटरैक्टिव नेटवर्क ट्रैफ़िक व्यूअर प्रति इंटरफ़ेस nethogs– प्रति प्रक्रिया इंटरैक्टिव नेटवर्क ट्रैफ़िक व्यूअरiotop– इंटरैक्टिव I/O व्यूअर[9]- आयोस्टैट (यूनिक्स)|
iostat– संचयन I/O आँकड़ों के लिए - नेटस्टैट (यूनिक्स)|
netstat– नेटवर्क आँकड़ों के लिए mpstat– सीपीयू आँकड़ों के लिएtload– टर्मिनल के लिए औसतन ग्राफ़ लोड करेंxload– एक्स के लिए औसतन ग्राफ़ लोड करें/proc/loadavg– लोड औसतन वाली टेक्स्ट फ़ाइल
यह भी देखें
संदर्भ
- ↑ "Linux Tech Support: What exactly is a load average?". 23 October 2008.
- ↑ Walker, Ray (1 December 2006). "लोड औसत की जांच करना". Linux Journal. Retrieved 13 March 2012.
- ↑ See http://serverfault.com/a/524818/27813
- ↑ Ferrari, Domenico; and Zhou, Songnian; "An Empirical Investigation of Load Indices For Load Balancing Applications", Proceedings of Performance '87, the 12th International Symposium on Computer Performance Modeling, Measurement, and Evaluation, North Holland Publishers, Amsterdam, The Netherlands, 1988, pp. 515–528
- ↑ "How is load average calculated on FreeBSD?". Unix & Linux Stack Exchange.
- ↑ Ripke, Klaus (2011). "Linux-Kernel Archive: LOAD_FREQ (4*HZ+61) avoids loadavg Moire". lkml.iu.edu. graph & patch
- ↑ "Patch kernel with the 4.61s load thing · Issue #2109 · AOSC-Dev/aosc-os-abbs". GitHub (in English).
- ↑ Baker, Scott (September 28, 2022). "dool - Python3 compatible clone of dstat". GitHub. Retrieved November 22, 2022.
...Dag Wieers ceased development of Dstat...
- ↑ "Iotop(8) - Linux manual page".
बाहरी संबंध
- Brendan Gregg (8 August 2017). "Linux Load Averages: Solving the Mystery". Retrieved 2018-01-22.
- Neil J. Gunther. "UNIX Load Average – Part 1: How It Works" (PDF). TeamQuest. Retrieved 2009-08-12.
- Andre Lewis (31 July 2009). "Understanding Linux CPU Load – when should you be worried?". Retrieved 2011-07-21. Explanation using an illustrated traffic analogy.
- Ray Walker (1 December 2006). "Examining Load Average". Linux Journal. Retrieved 2011-07-21.
- Karsten Becker. "Linux OSS load monitoring toolset". LoadAvg.
