اختبار الأداء والتحميل

الاختناقات على مستوى النظام

18 دقيقة الدرس 7 من 28

الاختناقات على مستوى النظام

تكشف اختبارات التحميل عن الأعراض — ارتفاع زمن الاستجابة، وسقوط الطلبات، وتشبّع الطوابير. أما تشخيص السبب الجذري فيتطلب النزول طبقةً واحدة أعمق: نحو نظام التشغيل والعتاد الذي يعمل فوقه كل شيء. تمنحك طريقة USE (الاستخدام والإشباع والأخطاء — Utilization, Saturation, Errors)، التي صاغها Brendan Gregg، قائمةَ تحقق منضبطة لكل مورد فيزيائي: المعالج، والذاكرة، وإدخال/إخراج القرص، والشبكة. طبّقها بهذا الترتيب كلما كشف اختبار التحميل عن تدهور غير مفسَّر.

طريقة USE في التطبيق العملي

لكل مورد ثلاثة مقاييس أساسية:

الاستخدام (Utilization) — نسبة الطاقة المستهلكة من الطاقة الكلية المتاحة (0–100%).
الإشباع (Saturation) — العمل المنتظر في الطابور لأن المورد بلغ طاقته القصوى (عمق طابور التشغيل، عمق طابور القرص...).
الأخطاء (Errors) — أعطال على مستوى العتاد أو المشغّل: تصحيحات ذاكرة ECC، وإعادة إرسال TCP، وإسقاطات بطاقة الشبكة.

الاستخدام المرتفع وحده ليس مثيرًا للقلق؛ أما الإشباع فمثيرٌ دائمًا. معالج يعمل بنسبة 95% مع طابور تشغيل عند الصفر هو مجرد مشغول. لكن معالجًا بنسبة 70% مع طابور تشغيل مستمر بعمق 8 على جهاز رباعي الأنوية هو في حالة إشباع وسيُنتج تذبذبات عشوائية في زمن الاستجابة p99.

لماذا USE قبل التحليل التفصيلي؟ تحليل التطبيقات (مخططات اللهب، التتبع) عملية مكلفة ومحدودة النطاق. USE هي قائمة تحقق تستغرق 30 ثانية تستبعد خلالها فئة كاملة من الموارد قبل أي استثمار في الأدوات. طبّق USE أولًا؛ وانتقل إلى التحليل التفصيلي فقط على المورد المُشبَع أو الذي يُسجّل أخطاءً.

اختناقات المعالج (CPU)

يتجلى إشباع المعالج في ارتفاع متوسط الحمل بالنسبة لعدد الأنوية، وظهور قيمة %wa غير صفرية (انتظار I/O) أو ارتفاع %us + %sy في top. أوامر الفحص السريع القياسية:

# لقطات بفاصل ثانية واحدة لجميع حالات المعالج
mpstat -P ALL 1 5

# عمق طابور التشغيل ومتوسط الحمل (USE: الإشباع)
vmstat 1 10

# أعلى 10 خيوط استهلاكًا للمعالج
ps -eo pid,tid,pcpu,psr,comm --sort=-pcpu | head -12

# زمن انتظار المجدول لكل مهمة — يتطلب أدوات BCC
/usr/share/bcc/tools/runqlat 10
# مدرّج تكراري: المدة التي تنتظرها المهام في طابور التشغيل قبل الحصول على معالج

على نطاق واسع، تعلوم أهمية ارتباط المجدول (Scheduler Affinity). جهاز JVM مثبَّت على عقدة NUMA لا يمتلكها يدفع عقوبة وصول إلى الذاكرة عبر NUMA تبلغ ~100 نانوثانية لكل عملية تخصيص. تحقق باستخدام numastat -c <pid> وعيّن numactl --cpunodebind=0 --membind=0 للخدمات الحساسة لزمن الاستجابة. بالنسبة للأحمال المعبأة في حاويات، طابق cpu.cpuset لمجموعة cgroup مع عقدة NUMA واحدة.

زمن السرقة في الأجهزة الافتراضية: %st في top هو دورات المعالج التي يستولي عليها المشرف الافتراضي (hypervisor). استمرار السرقة فوق 5% يدل على جيران مزعجين على نفس المضيف الفيزيائي — تصعّد إلى مزوّد الخدمة السحابية أو انتقل إلى مضيف مخصص. لا تظهر السرقة في مقاييس التطبيق؛ إنها تضخّم p99 بصمت.

اختناقات الذاكرة

يتجلى ضغط الذاكرة في Linux عبر آليتين منفصلتين: قاتل OOM (الحد الصارم) والمقايضة / استعادة الصفحات (الإشباع اللطيف). كلتاهما تُدهور زمن الاستجابة p99 قبل أي حدث OOM فعلي أو امتلاء ملف المقايضة.

# صورة عامة للذاكرة
free -h

# RSS والمقايضة والذاكرة الافتراضية لكل عملية
ps -eo pid,comm,rss,vsz,pmem --sort=-rss | head -15

# ضغط استعادة الصفحات — ارتفاع pgmajfault = مقايضة نشطة
vmstat 1 | awk '{print $7, $8, $10, $11}'
# الأعمدة: swpd, free, si(swap-in), so(swap-out)

# إخفاقات THP (الصفحات الكبيرة الشفافة)
grep -E 'thp_fault_alloc|thp_collapse_alloc_failed' /proc/vmstat

# USE: أخطاء — تصحيحات ذاكرة ECC (يتطلب ipmitool أو عميل المورّد)
ipmitool sel list | grep -i "correctable\|uncorrectable"

للخدمات الإنتاجية: عطّل المقايضة على العقد الحساسة لزمن الاستجابة (swapoff -a + أزل مدخلات المقايضة من /etc/fstab). عملية تصل إلى المقايضة على SSD حديث لا تزال تضيف 10–100 ميكروثانية لكل خطأ في الصفحة. يجب أن تحتوي عقد Kubernetes التي تشغّل حاويات حساسة لزمن الاستجابة على memory.swappiness=0 (أو vm.swappiness=1) محدَّدًا في ملف sysctl للعقدة.

تجزئة الذاكرة هي مصدر أكثر خفاءً لتذبذبات زمن الاستجابة. إخفاقات ضغط THP تسبب توقفات بمقدار مللي ثوانٍ في الخدمات كثيفة استخدام الذاكرة (Redis وجافا ذات الكومات الكبيرة). راقب thp_collapse_alloc_failed في /proc/vmstat واضبط /sys/kernel/mm/transparent_hugepage/enabled على madvise ليستخدم THP فقط في عمليات التخصيص التي تطلبه صراحةً.

قائمة تحقق USE — الاستخدام والإشباع والأخطاء لكل من مجالات موارد النظام الأربعة.

اختناقات إدخال/إخراج القرص

يُعدّ إشباع I/O القرص قاتلًا لقواعد البيانات والخدمات الصغيرة كثيفة الكتابة. المقياس الرئيسي هو avgqu-sz من iostat — عمق طابور ثابت يتجاوز 1 على جهاز NVMe يعني أن الجهاز متراكم عليه الطلبات. على نطاق كبير، حتى التذبذبات القصيرة في I/O ملحوظة لأنها تزيد ضغط ذاكرة التخزين المؤقت في النواة، مما يُزيح البيانات الساخنة ويفاقم المشكلة.

# إحصاءات لحظية لكل جهاز (فاصل ثانية، 10 عينات)
iostat -xz 1 10

# الأعمدة الرئيسية للمراقبة:
# %util   — استخدام الجهاز (يقترب من 100% = HDD مشبع؛ NVMe يتحمل >100% عبر NCQ)
# await   — متوسط زمن انتظار I/O بالمللي ثانية (SSD صحي: <1 ms؛ HDD: <10 ms؛ تنبيه إذا >20 ms تحت الحمل)
# avgqu-sz — عمق الطابور؛ >1 = بداية الإشباع
# r/s, w/s — IOPS؛ قارنه بالمواصفات التقنية للجهاز

# BCC biolatency — رسم بياني لزمن انتظار I/O على مستوى الكتلة
/usr/share/bcc/tools/biolatency -D 10

# تحديد أي عملية تمتلك I/O
iotop -o -b -n 3

# فحص حالة SMART (تحذير مبكر من الأعطال)
smartctl -a /dev/nvme0n1

أدوات الضبط في الإنتاج: اضبط جدولة I/O على none (المرور المباشر) لأجهزة NVMe — مجدولو النواة mq-deadline وbfq يضيفان حملًا زائدًا تتعامل معه قوائم انتظار NVMe أصلًا. تحقق باستخدام cat /sys/block/nvme0n1/queue/scheduler. بالنسبة لقواعد البيانات، يتجاوز الإدخال/الإخراج المباشر (O_DIRECT) ذاكرة التخزين المؤقت ويُزيل الازدواجية في التخزين المؤقت؛ يستخدمه PostgreSQL عبر ضبط effective_io_concurrency وتحجيم wal_buffers.

مشكلة الجار المزعج في القرص ضمن Kubernetes: تخزين الحاويات في الغالب وحدة تخزين شبكية مشتركة (EBS، GCS PD، Ceph). جميع الحاويات على نفس العقدة تتنافس على نفس ميزانية IOPS المشتركة. مهمة دفعية مُهيَّأة بشكل خاطئ تكتب 500 MB/s يمكنها تشبيع التخزين المشترك وتسبّب ارتفاعًا في زمن الاستجابة في خدمات لا علاقة لها بالأمر. احرص دائمًا على ضبط resources.limits مع فئة تخزين تراعي I/O، أو استخدم مجموعات عقد مخصصة للأحمال كثيفة I/O.

اختناقات الشبكة

يظهر إشباع الشبكة على شكل إعادة إرسال TCP، وفيض طابور الإرسال للمقبس، وإسقاطات عتاد بطاقة الشبكة — كلها غير مرئية في مقاييس مستوى التطبيق ما لم تُضف قياسًا صريحًا لها. على شبكة بسرعة 10 Gbit/s، خدمة واحدة ترسل 9+ Gbit/s من البيانات تُزاحم كل حاوية أخرى على نفس المضيف.

# إنتاجية بطاقة الشبكة مقابل سرعة الارتباط (USE: الاستخدام)
sar -n DEV 1 5
# انظر rxkB/s وtxkB/s؛ قارنها بسرعة الواجهة

# معدل إعادة إرسال TCP (USE: أخطاء — مستوى الشبكة)
nstat -az | grep -E 'TcpRetrans|TcpInErrs|TcpOutRsts'
# أو باستخدام ss:
ss -s

# عمق طابور كل مقبس (الإشباع: فيض طابور الإرسال)
ss -tnp | awk '{print $2, $3, $5}' | sort -k1 -rn | head -20
# العمود 2 = Recv-Q، العمود 3 = Send-Q؛ Send-Q غير صفري = ضغط خلفي من النواة

# BCC tcpretrans — تتبع أحداث إعادة الإرسال مع المصدر والوجهة
/usr/share/bcc/tools/tcpretrans

# عدادات إسقاط النواة (فيض حلقة المخزن المؤقت للبطاقة)
ethtool -S eth0 | grep -i drop

ضبط النواة الحيوي للخدمات عالية الإنتاجية (يُطبَّق عبر sysctl أو /etc/sysctl.d/):

# /etc/sysctl.d/99-perf.conf — ضبط شبكة الإنتاج
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.tcp_slow_start_after_idle = 0
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 250000

# تطبيق فوري (لا توجد آثار جانبية — آمن لإعادة التشغيل)
sysctl --system

TCP BBR (النطاق الترددي وزمن الذهاب والإياب للاختناق — Bottleneck Bandwidth and RTT) هو خوارزمية الازدحام التي نشرتها Google على نطاق واسع؛ تحقق إنتاجية أعلى بكثير من CUBIC في الشبكات عالية الخسارة أو عالية BDP. تفعيلها يتطلب نواة 4.9+ (أي Linux إنتاجي حديث). اقرنها بـ fq (qdisc التوزيع العادل) — لأن BBR يعتمد على التجزئة الزمنية التي يوفرها fq فقط.

ربط مقاييس النظام بنتائج اختبار التحميل

عندما تُظهر جلسة k6 ارتفاعًا في زمن الاستجابة p99 فوق 500 ms، يكون المسار التشخيصي:

تحقق من vmstat 1 — هل طابور التشغيل مُشبَع (معالج) أم هناك I/O مقايضة (ذاكرة)؟
تحقق من iostat -xz 1 — هل await مرتفع أو avgqu-sz > 1؟
تحقق من nstat -az | grep Retrans — هل إعادة إرسال TCP في تصاعد؟
إذا كانت الثلاثة نظيفة، فالاختناق على مستوى التطبيق (استنفاد مجموعة الخيوط، جمع البيانات المهملة، تنافس القفل) — انتقل إلى مخططات اللهب والتتبع على مستوى التطبيق.

ربط المقاييس مع Prometheus: صدّر مقاييس node_exporter وأنشئ لوحة USE في Grafana بلوحات لـ node_cpu_seconds_total وnode_memory_SwapTotal_bytes وnode_disk_io_time_seconds_total وnode_network_transmit_drop_total. أضف الجدول الزمني لاختبار التحميل كتعليق توضيحي في Grafana لتتمكن من ربط زيادات حركة المرور بأحداث استنفاد الموارد بصريًا — هذا إجراء تشغيلي موحّد في تحليلات ما بعد الحوادث لدى SRE.