التحميل (الحوسبة)

📅 آخر تحديث: ١٨ يوليو ٢٠٢٦
✍️ نُشر في: ١٨ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

يعرض برنامج htop حملاً حاسوبياً كبيراً (أعلى اليمين: متوسط ​​الحمل: )

في أنظمة يونكس ، يُعدّ حمل النظام مقياسًا لحجم العمليات الحسابية التي يُجريها نظام الحاسوب. ويمثل متوسط ​​الحمل متوسط ​​حمل النظام خلال فترة زمنية محددة. ويظهر عادةً على شكل ثلاثة أرقام تُشير إلى حمل النظام خلال الدقائق الأخيرة (دقيقة واحدة، خمس دقائق، وخمس عشرة دقيقة).

حمولة

يشير رقم التحميل في نظام يونكس إلى عدد العمليات التي تستخدم وحدة المعالجة المركزية أو تنتظرها ؛ أي عدد العمليات في قائمة الانتظار أو قائمة التشغيل . يكون رقم التحميل لجهاز كمبيوتر خامل صفرًا (لا تُحتسب العملية الخاملة). كل عملية قيد التشغيل تزيد رقم التحميل بمقدار 1، وكل عملية تنتهي تُنقصه بمقدار 1. تحسب معظم أنظمة يونكس العمليات في حالتي التشغيل (على وحدة المعالجة المركزية) أو الجاهزية (في انتظار وحدة المعالجة المركزية) فقط (الحالة R).

بالإضافة إلى العمليات في حالة "R"، يتضمن نظام لينكس أيضًا عمليات في حالات سكون غير قابلة للمقاطعة (عادةً ما تنتظر نشاط القرص ؛ الحالة "D")، مما قد يؤدي إلى نتائج مختلفة بشكل ملحوظ إذا ظلت العديد من العمليات عالقة في عمليات الإدخال/الإخراج بسبب انشغال نظام الإدخال/الإخراج أو توقفه. [ 1 ] يشمل ذلك، على سبيل المثال، العمليات العالقة بسبب فشل خادم NFS أو بطء وسائط التخزين (مثل أجهزة تخزين USB 1.x). يمكن أن تؤدي هذه الظروف إلى ارتفاع متوسط ​​الحمل، وهو ما لا يعكس زيادة فعلية في استخدام وحدة المعالجة المركزية. تكمن الفكرة وراء تضمين هذه الحالة في أنه على الرغم من أن انتظار القرص ليس هو نفسه انتظار وحدة المعالجة المركزية، إلا أنه لا يزال يعكس المدة التي يحتاجها المستخدم للانتظار.

في أنظمة يونكس الحديثة، يختلف التعامل مع الخيوط فيما يتعلق بمتوسطات الحمل. فبعض الأنظمة تتعامل مع الخيوط كعمليات لأغراض حساب متوسط ​​الحمل: حيث يضيف كل خيط ينتظر التشغيل 1 إلى الحمل. بينما تستخدم أنظمة أخرى، وخاصةً تلك التي تُطبّق ما يُسمى بخيوط M:N ، استراتيجيات مختلفة، مثل احتساب العملية مرة واحدة فقط لغرض حساب الحمل (بغض النظر عن عدد الخيوط)، أو احتساب الخيوط التي يُتيحها مُجدول خيوط المستخدم للنواة فقط، وهو ما قد يعتمد على مستوى التزامن المُحدد للعملية. ويبدو أن لينكس يحسب كل خيط على حدة، مُضيفًا 1 إلى الحمل. [ 2 ]

لا توجد طريقة قياسية لمعرفة طول قائمة انتظار التشغيل في أنظمة يونكس المختلفة، [ أ ] ولكن إحدى الطرق الشائعة هي تحليل مخرجات أمر ps ، وتحديدًا ps ps -ax -o stat، وحساب عدد الأسطر التي تبدأ بالحرف "R" (والتي تُشير إلى العمليات في حالة "R"). ويمكن إضافة حالة انتظار "القرص" غير القابلة للمقاطعة ، والمُشار إليها بالحرف "D" في لينكس وفري بي إس دي، والحرف "U" في ماك أو إس ، إذا رُغب في ذلك . -Mويمكن استخدام ps للحصول على معلومات لكل مؤشر ترابط في لينكس وماك أو إس، ولكن ليس في فري بي إس دي، حيث يكون الخيار ps هو ps -H. [ 4 ] (لن يكون الحمل المُبلغ عنه صفرًا أبدًا، لأن psالعملية نفسها تُحسب. وللحصول على الحمل الحقيقي، اطرح واحدًا من العدد).

في نظام لينكس تحديدًا، يحتوي ملف procfs/proc/stat على سطرين procs_running، أحدهما procs_blockedيمثل حالة "R" والآخر يمثل حالة "D"، وكلاهما يمثلان كيانات الجدولة (العمليات/الخيوط) في حالتي "R" و"D" على التوالي. يمكن استخدام هذا الملف لقراءة الحمل الحالي بدلًا من قراءة psقيمة الحمل السابقة. وكما في السابق، يشمل الحمل المُبلغ عنه البرنامج الذي يقرأ ملف procfs حاليًا، لذا اطرح واحدًا من المجموع للحصول على الحمل الحقيقي. [ 5 ]

مقارنة باستخدام وحدة المعالجة المركزية

أظهرت دراسة مقارنة لمؤشرات الحمل المختلفة أجراها فيراري وآخرون أن معلومات حمل وحدة المعالجة المركزية المستندة إلى طول قائمة انتظار وحدة المعالجة المركزية تُحقق توازنًا أفضل بكثير في الحمل مقارنةً باستخدام وحدة المعالجة المركزية. ولعل السبب في تفوق طول قائمة انتظار وحدة المعالجة المركزية هو أنه عندما يكون المضيف مُحملاً بشكل كبير، فمن المرجح أن يكون استخدام وحدة المعالجة المركزية قريبًا من 100%، ولا يعكس هذا الطول مستوى الحمل الفعلي. في المقابل، يُمكن لطول قائمة انتظار وحدة المعالجة المركزية أن يعكس مباشرةً مقدار الحمل الواقع على وحدة المعالجة المركزية. على سبيل المثال، من المرجح جدًا أن يكون استخدام نظامين، أحدهما يحتوي على 3 عمليات والآخر على 6 عمليات في قائمة الانتظار، قريبًا من 100%، على الرغم من اختلافهما الواضح من حيث أوقات انتظار العمليات. [ 6 ]

متوسط ​​التحميل

تُنتج جميع أنظمة يونكس والأنظمة الشبيهة بيونكس مقياسًا لا بُعديًا لثلاثة أرقام "متوسط ​​الحمل" في النواة . يمكن للمستخدمين الاستعلام بسهولة عن النتيجة الحالية من خلال سطر أوامر يونكس عن طريق تشغيل uptimeالأمر التالي:

$ uptime 14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09

تُظهر الأوامر w`and` topنفس متوسطات الحمل الثلاثة، كما تفعل مجموعة من أدوات واجهة المستخدم الرسومية . الواجهة الأساسية هي `data` getloadavg()، وهي دالة مكتوبة بلغة C موجودة في معظم أنظمة UNIX منذ إصدار 4.3BSD-Reno عام 1990 (لكنها ليست جزءًا من معيار POSIX ). [ 7 ] في نظام Linux تحديدًا، يمكن أيضًا قراءة `data` /proc/loadavgللحصول على هذه المعلومات. يوفر هذا الملف أيضًا معلومات فورية عن عدد العمليات في حالة "R"، والعدد الإجمالي للعمليات، ومعرّف العملية التي تم إنشاؤها مؤخرًا. [ 8 ]

تحسب الأنظمة متوسط ​​الحمل كمتوسط ​​متحرك مرجح/مخمّد أُسّيًا لرقم الحمل . تشير القيم الثلاث لمتوسط ​​الحمل إلى الدقائق الـ 1 و5 و15 الماضية من تشغيل النظام. [ 9 ]

رياضيًا، تمثل القيم الثلاث جميعها متوسط ​​حمل النظام منذ بدء تشغيله. تتناقص هذه القيم أُسّيًا، ولكن بسرعات مختلفة : تتناقص أُسّيًا بمقدار e بعد دقيقة واحدة، و5 دقائق، و15 دقيقة على التوالي. بالتالي، يتكون متوسط ​​الحمل لمدة دقيقة واحدة من 63% (بدقة أكبر: 1 - 1/ e ) من الحمل في الدقيقة الأخيرة، و37% (1/ e ) من متوسط ​​الحمل منذ بدء التشغيل، باستثناء الدقيقة الأخيرة. بالنسبة لمتوسطي الحمل لمدة 5 دقائق و15 دقيقة، تُحسب النسبة نفسها 63%/37% على مدى 5 دقائق و15 دقيقة على التوالي. لذلك، ليس من الدقة الفنية القول بأن متوسط ​​الحمل لمدة دقيقة واحدة يشمل فقط آخر 60 ثانية من النشاط، لأنه يشمل 37% من النشاط السابق، ولكن من الصحيح القول إنه يشمل في الغالب الدقيقة الأخيرة.

تفسير

بالنسبة للأنظمة أحادية المعالج التي تعتمد بشكل كبير على المعالج ، يمكن اعتبار متوسط ​​الحمل مقياسًا لاستخدام النظام خلال الفترة الزمنية المحددة. أما بالنسبة للأنظمة متعددة المعالجات، فيجب قسمة الحمل على عدد المعالجات للحصول على مقياس قابل للمقارنة.

على سبيل المثال، يمكن تفسير متوسط ​​الحمل "1.73 0.60 7.98" على نظام بمعالج واحد على النحو التالي:

  • خلال الدقيقة الأخيرة، تم تحميل النظام بنسبة 73٪ في المتوسط ​​(1.73 عملية قابلة للتشغيل، بحيث كان على 0.73 عملية الانتظار للحصول على دور لنظام وحدة المعالجة المركزية الواحدة في المتوسط).
  • خلال الدقائق الخمس الأخيرة، كان المعالج المركزي في وضع الخمول بنسبة 40% من الوقت، في المتوسط.
  • خلال الدقائق الخمس عشرة الماضية، كان النظام محملاً بنسبة 698% في المتوسط ​​(7.98 عملية قابلة للتشغيل، بحيث كان على 6.98 عملية الانتظار للحصول على دور لنظام وحدة المعالجة المركزية الواحدة في المتوسط).

وهذا يعني أن هذا النظام كان بإمكانه التعامل مع جميع الأعمال المقررة للدقيقة الأخيرة إذا كان أسرع بمقدار 1.73 مرة.

في نظام بأربعة معالجات، يشير متوسط ​​الحمل البالغ 3.73 إلى وجود 3.73 عملية جاهزة للتنفيذ في المتوسط. ولأن هذا العدد أقل من 4، نعلم أنه يمكن جدولة كل عملية على معالج، وأنه لا يوجد تحميل زائد.

حساب حمل وحدة المعالجة المركزية

لينكس كمثال

في أنظمة لينكس، لا يُحسب متوسط ​​الحمل مع كل نبضة ساعة، بل يُعتمد على قيمة متغيرة تستند إلى HZإعداد التردد وتُختبر مع كل نبضة ساعة. يُحدد هذا الإعداد معدل نبضات ساعة النواة بالهرتز (عدد النبضات في الثانية)، وقيمته الافتراضية 100.دورات زمنية مقدارها 10 مللي ثانية  . تستخدم أنشطة النواة هذا العدد من الدورات الزمنية لتحديد وقتها. تحديدًا، calc_load()الدالة (في loadavg.h، والتي كانت تُعرف سابقًا باسم sched.h)، والتي تحسب متوسط ​​الحمل، تعمل اسميًا كل LOAD_FREQ (5*HZ+1)دورة زمنية، أي بعد فترة زمنية قصيرة جدًا.5  ثوانٍ .

extern unsigned long avenrun []; /* متوسطات التحميل */ extern void get_avenrun ( unsigned long * loads , unsigned long offset , int shift );#define FSHIFT 11 /* عدد بتات الدقة */ #define FIXED_1 (1<<FSHIFT) /* 1.0 كنقطة ثابتة */ #define LOAD_FREQ (5*HZ+1) /* فترات 5 ثوانٍ */ #define EXP_1 1884 /* 1/exp(5sec/1min) كنقطة ثابتة */ #define EXP_5 2014 /* 1/exp(5sec/5min) */ #define EXP_15 2037 /* 1/exp(5sec/15min) *//* a1 = a0 * e + a * (1 - e) */ static inline unsigned long calc_load ( unsigned long load , unsigned long exp , unsigned long active ) { unsigned long newload ;newload = load * exp + active * ( FIXED_1 - exp ); if ( active >= load ) newload += FIXED_1 -1 ;return newload / FIXED_1 ; }extern unsigned long calc_load_n ( unsigned long load , unsigned long exp , unsigned long active , unsigned int n );#define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)

تحتوي مصفوفة avenrun على متوسطات دقيقة واحدة، وخمس دقائق، وخمس عشرة دقيقة. calc_load()توفر الدالة التحديث الصحيح لمتوسط ​​الحمل لمعدل التحديث الافتراضي LOAD_FREQ (5*HZ+1). [ 10 ] تُستخدم على النحو التالي في ملف loadavg.c (المعروف سابقًا باسم sched.c): [ 11 ]

void calc_global_load ( void ) { unsigned long sample_window ; long active , delta ;sample_window = READ_ONCE ( calc_load_update ); if ( time_before ( jiffies , sample_window + 10 )) return ;/*  * قم بطي قيمة NO_HZ-delta القديمة لتشمل جميع وحدات المعالجة المركزية NO_HZ.  */ delta = calc_load_nohz_read (); if ( delta ) atomic_long_add ( delta , & calc_load_tasks );active = atomic_long_read ( & calc_load_tasks ); active = active > 0 ? active * FIXED_1 : 0 ;avenrun [ 0 ] = calc_load ( avenrun [ 0 ], EXP_1 , active ); avenrun [ 1 ] = calc_load ( avenrun [ 1 ], EXP_5 , active ); avenrun [ 2 ] = calc_load ( avenrun [ 2 ], EXP_15 , active );WRITE_ONCE ( calc_load_update , sample_window + LOAD_FREQ );/*  * في حال انتقلنا إلى NO_HZ لفترات LOAD_FREQ متعددة  * يتم اللحاق بالركب دفعة واحدة.  */ calc_global_nohz (); }

لاحظ كيفية التعامل مع وحدات المعالجة المركزية NO_HZ. NO_HZ هو وضع مصمم لتقليل عدد مقاطعات ساعة الجدولة على المعالجات الخاملة، مما يحسن كفاءة استهلاك الطاقة ويقلل من اضطراب الساعة. مع ذلك، قد يؤدي هذا إلى تفويت المعالجات لتحديثاتها. ونتيجة لذلك، يتم حساب المهام باستخدام عمليات ذرية. calc_global_nohzتتولى الدالة إجراء الحساب في حالة الحاجة إلى اللحاق بعدة تحديثات، وذلك باستخدام هذه الدالة:

/* [1] تطبيق المتسلسلة الهندسية: * n 1 - x^(n+1) * S_n := \Sum x^i = ------------- * i=0 1 - x */ unsigned long calc_load_n ( unsigned long load , unsigned long exp , unsigned long active , unsigned int n ) { return calc_load ( load , fixed_power_int ( exp , FSHIFT , n ), active ); }

هنا fixed_power_int(غير مدرج في المقال) يرفع exp إلى قوته n في حساب النقطة الثابتة.

أخذ العينات والدقة

يُعدّ حساب متوسطات الأحمال "باستخدام العينات" سلوكًا شائعًا إلى حد ما؛ فنظام FreeBSD أيضًا يُحدّث القيمة كل خمس ثوانٍ فقط. وعادةً ما تُعتبر هذه الفترة غير دقيقة تمامًا حتى لا يتم جمع العمليات المُجدولة للتشغيل في لحظة مُحددة. وهذا هو سبب استخدام "+1" في كود Linux المذكور أعلاه؛ بينما يستخدم FreeBSD بدلًا من ذلك إزاحة شبه عشوائية تُضاف إلى الفترة. [ 12 ]

loadavg.hويشير أيضًا إلى أن استخدام 11 بتًا كسريًا في حساب النقطة الثابتة المذكور أعلاه يمنع تقليل الفاصل الزمني ( LOAD_FREQ) إلى قيمة أقل بكثير. على سبيل المثال، سيؤدي فاصل زمني مدته ثانيتان إلى أن تصبح قيم EXP هي 1981 و2034 و2043، مما يؤدي إلى تشبع الدقة المتاحة تقريبًا (0 – 2047). [ 10 ]

أظهر ريبك كلاوس في عام 2011 أن تعديل "+1" وحده لا يكفي لتجنب تشوهات موير الناتجة عن العمليات المجدولة بانتظام. تشير تجاربه إلى أن 4.61 قيمة أفضل: 0.61 قريبة من النسبة الذهبية ، مما يساعد على توزيع نقطة العينة على أجزاء من الثانية. في الوقت نفسه، 4.61 قريبة من 60/13 ، لذا فإن خاصية5  s هو كسر صحيح من يتم الحفاظ على 60 ثانية . [ 13 ] [ 14 ] يُعد تغيير Ripke شائعًا بين نواة نظام Android ، على الرغم من أن التعبير المستخدم ( 4*HZ+61) يفترض قيمة HZ تساوي 100. [ 15 ]60*HZ/13 سيكون أكثر ملاءمة لقيم HZ المتغيرة. ستكون القيم الجديدة كما يلي: [ 14 ]

#define LOAD_FREQ (60*HZ/13) /* 60/13 ~ 4.61 ثانية فترات */ #define EXP_1 1896 /* 1/exp(4.61 ثانية/دقيقة واحدة) = 1/exp(1/13) كنقطة ثابتة */ #define EXP_5 2017 /* 1/exp(4.61 ثانية/5 دقائق) = 1/exp(1/13/5) */ #define EXP_15 2038 /* 1/exp(4.61 ثانية/15 دقيقة) = 1/exp(1/13/15) */

الحساب من مساحة المستخدم

كما ناقشنا سابقًا، تستخدم معظم أنظمة التشغيل حسابات النقطة الثابتة لحساب متوسط ​​الحمل، وذلك لتحقيق الكفاءة والبساطة. إلا أن هذا يحد من معدل التحديث والدقة الممكنة. وبما أننا قد حددنا كيفية الحصول على الحمل اللحظي من مساحة المستخدم، فمن الممكن أيضًا حساب متوسط ​​الحمل من مساحة المستخدم. يقوم الكود التالي بذلك بلغة بايثون، باستخدام معدل تحديث φ ≈ 1.618 ثانية ، على فترات زمنية تتراوح من 10 ثوانٍ إلى ساعة واحدة.

#!/usr/bin/env python3وقت الاستيراداستيراد نظام التشغيلمن datetime استورد datetimeمن الرياضيات استورد exp و logfrom dataclasses import dataclassLOGSYSPERIODS = [ log ( x ) for x in [ 60 , 300 , 900 ]]معدل التحديث = (( 5 ** 0.5 ) + 1 ) / 2 # النسبة الذهبية لريبكالفترات = [ 10 ، 30 ، 60 ، 120 ، 300 ، 900 ، 1800 ، 3600 ]COUNT_DISKWAIT = True # ما إذا كان سيتم تضمين انتظار القرص في حساب الحمل@dataclassفئة LoadEntry :المتوسط : عدد عشريexp : floatdef initialize_loads ( now : int | float , lavgs : dict [ int , LoadEntry ]):"""تهيئة متوسطات الأحمال بناءً على الاستيفاء الخطي لمتوسطات أحمال النظام وعدد الأحمال اللحظية."""sys = getloadavg ()المنحدرات = (( sys [ 0 ] - الآن ) / 60 ، ( sys [ 1 ] - sys [ 0 ]) / 240 ، ( sys [ 2 ] - sys [ 1 ]) / 600 )للفترة الزمنية في [ 10 ، 30 ، 60 ، 120 ، 300 ، 900 ، 1800 ، 3600 ]:exp_factor = exp ( - REFRESH_RATE / period )إذا كانت الفترة < 60 :est_avg = now + slopes [ 0 ] * ( period - 60 )elif period < 300 :est_avg = sys [ 0 ] + slopes [ 1 ] * ( period - 300 )آخر :est_avg = sys [ 1 ] + slopes [ 2 ] * ( period - 900 )lavgs [ period ] = LoadEntry ( avg = max ( est_avg , 0 ), exp = exp_factor )دالة تحديث_الأحمال ( lavgs : قاموس [ عدد صحيح ، LoadEntry ]، التحميل_الحالي : عدد صحيح | عدد عشري ) -> لا شيء :for _ , entry in lavgs . items ():entry.avg = entry.avg * entry.exp + current_load * ( 1 - entry.exp )​​​​​​​​إذا كان نظام التشغيل هو " posix" :uname = نظام التشغيل . اسم ()[ 0 ] . أدنى ()getloadavg = os.getloadavg​​إذا كان اسم النظام يساوي "linux" :دالة get_current_load () -> int :الحمل = 0with open ( "/proc/stat" , "r" ) as f :for line in f :إذا كان السطر يبدأ بـ " procs_running" :load += int ( line . split ()[ 1 ]) # قراءة procs_runningload -= 1 # اطرح واحدًا لأنفسناelif line . startswith ( "procs_blocked " ) and COUNT_DISKWAIT :load += int ( line . split ()[ 1 ]) # قراءة procs_blockedإرجاع التحميلآخر :PS_THREAD_OPTION = "-H" إذا كان os.uname ( )[ 0 ] .lower () . endswith ( " bsd" ) وإلا "-M "PS_DISK_WAIT = "U" إذا كان os.uname ( )[ 0 ] يساوي "Darwin" وإلا " D"PS_STATES = ( "R" + PS_DISK_WAIT ) إذا كان COUNT_DISKWAIT وإلا "R"دالة get_current_load () -> int :with os.popen ( f " ps { PS_THREAD_OPTION } ax -o stat" , " r" ) as f :states = map ( f , lambda line : line . split ()[ - 1 ]) # الحصول على العمود الأخير. مطلوب على نظام macOS!أعد مجموع ( 1 إذا كانت الحالة [ 0 ] في PS_STATES وإلا 0 لكل حالة في states ) - 1elif os.name == " nt " :# من الممكن استخدام عدادات أداء نظام التشغيل ويندوز للحصول على طول قائمة الانتظار.# في الواقع، توصي مايكروسوفت باستخدامه كمقياس إضافي للحمل بالإضافة إلى استخدام وحدة المعالجة المركزية:# https://learn.microsoft.com/en-us/biztalk/technical-guides/using-the-performance-analysis-of-logs-pal-tool#processor-queue-length-analysis# باستخدامها يمكننا أيضًا الحصول على حمل مشابه لأنظمة يونكس.from pyperfmon import pyperfmonpm = pyperfmon . pyperfmon ()ncores = os.cpu_count ( )​get_counter = lambda x : pm . getCounter ( x )def get_current_load () -> float :يعود (# الخيوط التي تنتظر وحدة المعالجة المركزية، وليست الخيوط قيد التشغيلget_counter ( r "System\Processor Queue Length" )# العدد التقريبي للخيوط التي تستخدم وحدة المعالجة المركزية+ get_counter ( r "Processor\_Total\% Processor Time" ) * ncores# الخيوط المنتظرة لعمليات الإدخال/الإخراج على القرص+ get_counter ( r "PhysicalDisk\_Total\Current Disk Queue Length" )إذا كان COUNT_DISKWAITوإلا 0)def getloadavg () -> tuple [ float , float , float ]:تطبيق وهمي لنظام التشغيل ويندوزload = get_current_load ()return ( load , load , load )def main ():lavgs : dict [ int , LoadEntry ] = {}current_load = get_current_load ()initialize_loads ( current_load , lavgs )heading = [ "SYSTIME" , " CURR" ] + [ str ( x ) for x in PERIODS ]print ( " \t " .join ( heading ) )بينما صحيح :# اطبع دائمًا قبل إعادة الحسابentries = [ f " { datetime . now () . strftime ( '%H:%M:%S' ) } { current_load : .4f } " ]entries += [ f " { entry . avg : .4f } " for entry in lavgs . values ​​()]print ( " \t " .join ( entries ) , flush = True )# النوم والانتظار. يفترض هذا أن الوقت المستغرق لتحديث سطر جديد هو# ضئيلة للغاية مقارنة بوقت النوم. إذا لم يكن الأمر كذلك، أ# يجب استخدام طريقة حساب الوقت من نوع sleepuntil().time.sleep ( REFRESH_RATE )​​# مطبعةcurrent_load = get_current_load ()تحديث_الأحمال ( lavgs , current_load )إذا كان __name__ يساوي "__main__" :رئيسي ()

أوامر أخرى متعلقة بأداء النظام

تتضمن الأوامر الأخرى لتقييم أداء النظام ما يلي:

  • uptime – موثوقية النظام ومتوسط ​​الحمل
  • top – للحصول على نظرة شاملة للنظام
    • htop – عارض العمليات التفاعلي
  • btop – أداة أخرى لعرض النظام بشكل عام
  • vmstat – يقدم vmstat معلومات حول العمليات القابلة للتنفيذ أو المحظورة، والذاكرة، والصفحات، وإدخال/إخراج الكتل، والمصائد، ووحدة المعالجة المركزية.
  • dool(سابقًا dstat)، [ 16 ] - يساعد في ربط جميع بيانات الموارد الموجودة للعمليات والذاكرة والصفحات وإدخال/إخراج الكتل والمصائد ونشاط وحدة المعالجة المركزية.atop 
  • iftop – عارض تفاعلي لحركة مرور الشبكة لكل واجهة
  • nethogs – عارض تفاعلي لحركة مرور الشبكة لكل عملية
  • iotop – عارض الإدخال/الإخراج التفاعلي [ 17 ]
  • iostat – لإحصائيات عمليات الإدخال/الإخراج للتخزين
  • netstat – لإحصائيات الشبكة
  • mpstat – لإحصائيات وحدة المعالجة المركزية
  • tload - تحميل الرسم البياني المتوسط ​​للطرفية
  • xload - تحميل الرسم البياني المتوسط ​​لـ X

انظر أيضاً

ملحوظات

  1. ↑ يوفر جزء XSI الاختياري من POSIX وظيفةًps -axlتُنتج مخرجات متعددة الأعمدة تحتوي على الحالة التي يمكن تحليلها. [ 3 ] لسوء الحظ، فإن تنفيذه أقل اتساقًا من سابقه-o statويتطلب جهدًا أكبر لتحليله.

مراجع

  1. ↑ "الدعم الفني لنظام لينكس: ما هو متوسط ​​الحمل بالضبط؟" . 23 أكتوبر 2008.
  2. ↑ انظر http://serverfault.com/a/524818/27813
  3. ↑ –مرجع الصدفة والأدوات المساعدة، مواصفات يونكس الموحدة ، الإصدار 5 من مجموعة Open Groupps  
  4. ↑
  5. ↑ "إحصائيات نواة متنوعة في /proc/stat" . تم الاطلاع عليه بتاريخ 4 أكتوبر 2023 .
  6. ↑ فيراري، دومينيكو؛ وتشو، سونغنيان؛ " دراسة تجريبية لمؤشرات الحمل لتطبيقات موازنة الأحمال "، وقائع مؤتمر الأداء 87، الندوة الدولية الثانية عشرة حول نمذجة أداء الحاسوب وقياسه وتقييمه، دار نشر نورث هولاند، أمستردام، هولندا، 1988، الصفحات 515-528
  7. ↑ – دليل استدعاءات نظام FreeBSDgetloadavg(2)  
  8. ↑ – دليل مبرمج لينكس – تنسيقات الملفات من Manned.orgproc_loadavg(5)  
  9. ↑ ووكر، راي (1 ديسمبر 2006). "دراسة متوسط ​​الحمل" . مجلة لينكس . تم الاطلاع عليه في 13 مارس 2012 .
  10. 1 2 "Linux v6.17 :: include/linux/sched/loadavg.h" . 
  11. ↑ "Linux v6.17 :: kernel/sched/loadavg.c" . 
  12. ↑ "كيف يتم حساب متوسط ​​الحمل على نظام FreeBSD؟" . موقع Unix & Linux Stack Exchange .
  13. ↑ ريبكه، كلاوس (2011). "أرشيف نواة لينكس: يتجنب التداخل" . lkml.iu.edu .LOAD_FREQ (4*HZ+61)loadavg
  14. 1 2 ريبكي، كلاوس (2011). "أنماط تموج في النسيج في متوسط ​​تحميل Linux" .(رسم بياني يوضح النمط؛ تعليق لاحق على 60 هرتز / 13)
  15. ↑ "تصحيح نواة النظام مع مشكلة التحميل التي تستغرق 4.61 ثانية · المشكلة رقم 2109 · AOSC-Dev/aosc-os-abbs" . GitHub .
  16. ↑ بيكر، سكوت (28 سبتمبر 2022). "dool - نسخة متوافقة مع بايثون 3 من dstat" . جيت هاب . تم الاطلاع عليه في 22 نوفمبر 2022. ... توقف داغ ويرز عن تطوير Dstat...
  17. ↑ "Iotop(8) - صفحة دليل لينكس" .