كيف تتعقب الحمل الزائد على خادمك Analyzing Server Overload

كيف تتعقب الحمل الزائد على خادمك Analyzing Server Overload

مفهوم متوسط الحمل Load Average
فى هذه المقالة سنوضح كيفية تعقب مصدر الحمل على خادمك باستخدام مجموعة من الأدوات المتوافرة بالفعل على أنظمة يونكس/لينكس. افضل طريقة لمعرفة تفاصيل عن العمليات التى تجرى على حاسبك -على أنظمة يونكس/لينكس- هى استخدام الأدوات المتوافرة بالفعل على النظام ومنها أمر top وأمر uptimeوهما من الأدوات الأساسية التى يتم إرفاقها بأنظمة يونكس/لينكس الان.

 

بداية نوضح أنه عند الحديث عن الحمل على الخادم فإننا نتحدث عن متوسط الحمل Load Average  والذى يظهره لنا أمر uptime. إنظر شكل ١

$ uptime
3:22  up  15:12, 1 users, load averages: 1.13  6.10  3.08

شكل ١ – مثال توضيحى لتشغيل أمر uptime

ملحوظة هامة: يستقى أمر uptime بيانات الحمل من ملف ‪/‬proc‪/‬loadavg ويمكنك الحصول على نفس الناتج بإصدار أمر cat لهذا الملف. إنظر شكل ٢

$ cat ‪/‬proc‪/‬loadavg
1.13  6.10  3.08 1/122 9241

شكل ٢ – أمر cat لملف ‪/‬proc‪/‬loadavg يعطى نفس بيانات الحمل التى يظهرها أمر uptime.

هذا الأمر يعطى ملخص عن عدد الساعات التى كان الخادم فيها فعالاً On وكذلك عدد المستخدمين المتواجدين عليه بالإضافة الى متوسط الحمل خلال عدد ساعات التشغيل تلك.

كما يظهر بالمثال الأول: عدد ساعات التشغيل هو خمس عشرة ساعة واثنتى عشرة دقيقة, عدد المستخدمين إثنان, ومتوسطات أحمال  1‪.‬13‪,‬  6‪.‬10‪,‬  3‪.‬08
من هذا المثال وبشكل تقنى, متوسط الحمل يمثل متوسط عدد العمليات Processes التى تضطر للإنتظار حتى يتاح لها وقت من المعالج  CPU Time للتعامل معها خلال الخمسة عشرة ساعة الماضية. بمعنى: إذا كان متوسط الحمل لديك هو صفر‪  (0) ‬فإن المعالج فى هذه الحالة يكون خاملاً Idle أى انه ليس لديه مهام ليؤديها. أما إذا كان متوسط الحمل واحد ‪(‬1‪)‬ فإن ذلك يعنى أن المعالج مشغول لدرجة أن عملية واحدة مازالت بالإنتظار حتي يتاح لها وقت من المعالج للتعامل معها. تخيل لو كان متوسط الحمل خمسة وسبعين مثلاً؟

هناك أمر لابد من التنبيه اليه. متوسط الحمل وعلاقته بعدد المعالجات ليست علاقة عكسية. بمعنى أنه إذا كان لدينا جهاز ذو معالج واحد وكان متوسط الحمل عليه ١, وجهاز أخر ثُمانى المعالجات ومتوسط الحمل عليه ٨ فإن نسبة إنشغال المعالجات على كل من الجهازين متساوية تقريبا, حيث ٨ ÷ ٨ = ١.

ولتقريب مفهوم الحمل أكثر اليك المثال التالى:

جسر مكون من حارة واحدة تتسع طولاً لعشر سيارات وعرضاً لسيارة واحدة. فى حال مرور عشرة سيارات على الجسر يكون الحمل = ١  حيث الجسر ممتلئ تماما.
فى حال مرور خمس سيارات على الجسر يكون الحمل = ١/٢  حيث الجسر مستغل بنصف طاقته.
فى حال محاولة مرور خمس عشرة سيارة على الجسر يكون الحمل = ١,٥ حيث الجسر ممتلئ بالفعل, وهناك خمس سيارات بالإنتظار حتى يتاح لها مكان للعبور. إنظر شكل ٣

شكل ٣ – مثال توضيحى لمفهوم الحمل.

إذا إفترضنا أن النظام يقوم بتسجيل متوسط الأحمال كل خمس دقائق, فإنه من المثال الأول يمكننا استنتاج أنه خلال الخمس عشرة دقيقة الأخيرة كان متوسط الحمل 3‪.‬08  تغير خلال العشر دقائق الأخيرة الى 6‪.‬10 بزيادة الضعف تقريباً, ثم هبط خلال الدقائق الخمس الأخيرة الى 1‪.‬13
أما إذا كان متوسط الأحمال مثلاً 2‪.‬11‪,‬ 7‪.‬78‪,‬ 18‪.‬23 فإنه يمكننا استنتاج أن متوسط الحمل فى إزدياد وأنه يتجه للأسوأ

متى يكون متوسط الحمل نذير خطر على استقرار النظام؟

بعد أن تعرفنا على مفهوم متوسط الحمل, نأتى للسؤال المنطقى: متى يكون رقم متوسط الحمل جيداً ومتى يكون مقلقاً؟
والإجابة على هذا السؤال أن ذلك يتوقف على عوامل عديدة. هناك العديد من الأسباب التى تؤدى لإرتفاع الحمل وفى نفس الوقت تؤثر بشكل مختلف فى أداء النظام وسرعة إستجابته. فقد يبلغ متوسط الحمل على أحد الأجهزة 60 أو 70 ومع ذلك تكون سرعة استجابة النظام جيدة وهناك جهاز أخر متوسط الحمل عليه دون ال 20 ومع ذلك تكون استجابته بطيئة جداً! المهم هنا هو الوصول الى سبب إرتفاع الحمل.

عند البدء فى تحديد أسباب ارتفاع الحمل نجد أن معظم الأسباب تقع فى ثلاث مجموعات رئيسة:
– إرتفاع حمل مرتبط بالمعالج CPU Related
– إرتفاع حمل مرتبط بالذاكرة Memory Related
– إرتفاع حمل مرتبط بالإدخال والإخراج I‪/‬O Related

بالطبع هناك أسباب أخرى منها عيوب مكونات الخادم Hardware Malfunction وإرتفاع درجة حرارة الوسط نتيجة سوء التبريد داخل غرف مراكز البيانات وغير ذلك. لكن هذه المسببات نادرة الحدوث هذه الأيام لعدة أسباب, أهمها إرتفاع جودة المكونات المستخدمة فى تصنيع الحاسبات وزيادة معاملات الأمان فى مراكز البيانات Data centers.

فى الأسطر التالية سوف نوضح كيفية استخدام أدوات نظام لينكس w و top و iostat للوصول الى سبب المشكلة

من الأوامر المفضلة لدى عند الدخول الى الخادم أمر  w. هذا الأمر يعطينى ملخصاً عن حالة الخادم, عدد الساعات التى عملها, عدد المستخدمين المتواجدين حاليا مع رقم عنوان الإنترنت الخاص بكل منهم, والعمليات التى يجريها كل منهم حاليا, بالإضافة الى متوسط الحمل للنظام.  إنظر شكل ٤

$ w
22:42:13 up 1 day,  9:21,  1 user,  load average: 1.13  6.10  3.08
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    XXX.XXX.XXX.XXX    22:06    0.00s  0.01s  0.00s w

شكل ٤ – مثال توضيحى لتشغيل أمر w – لاحظ أن قيمة XXX.XXX.XXX.XXX ترمز لعنوان الإنترنت الرقمى IP Address الخاص بالخادم.

ثم هناك أمر top والذى يوفر الكثير من البيانات عن حالة النظام عموما والعمليات الجارية عليه ومدى استغلال كل منها لموارده.   إنظر شكل٥

top – 22:06:41 up 1 day,  8:46,  1 user,  load average: 0.31, 0.44, 0.44
Tasks: 226 total,   1 running, 225 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.8%us,  0.2%sy,  0.0%ni, 96.8%id,  0.2%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   4035784k total,  3825288k used,   210496k free,   362852k buffers
Swap:  2096440k total,    84988k used,  2011452k free,  1523744k cached

PID USER           PR  NI   VIRT     RES   SHR S %CPU   %MEM    TIME+     COMMAND
12704 nobody    15   0     81252   7188  1852 S  0.7        0.2        0:00.17       httpd
12768 nobody    15   0     81252   7100  1800 S  0.7         0.2       0:00.02       httpd
9386 mysql        15   0    663m    264m  3172 S  0.3        6.7       452:32.80   mysqld
12201 nobody    15   0    81388    7292  1860 S  0.3        0.2       0:00.17        httpd
12211 nobody    15   0    81388    7344  1908 S  0.3        0.2       0:00.15        httpd
12637 nobody    15   0    81444    7280  1852 S  0.3        0.2       0:00.06        httpd
12641 nobody    16   0    81252    7208  1856 S  0.3        0.2       0:00.03        httpd
12767 nobody    15   0    81436    7240  1828 S  0.3        0.2       0:00.02        httpd
12776 nobody    15   0    81256    7156  1840 S  0.3        0.2       0:00.01        httpd

شكل ٥ – مثال توضيحى لتشغيل أمر top

يوضح الشكل أعلاه ناتج إجراء أمر top على أحد الخوادم ونرى فى الأسطر الأولى كيف أنه يعطى تقريبا نفس النواتج التى حصلنا علها من أمرى w و uptime. كما انه يحدث البيانات تلقائيا كل عدة ثوان. كما يظهر بالشكل فإن النظام مستقر. عند محاولة تعقب مصدر الحمل فإننا نبدأ أولا بمسببات الحمل على المعالج, ثم الذاكرة, ثم الإدخال والإخراج I‪/‬O. سنبدأ الان بالمعالج:

إرتفاع الحمل المرتبط بالمعالج  CPU Related Load

إرتفاع الحمل على المعالج Processor  سببه كثرة العمليات المركزة عليه والتى تعمل معا فى نفس الوقت. ولأن كل عملية تحتاج لوقت من المعالج فإن ذلك يترتب عليه أن كل منها ستنتظر دورها. لكى تعرف إذا كان ارتفاع الحمل مرتبط بالمعالج تفقد السطر التالى

Cpu(s):  2.8%us,  0.2%sy,  0.0%ni, 96.8%id,  0.2%wa,  0.0%hi,  0.1%si,  0.0%st

كل من هذه النسب المئوية هى نسبة من وقت المعالج مرتبطة بعملية معينة يتم معالجتها. واليك ملخص للقيم وكيفية قرائتها:

us ‫=‬ user CPU time

هذه هى النسبة المتعلقة بالتطبيقات والعمليات التى يجريها المستخدم. فى معظم الأحيان يكون إرتفاع الحمل ناتج عن عملية أو تطبيق تقوم أنت بتشغيله على النظام مثل خادم الأباتشى Apache Webserver  وقواعد بيانات MySQL.
إذا كانت هذه النسبة مرتفعة فالأرجح أن أحد التطبيقات الفعالة هو السبب فى الإرتفاع.

sy = system CPU time

هذه هى النسبة المتعلقة بالتطبيقات والعمليات الخاصة بالنظام نفسه مثل نواة النظام Kernel والعمليات الأخرى الأساسية.

id = CPU idle time

هذه هى نسبة الوقت الذى يقضيه المعالج خاملاً Idle لا يؤدى أى وظائف. وكلما ارتفعت هذه النسبة كلما كان ذلك أفضل لانه يعنى أن موراد الجهاز كافية وليس هناك عمليات تستغرق وقتا طويلا للتنفيذ وأن أى ارتفاع للحمل ليس متعلقا بالمعالج -بمعنى أخر, قدرة المعالج الحالى كافية للقيام بالمهام المطلوبة ولا تحتاج لترقيته.‪ ‬

wa = I/O wait

نسبة انتظار الإدخال والإخراج I‪/‬O Wait توضح الوقت الذى يقضيه المعالج منتظراً اتمام إحدى عمليات الإدخال والإخراج I‪/‬O. إذا كان خادمك يعانى من إرتفاع الحمل وكانت قيمة هذه النسبة مرتفعة فالارجح أن سبب إرتفاع الحمل يرجع الىالقرص الصلب أو الذاكرة RAM وليس مرتبطاً بالمعالج. لاحظ أن القرص الصلب هو من أبطأ الأجزاء فى الحاسبات الالية عموما من ناحية سرعة القراءة/الكتابة لأنه وببساطة مكون ميكانيكي -يعتمد على أجزاء متحركة ذات سرعة محدودة, يتفوق عليه فى البطء كلاً من السواقات البصرية CD‪/‬DVD‪-‬ROMs وذاكرة USB على الرغم من كونها لاتحوى أجزاءاً ميكانيكية, لكن سرعة ال I‪/‬O لها مازالت محدودة*.

بينما تعتبر الذاكرة المؤقتة RAM من أسرع الأجزاء فى تبادل البيانات.
لكى نوضح أكثر اليك المثال التالى:
عملية بحث فى قاعدة بيانات MySQL تجريها للبحث عن بيانات مستخدم معين فى منتدى تستدعى من برنامج أو عملية mysqld  أن تقرأ ملف قاعدة البيانات من على القرص الصلب ثم تستخلص منه ناتج البحث وتعطيه لك. قراءة قاعدة البيانات من على القرص الصلب تستغرق وقتا يقضيه القرص الصلب نفسه Hard Drive فى البحث عن الملف المطلوب -قاعدة البيانات نفسهاـ وقرائتها ثم ارسالها مرة أخرى للنظام. فى الوقت الذى يبحث فيه القرص الصلب عن الملف ويستخلصه يكون المعالج منتظراً Idle حتى ينتهى القرص الصلب من مهمته.

نتيجة هامة: لتحسين سرعة أداء الخادم إختر أقراصاً صلبة ذات معدل I‪/‬O مرتفع. الأجيال الجديدة من الأقراص الصلبة من فئة SATA يوجد منها انواع تدور بسرعة 10K (عشرة الاف لفة/دقيقة). يفضل إستخدام هذه الأقراص على الخوادم التى تستخدم لإستضافة قواعد بيانات كبيرة.
يمكنك أيضا ترقية الذاكرة الى نوع يدعم سرعة Bus أعلى. مثلا إذا كانت الذاكرة لديك تعمل على سرعة Bus بحد أقصى 800MHz يمكنك الترقية الى ذاكرة تعمل بسرعة 1066‪MHz‬ أو أعلى. يتوقف ذلك على دعم اللوحة الأم لهذه السرعات, ويمكنك دائما استشارة مركز البيانات المتواجد به خادمك.‪   ‬

تعقب إرتفاع الحمل المتعلق بالمعالج
إذا كنت ترى نسبة حمل مرتفعة فى الجزء الخاص بالمستخدم أو النظام, فهناك إحتمال كبير أن يكون الحمل مرتبطاً بالمعالج. لتعقب السبب انظر الى الأسطر التى يعرض فها أمر top العمليات الجارية على النظام. بشكل اساسى يقوم أمر top بترتيب هذه العمليات تنازليا بوضع الأكثر استخداماً للمعالج بالأعلى,نقصد تحديدا العمود المسمى ‪%‬CPU.  إنظر شكل ٦

PID USER           PR  NI   VIRT     RES   SHR S %CPU   %MEM    TIME+     COMMAND
12704 nobody    15   0     81252   7188  1852 S  0.7        0.2        0:00.17       httpd
12768 nobody    15   0     81252   7100  1800 S  0.7         0.2       0:00.02       httpd
9386 mysql        15   0    663m    264m  3172 S  0.3        6.7       452:32.80   mysqld
12201 nobody    15   0    81388    7292  1860 S  0.3        0.2       0:00.17        httpd
12211 nobody    15   0    81388    7344  1908 S  0.3        0.2       0:00.15        httpd
12637 nobody    15   0    81444    7280  1852 S  0.3        0.2       0:00.06        httpd
12641 nobody    16   0    81252    7208  1856 S  0.3        0.2       0:00.03        httpd
12767 nobody    15   0    81436    7240  1828 S  0.3        0.2       0:00.02        httpd
12776 nobody    15   0    81256    7156  1840 S  0.3        0.2       0:00.01        httpd

شكل ٦ ‪-‬ أمر top يرتب العمليات تنازليا طبقا لحدتها ‪ ‬

يخبرنا العمود ‪%‬CPU كم استغلال كل عملية من العمليات الجارية للمعالج. فى حالتنا هذه نجد أن عملية httpd -وهى خاصة بخادم الأباتشى- هى أكثر العمليات استغراقاً للمعالج, حيث تستهلك 0‪.‬7‪%‬ من وقته. حين النظر الى شاشة أمر top  وقت إجراءه ستجد أحد أمرين: إما عملية محددة تستهلك معظم وقت المعالج, أو عدة عمليات تتسابق فيما بينها للحصول على وقت من المعالج, وهذا ما نراه فى المثال الموضح أمامنا.  فى كلا الحالتين سيكون من السهل تحديد العملية المسببة لإرتفاع الحمل.

يستخدم خادم الأباتشى خاصية التفريع Forking لتحسين أداءه. وهذه الخاصية باختصار تعتمد على تفريع العملية الرئيسة httpd الى عشرات -أحيانا الاف- العمليات الفرعية بنفس الأسم لكن بمعرف PID مختلف, وذلك لتلبية طلبات المستخدمين الذين يتصفحون الموقع. بالطبع كلما أرتفع عدد الزوار كلما زاد عدد العمليات الفرعية-علاقة طردية. على الأجهزة التى لاتدعم معالجاتها خاصية ال Multi‪-‬Threading أو التى تحتوى على معالج واحد فقط, يتسبب تفريع عملية مثل httpd فى إرتفاع الحمل الإجمالى بشكل ملحوظ على الرغم من أن كل عملية فرعية قد لا يتعدى حملها 0‪.‬3.

نتيجة هامة: للحصول على أداء جيد من الخوادم الخاصة بالأباتشى, يفضل استخدام خوادم متعددة المعالجات Multi‪-‬CPU  أو أحادية المعالجات لكنها متعددة النواة Multi‪-‬Core CPU. كما أنه يمكن الجمع بين الخاصيتين باستعمال خادم متعدد المعالجات وكل معالج متعدد الأنوية.

معلومة مفيدة: يمكنك استخدام أمر kill مع معرف العملية الفرعية PID لوقف تلك العملية حال كونها تستهلك موارد النظام. كما يمكنك أيضا استخدام أمر killall مع اسم العملية لوقف العملية الرئيسة وكل العمليات المتفرعة منها. إنظر شكلى ٧ و ٨

kill 12704

شكل ٧ – استخدام أمر kill مع معرف العملية الفرعية PID لوقف العملية.

killall -9 httpd

شكل ٨ – استخدام أمر killall مع اسم العملية لوقف العملية الرئيسة وكل العمليات المتفرعة منها.

إرتفاع الحمل المرتبط بالذاكرة RAM Related Load

السبب الأخر من أسباب ارتفاع الحمل هو نفاذ الذاكرة الموقتة للخادم RAM بسبب إمتلائها عن أخرها مما يضطر النظام لإستخدام قسم ال swap على القرص الصلب كبديل للذاكرة.
قسم ال swap هو جزء من القرص الصلب خاص بالنظام ولا يمكن للمستخدم عادة الدخول عليه, حيث يستخدم كذاكرة مؤقتة للنظام حال إمتلاء الذاكرة المؤقتة الأصلية RA‪M‬. ولأن القرص الصلب -كما بينا من قبل- أبطأ بكثير من الذاكرة فإن ذلك يتسبب فى إنخفاض أداء الجهاز بشكل ملحوظ مع إرتفاع الحمل نتيجة إرتفاع نسبة ال I‪/‬O. وطبيعى أن العمليات التى يتم إجرائها من على قسم ال swap تكون ابطأ كثيرا فى التنفيذ.
ثم تحدث الكارثة عندما تستنفذ مساحة قسم ال swap بالكامل. إذ عنده لايجد النظام مكاناً لا فى الذاكرة المؤقتة ولا على قسم ال swap على القرص الصلب وهى الحالة التى إذا لم يتم تداركها فإن العمليات تتراكم بإنتظار التنفيذ  النظام كله قد ينهار Crash مما قد يضطرك الى إعادة تشغيله عن طريق عمل Reset للخادم.

وهناك نقطة ماكرة بخصوص ال swap. فبسبب أن استخدام النظام له بكثافة يهبط بأداء القرص الصلب, فإنه من السهل أن يشخص سبب إرتفاع الحمل خطأ على أنه مشكلة مرتبطة بالإدخال والإخراج I‪/‬O Related فى حين أن المشكلة الحقيقية هى نفاذ الذاكرة المؤقتة‪.‬
لذا, إذا وجدت إرتفاعاً فى نسبة ال I/O wait عند تفقد سطر Cpu‪(‬s‪)‬ فى معطيات أمر top, إفحص الذاكرة المؤقتة أولا وتأكد من وجود كم مناسب منها متاحاً للتطبيقات. تفقد أيضا إعدادات تطبيقاتك وتأكد من ضبطها بحيث لا تستغرق كل الحجم المتاح من الذاكرة.

مثال حى: فى أحد الأيام كان لدينا خادم أباتشى مزدوج المعالجات مع ستة عشر جيجا من الذاكرة المؤقتة ومع ذلك كان الحمل القادم من عملية mysqld مرتفعا جداً, مصحوباً بإمتلاء ال RAM مع إستخدام جزء صغير من قسم swap
من النظرة الأولى لمعطيات to‪p‬ اتضح لنا أن المشكلة هى إمتلاء الذاكرة المؤقتة بالرغم من الحجم الكبير المتوافر. بتفقد إعدادات ال MySQL وجدنا أن هناك خطأ  بإعدادات ال buffer مما سبب أن تستهلك عملية mysqld معظم الذاكرة المتاحة, ومع امتلاء الذاكرة بدأ الحمل فى الإرتفاع. ‪تصحيح هذا الخطأ هبط بالحمل فوراً الى منسوب معقول مع تحسن رائع فى تحميل صفحات الموقع‬

لتحليل وتحديد مشاكل الذاكرة إنظر الى السطرين الرابع والخامس

Mem:   4035784k total,  3825288k used,   210496k free,   362852k buffers
Swap:  2096440k total,    84988k used,  2011452k free,  1523744k cached

هذه الأسطر تخبرك بكم الذاكرة المتاحة إجمالا و الكم المشغول والمتوفر منها. كما تخبرك بنفس البيانات عن ال swap. مع ذلك يجب الحرص عند النظر الى هذه البيانات حيث أنها قد تخدع حتى بعض مديرى النظم المتمكنين. فعند النظر الى حجم الذاكرة الغير مشغولة تجد أنه 210496k  أى أن الذاكرة ممتلئة تقريباً. وبالرغم من أن الرقم صحيح فأن هذه ليست الحقيقة كاملة.

الملفات المخزنة ونظام لينكس  Linux File Caching

عندما تفتح ملفاً على نظام لينكس تقوم النواة بتحميل ذلك الملف فى الذاكرة المؤقتة RAM. لكن النواة لاتقوم بالضرورة بتفريغ الذاكرة من هذا الملف عند الفراغ من استخدامه. إذا كان النظام مازال به المزيد من الذاكرة الفارغة فإن النواة تحاول تخزين أكبر قدر ممكن من الملفات بها, وهو مايعرف بالملفات المخزنة Fi‪le Cache‬. يسهم هذا الأسلوب فى تحسين أداء الأجهزة بشكل عام حيث يقلل من زمن استدعاء الملفات, فبدلا من قراءة الملف من على القرص الصلب فى كل مرة ترغب فى تشغيله, يتم جلبه مباشرة من الذاكرة المؤقته بعد تخزينه بها للمرة الأولى. وكلما طال زمن تشغيل النظام – بعض خوادم لينكس تعمل أعواما بدون إنقطاع لثانية واحدة – كلما امتلأت الذاكرة بالمزيد من الملفات المخزنة.
لذا فإنه لتحديد نسبة ال RAM الفارغة بشكل أدق, قارن بين قيم عمودى free  و cached. فى حالتنا هذه لدينا  1523744k cached ‪+‬  210496k free  يعنى مايقرب من ٢٥٠ ميجابايت من الذاكرة فارغة مقابل ١,٥ جيجا تقريبا من الملفات المخزنة بينما إجمالى الذاكرة على الخادم هو ٤ جيجابايت. هنا يمكننى القول ببساطة أن ارتفاع الحمل غير ناتج عن نفاذ الذاكرة المؤقتة. لذا انتقل الى سطر ال swap لأعرف ماإذا كان يستخدم بكثافة.

تأكد من عدم استخدام ال RAM بكثافة

إذا كان نظامك يعانى من قلة الذاكرة المؤقتة الفارغة انظر الى عمود %MEM واضغط حرف M على لوحة مفاتحك. كما أوضحنا فإن أمر top يرتب العمليات طبقا لشدتها, لكن عند ضغط حرف M فإنه سيرتبها طبقا لما تستغله من ذاكرة RAM
يمكن هنا أن نرى أن العملية mysqld هى الأكثر استهلاكاً للذاكرة. إنظر شكل ٩

PID USER           PR  NI   VIRT     RES   SHR S %CPU   %MEM    TIME+     COMMAND
9386 mysql        15   0    663m    264m  3172 S  0.3        6.7       452:32.80   mysqld
12704 nobody    15   0     81252   7188  1852 S  0.7        0.2        0:00.17       httpd
12768 nobody    15   0     81252   7100  1800 S  0.7         0.2       0:00.02       httpd
12201 nobody    15   0    81388    7292  1860 S  0.3        0.2       0:00.17        httpd
12211 nobody    15   0    81388    7344  1908 S  0.3        0.2       0:00.15        httpd
12637 nobody    15   0    81444    7280  1852 S  0.3        0.2       0:00.06        httpd
12641 nobody    16   0    81252    7208  1856 S  0.3        0.2       0:00.03        httpd
12767 nobody    15   0    81436    7240  1828 S  0.3        0.2       0:00.02        httpd
12776 nobody    15   0    81256    7156  1840 S  0.3        0.2       0:00.01        httpd

شكل ٩ – ترتيب العمليات وفقا لحجم الذاكرة المستغلة.‪ ‬

معلومة مفيدة: إذا كنت تعلم أن هناك الكثير من الملفات المخزنة بال RAM وكنت ترغب فى تنظيفها فيمكنك تحرير المزيد من الذاكرة باستخدام “drop_caches”

أصدر الأوامر التالية على الترتيب الموضح

$ free -m
$ sync
$ echo 3 > /proc/sys/vm/drop_caches

إرتفاع الحمل المرتبط بالإدخال والإخراج  I‪/‬O Related Load

كما اوضحنا من قبل, يمكن أن تنخدع ببعض بيانات top وتظن أن الأمر متعلق بالإدخال والإخراج I‪/‬O Related حين يكون هناك استخدام مكثف لل swap نتيجة نفاذ ال RAM. لكن عند التأكد من أن المشكلة غير متعلقة بالذاكرة المؤقتة وكان لديك رقم I/O wait كبير, فإنه يكون عليك تحديد أى الأقراص الصلبة أو أقسامها على جهازك هى سبب المشكلة. لعمل ذلك تحتاج لإستخدام أداة iostat. إنظر شكل ١٠

$ iostat

Linux 2.6.18-164.15.1.el5xen       (test.server.com)     05/25/2010

avg-cpu:       %user        %nice      %system        %iowait       %steal        %idle
0.05         0.00          0.02                0.03            0.01         99.90

Device:          tps           Blk_read/s   Blk_wrtn/s     Blk_read           Blk_wrtn
sda                2.38         20.02           46.17            25346610         58465488
sda1              0.00         0.04             0.02              53320               27720
sda2              1.14         15.71           17.85           19894167          22602992
sda3              0.53         1.74             14.47            2200759           18319288
sda4              0.00         0.00             0.00             14                      0
sda5              0.41         1.81             10.42           2295634            13196336
sda6              0.00         0.00             0.00             2330                  528
sda7              0.02         0.71             0.16             896024              201472
sda8              0.27         0.00             3.25             3826                  4117152
sdb                71.63       1749.11       2172.62       2214969981      2751278073
sdb1              71.63       1749.11       2172.62       2214969197      2751278073
sdc                106.91     2750.96       2843.76       3483667846      3601183456
sdc1              106.91     2750.96       2843.76       3483667174      3601183456

شكل ١٠ –  مثال توضيحى لتشغيل أمر iostat

وكما يفعل أمر top فإن أمر iostat يعطينا معلومات عن متوسط الحمل على المعالج. تحت ذلك تجد بيانات عن كل من

tps: transactions per second.                                عدد العمليات / الثانية
Blk_read/s: blocks read per second.                    عدد البلوكات المقروءة / الثانية
Blk_wrtn/s: blocks written per second.               عدد البلوكات المكتوبة / الثانية
Blk_read: total blocks read.                                 إجمالى عدد البلوكات المقروءة
Blk_wrtn: total blocks written.                            إجمالى عدد البلوكات المكتوبة

بتحليل هذه البيانات سيكون بمقدورك اكتشاف القرص الصلب/القسم  المسبب للمشكلة حيث سيكون هو صاحب أعلى أرقام. كما سيمكنك تحديد ما إذا كانت غالبية البيانات داخلة أم خارجة منه-مكتوبة أم مقروءة.
مثلاً: إذا كان لديك نظام نسخ إحتياطى خارجى External Backup وكنت تشك أن عملية النسخ هى سبب إرتفاع الحمل, قارن ارقام Blk_read/s و Blk_wrtn/s فإذا كانت ارقام Blk_wrtn/s هى الأعلى فأنه بالتأكيد عملية النسخ ليست هى المشكلة لأنه من المفترض أن تقرأ من قرصك الصلب وتكتب على القرص الصلب للسيرفر الاخر. أما إذا كانت أرقام Blk_read/s هى الأعلى, فأنه يمكنك تشغيل أمر lsof  وأمر grep ضد اسم عملية المنسخ لتعرف بيانات أكثر عنها.
تعقب ارتفاع الحمل بواسطة أمر iostat ليس أمرا مباشراً لكنه ليس بالعسير. فقط يتطلب الأمر بعض الممارسة حتى تتمكن من التعرف على موطن الخلل. كما أن لأمر iostat العديد من المحددات يمكنك التعرف عليها بتفقد صفحة ال man الخاصة به.

حتى وقت قريب كانت أدوات مثل iostat تمثل اقصى ما يمكن لمديرى نظم يونكس/لينكس الحصول عليه لتحرى مشاكل الإدخال والإخراج I/O. لكن مع التطور الذى حدث فى نواة النظام أُدخلت أدوات حديثة تسمح بتحرى مسببات هذه المشاكل حتى مستوى العمليات الفردية Per-Process Level . من هذه الأدوات الجديدة أداة iotop وهى مماثلة لأداة iostat لكنها تتخصص فى فحص عمليات الإدخال والإخراج I/O.

$ iotop

2010     May 25 14:48:13,     load: 2.40,    disk_r:    56972 KB,    disk_w:   7108 KB

UID         PID             PPID                   CMD                   DEVICE       MAJ         MIN D            BYTES
501        2249          132                    mysqld                ??               14           3 R                20480
501        65848        132                    httpd                   ??               14           2 R               475136
0            0                0                        kernel_task         ??               14           3 W              983040

شكل ١١ – شكل توضيحى لتنفيذ أمر iotop.

ملحوظة هامة: هناك أمر أخر لابد أن يؤخذ فى الإعتبار وهو أن تتأكد من عدم إمتلاء أقسام القرص الصلب الخاص بخادمك لما لذلك من تأثير سلبى على الأداء. يمكنك التحقق من ذلك بسهولة عن طريق إصدار أمر df ‪-‬h. أمر df يظهر لك حجم إشغال الأقراص الصلبة والأقسام التى على خادمك. إنظر شكل ١٢

$ df -h

Filesystem            Size      Used    Avail   Use%      Mounted on
/dev/sda5             9.7G     860M    8.4G  10%         /
/dev/sda8             996M    986M    9.6M   99%        /tmp
/dev/sda7             101G    2.3G     93G     3%          /home
/dev/sda3             9.7G     4.3G     5.0G    46%        /usr
/dev/sda2             9.7G    1.3G      8.0G    14%        /var
/dev/sda1             99M     55M      39M     59%        /boot

شكل ١٢ – شكل توضيحى لتنفيذ أمر df.

لاحظ هنا إمتلاء قسم ‪/‬tmp على القرص الصلب وهذا يسبب مشاكل مع أى عمليات تستخدم هذا القسم لتخزين ملفات أثناء عملها قد تصل أحيانا الى انهيار العملية كليا بسبب عدم قدرتها على إضافة أى ملفات لهذا القسم.

وماذا بعد؟

الأن وقد وضعت أقدامك على الطريق الصحيح لتحديد أسباب إرتفاع الحمل على الخادم, تأتى الى النقطة الأخيرة وهى كيفية التعامل مع الأسباب وحل المشكلة. هنا تتعدد الحلول المطروحة طبقا لظروف الخادم ونوع العمليات الجارية عليه. فإن إرتفاع الحمل الناتج عن عملية تجريها على الخادم ويمكنك بسهولة وأمان إنهائها يختلف عن إرتفاع الحمل الناتج عن عملية قواعد بيانات MySQL, حيث لايمكنك إنهائها فوراً لما قد يسببه ذلك من تلف لملفات قواعد البيانات الموجودة على الخادم. عندها قد تلجأ الى زيادة موارد الخادم من ذاكرة مؤقتة أو معالجات أو حتى أقراص صلبة. فى النهاية تحديد الحل المناسب يعود اليك أنت.

References   مراجع

http://www.linuxjournal.com/article/9001
http://en.wikipedia.org/wiki/Load_%28computing%29
‫Linux Man Pages:  http://man.he.net‬
http://luv.asn.au/overheads/NJG_LUV_2002/luvSlides.html
http://www.performancewiki.com/cpu-tuning.html#linux
http://www.linuxinsight.com/proc_filesystem.html
‫————————————————————————————————————————————————————————————————–‬

‪* ‬المفترض فى الجيل الثالث من اجهزة ال USB أن تصل سرعة نقل البيانات منه الى 5 ‪جيجابت/ثانية, وهى سرعة تقترب كثيرا من سرعة الأقراص الصلبة, بل وتتفوق على بعضها‬
htop و mytop هناك عدة أدوات مفتوحة المصدر تسهل متابعة وتشخيص حالة النظام, منها على سبيل المثال**
‪*** ‬ تمرين: ما الفارق بين إجراء أمر top بدون محددات وبين إجراءه بالمحددات top -SHM ؟[:]