लोड (कंप्यूटिंग)
UNIX कम्प्यूटिंग में, सिस्टम लोड कंप्यूटर सिस्टम द्वारा किए जाने वाले कम्प्यूटेशनल कार्य की मात्रा का माप है। लोड औसत समय की अवधि में औसत सिस्टम लोड का प्रतिनिधित्व करता है। यह परंपरागत रूप से तीन संख्याओं के रूप में प्रकट होता है जो अंतिम एक-, पांच- और पंद्रह मिनट की अवधि के दौरान सिस्टम लोड का प्रतिनिधित्व करते हैं।
यूनिक्स-शैली लोड गणना
सभी यूनिक्स और यूनिक्स जैसी प्रणालियाँ कर्नेल (ऑपरेटिंग सिस्टम) में तीन लोड औसत संख्याओं का आयामहीन सॉफ्टवेयर मीट्रिक उत्पन्न करती हैं। उपयोगकर्ता इसे चलाकर यूनिक्स शैल से वर्तमान परिणाम को आसानी से क्वेरी कर सकते हैं uptime आज्ञा:
$ uptime
14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09
डब्ल्यू (यूनिक्स)|wऔर टॉप (यूनिक्स)|topकमांड समान तीन लोड औसत संख्याएँ दिखाते हैं, जैसा कि ग्राफिकल यूज़र इंटरफ़ेस उपयोगिताओं की श्रृंखला होती है। लिनक्स में, उन्हें procfs| को पढ़कर भी एक्सेस किया जा सकता है/proc/loadavgफ़ाइल।
निष्क्रिय कंप्यूटर की लोड संख्या 0 होती है (निष्क्रिय प्रक्रिया की गणना नहीं की जाती है)। सेंट्रल प्रोसेसिंग यूनिट (तैयार कतार या रन कतार) का उपयोग या प्रतीक्षा करने वाली प्रत्येक प्रक्रिया (कंप्यूटिंग) लोड संख्या को 1 से बढ़ाती है। प्रत्येक प्रक्रिया जो समाप्त होती है वह इसे 1 से घटाती है। अधिकांश यूनिक्स सिस्टम केवल चलने वाली प्रक्रियाओं (सीपीयू पर) की गणना करते हैं या चलाने योग्य (सीपीयू की प्रतीक्षा में) प्रक्रिया स्थिति। हालाँकि, लिनक्स में अबाधित स्लीप स्टेट्स (आमतौर पर हार्ड डिस्क ड्राइव गतिविधि की प्रतीक्षा) में प्रक्रियाएँ भी शामिल हैं, जो कि व्यस्त या रुके हुए I/O सिस्टम के कारण इनपुट/आउटपुट|I/O में कई प्रक्रियाएँ अवरुद्ध रहने पर स्पष्ट रूप से भिन्न परिणाम दे सकती हैं। .[1] उदाहरण के लिए, इसमें नेटवर्क फ़ाइल सिस्टम सर्वर विफलता या बहुत धीमी आधार सामग्री भंडारण (उदाहरण के लिए, USB 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 प्रक्रियाएं चलने के लिए तैयार थीं, और प्रत्येक को सीपीयू में शेड्यूल किया जा सकता था।
आधुनिक UNIX प्रणालियों पर, लोड औसत के संबंध में थ्रेड (कंप्यूटिंग) का उपचार भिन्न होता है। कुछ सिस्टम लोड औसत गणना के प्रयोजनों के लिए थ्रेड्स को प्रक्रियाओं के रूप में मानते हैं: चलने की प्रतीक्षा कर रहा प्रत्येक थ्रेड लोड में 1 जोड़ देगा। हालाँकि, अन्य प्रणालियाँ, विशेष रूप से तथाकथित थ्रेड (कंप्यूटिंग)#M:N (हाइब्रिड थ्रेडिंग)|M:N थ्रेडिंग को लागू करने वाली प्रणालियाँ, विभिन्न रणनीतियों का उपयोग करती हैं जैसे कि लोड के उद्देश्य के लिए प्रक्रिया को ठीक बार गिनना (संख्या की परवाह किए बिना) थ्रेड्स), या केवल वर्तमान में उपयोगकर्ता-थ्रेड शेड्यूलर द्वारा कर्नेल के संपर्क में आने वाले थ्रेड्स की गिनती करना, जो प्रक्रिया पर निर्धारित समवर्ती स्तर पर निर्भर हो सकता है। ऐसा प्रतीत होता है कि लिनक्स प्रत्येक थ्रेड को लोड में 1 जोड़कर अलग से गिनता है।[3]
सीपीयू लोड बनाम सीपीयू उपयोग
फेरारी एट अल द्वारा किए गए विभिन्न लोड सूचकांकों का तुलनात्मक अध्ययन।[4] बताया गया कि सीपीयू कतार की लंबाई के आधार पर सीपीयू लोड जानकारी सीपीयू उपयोग की तुलना में लोड संतुलन में बहुत बेहतर करती है। सीपीयू कतार की लंबाई बेहतर होने का कारण शायद यह है कि जब होस्ट भारी लोड होता है, तो इसका सीपीयू उपयोग 100% के करीब होने की संभावना होती है और यह उपयोग के सटीक लोड स्तर को प्रतिबिंबित करने में असमर्थ होता है। इसके विपरीत, सीपीयू कतार की लंबाई सीधे सीपीयू पर लोड की मात्रा को प्रतिबिंबित कर सकती है। उदाहरण के तौर पर, दो प्रणालियाँ, 3 के साथ और दूसरी कतार में 6 प्रक्रियाओं के साथ, दोनों में 100% के करीब उपयोग होने की बहुत संभावना है, हालांकि वे स्पष्ट रूप से भिन्न हैं।
सीपीयू लोड की गणना
लिनक्स सिस्टम पर, लोड-औसत की गणना प्रत्येक क्लॉक टिक पर नहीं की जाती है, बल्कि वैरिएबल मान द्वारा संचालित होती है जो एचजेड आवृत्ति सेटिंग पर आधारित होती है और प्रत्येक क्लॉक टिक पर परीक्षण की जाती है। यह सेटिंग हेटर्स ़ (प्रति सेकंड समय) में कर्नेल क्लॉक टिक दर को परिभाषित करती है, और यह 10ms टिक के लिए 100 पर डिफ़ॉल्ट होती है। कर्नेल गतिविधियाँ स्वयं समय निर्धारित करने के लिए इस संख्या में टिक का उपयोग करती हैं। विशेष रूप से, timer.c::calc_load() फ़ंक्शन, जो लोड औसत की गणना करता है, हर बार चलता है 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.
