مستوى المقال: مبتدئ. مناسب لو لسه بادئ في إدارة سيرفرات لينكس وعايز تفهم الأرقام اللي بتطلعلك في uptime وtop من غير ما تفزع منها.
Load Average في لينكس: ليه رقم 8 مش دايمًا مشكلة
لو شفت load average وصل 8 على سيرفرك وقلبك وقع، ركز: الرقم ده ممكن يكون طبيعي تمامًا. المشكلة غالبًا مش في السيرفر، المشكلة إنك بتقرأ الرقم غلط. في السطور الجاية هتعرف تفرّق في ثانية بين سيرفر مشغول وسيرفر مخنوق فعلًا.
المشكلة باختصار
أغلب الناس بتتعامل مع load average كأنه نسبة مئوية، فبيفتكروا إن أي رقم فوق 1 معناه السيرفر بيموت. ده غلط. الرقم ده مش نسبة، وقيمته الطبيعية بتعتمد على حاجة واحدة هتكررها في المقال ده كتير: عدد الأنوية (cores). من غير ما تعرف عدد الأنوية، الرقم لوحده مالوش أي معنى.
يعني إيه load average أصلًا؟ (بمثال بسيط)
تخيّل سوبر ماركت فيه 4 كاشير. الزباين اللي بيتم خدمتهم دلوقتي = 4. وفيه كمان 3 زباين واقفين في الطابور مستنيين دورهم. يبقى إجمالي الضغط على المحل = 4 اللي بيتخدموا + 3 مستنيين = 7.
الرقم 7 ده بالظبط هو فكرة الـ load average: مش بس اللي بيشتغل دلوقتي، لكن كمان اللي مستني دوره. لو عندك 4 كاشير والضغط 4، يبقى كل واحد مشغول وملوش طابور؛ وضع مثالي. لو الضغط 7 وعندك 4 كاشير بس، يبقى في زباين بيستنوا، والخدمة بقت أبطأ.
دلوقتي بعد ما المثال وضّح الفكرة، تعالَ للتعريف العلمي الدقيق: load average هو متوسط عدد العمليات (processes) اللي في حالة تشغيل أو في انتظار التشغيل خلال فترة زمنية. الكاشير = نواة المعالج. الزبون اللي بيتخدم = عملية شغّالة على نواة. الزبون اللي مستني = عملية جاهزة بس مفيش نواة فاضية تشغّلها.
القاعدة الذهبية: اقسم على عدد الأنوية
القاعدة اللي بتحوّل الرقم الغامض لمعلومة مفيدة بسيطة جدًا: اقسم الـ load على عدد الأنوية. شغّل الأمرين دول:
$ uptime
14:21:05 up 9 days, 3:42, 2 users, load average: 7.82, 4.10, 2.45
$ nproc
8هنا الـ load وصل 7.82 وعدد الأنوية 8. اقسم: 7.82 ÷ 8 = 0.97 تقريبًا. يعني السيرفر مستغَل بحوالي 97% من طاقته، شغّال على آخره بس من غير ما يتجاوز قدرته. مفيش طابور انتظار يُذكر. الرقم 8 هنا مش مشكلة خالص؛ ده سيرفر بيشتغل بكفاءة عالية.
بالعكس، لو نفس الرقم 7.82 على سيرفر فيه نواتين بس، يبقى 7.82 ÷ 2 = 3.9. ده معناه إن السيرفر متحمّل تقريبًا 4 أضعاف طاقته. القاعدة العملية: لو الناتج بعد القسمة أقل من 1، السيرفر مرتاح. حوالي 1، مستغَل بالكامل. أكتر من 1، في طابور انتظار والأمور بتبطّأ.
بالأرقام: لو عندك نواتين واللود 4، كل مهمة بتاخد عادةً 100 مللي ثانية ممكن تطلع تاخد قرابة 200 مللي ثانية، لأنها بتقضي نص الوقت مستنية دورها على النواة.
الأرقام الثلاثة: 1 و5 و15 دقيقة
الـ uptime بيديك 3 أرقام مش رقم واحد: متوسط آخر دقيقة، آخر 5 دقايق، وآخر 15 دقيقة. الترتيب ده بيحكيلك قصة الاتجاه:
- لو رقم الدقيقة أعلى من رقم الـ15 دقيقة (زي 7.82 مقابل 2.45)، يبقى الحِمل بيزيد دلوقتي. في حاجة بدأت تضغط.
- لو رقم الدقيقة أقل من رقم الـ15 دقيقة، يبقى الموجة عدّت والحِمل بيهدأ.
- لو التلاتة قريبين من بعض، يبقى الحِمل ثابت ومستقر.
عشان كده متفزعش من قفزة لحظية في رقم الدقيقة. بُص على رقم الـ15 دقيقة عشان تعرف الوضع الحقيقي المستقر.
نقطة بتخدع كتير: لينكس بيحسب انتظار القرص كمان
هنا الـ trade-off اللي لازم تعرفه. على عكس أنظمة يونكس الكلاسيكية، لينكس مابيحسبش بس العمليات اللي مستنية المعالج، لكنه كمان بيضيف العمليات اللي في حالة انتظار غير قابلة للمقاطعة (uninterruptible sleep)، وأغلبها بيكون مستني قراءة أو كتابة من القرص أو الشبكة.
المعنى العملي: ممكن يكون اللود عالي والمعالج نفسه فاضي تقريبًا، والسبب الحقيقي قرص بطيء. عشان كده القسمة على عدد الأنوية وحدها مش كفاية لو السبب I/O. افتح top وبُص على قيمة %wa (يعني io wait):
$ top
%Cpu(s): 9.1 us, 3.0 sy, 0.0 ni, 12.4 id, 75.2 wa, 0.0 hi, 0.3 siلو wa رقم كبير زي 75 زي فوق، يبقى السيرفر مش مخنوق بسبب المعالج، هو مستني القرص. في الحالة دي زيادة المعالجات مش هتحل المشكلة؛ المفروض تشوف القرص أو الـ I/O.
متى لا تعتمد على هذه القاعدة
القاعدة (اقسم على الأنوية) دقيقة لما يكون الحِمل بسبب المعالج. لكنها بتضلّلك في حالتين:
- لما الحِمل بسبب I/O wait: الرقم عالي بس المعالج فاضي. اتفرّج على
%waالأول. - على السيرفرات الافتراضية المشتركة (VMs): ممكن يكون فيه
steal time(وقت بياخده جارك على نفس العتاد الفعلي). شوف قيمةstفيtopقبل ما تحكم.
الافتراض هنا إن عندك سيرفر فعلي أو افتراضي مخصّص، وإن شغلك معتمد على المعالج. غير كده، الرقم لوحده مش هيكفي.
الخطوة التالية
افتح سيرفرك دلوقتي وشغّل uptime ثم nproc، واقسم رقم الـ15 دقيقة على عدد الأنوية. لو الناتج أقل من 1، سيرفرك مرتاح وخلاص؛ بطّل قلق. لو طلع أكبر من 1، افتح top وبُص على %wa وst قبل ما تفكر في ترقية العتاد، عشان تتأكد إن المشكلة فعلًا في المعالج مش في القرص أو الاستضافة.
المصادر
- توثيق لينكس الرسمي لملف
/proc/loadavgوتعريف متوسط الحِمل: man7.org — proc_loadavg(5) - مقال Brendan Gregg التفصيلي عن سبب احتساب لينكس لعمليات الـ uninterruptible في الحِمل: Linux Load Averages: Solving the Mystery (2017)
- صفحة دليل أمر
uptime: man7.org — uptime(1) - شرح حقول
topومنهاwaوst: man7.org — top(1)