تحسين متقدم لنواة لينكس باستخدام sysctl

إنفورماتيك ديجيتال » موارد » تحسين متقدم لنواة لينكس باستخدام sysctl

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

تُتيح نواة النظام مئات الخيارات المتعلقة بالشبكة والذاكرة ونظام الملفات وجدولة العمليات، والتي يمكن تعديلها أثناء التشغيل. باستخدام هذه الأداة sysctl وبعض التعديلات في /procمن الممكن تحقيق أقصى استفادة من الأجهزة وتحقيق زمن استجابة أقل، وإنتاجية أعلى، واستقرار أفضل ينطبق هذا على خوادم الويب وقواعد البيانات، بالإضافة إلى بيئات الوقت الفعلي وKubernetes. ومع ذلك، من الضروري معرفة ما تفعله بالضبط وكيفية قياسه.

ما هو sysctl وكيف يقوم بتنظيم معلمات النواة؟

خدمة sysctl إنها البوابة لتغيير معلمات النواة دون الحاجة إلى إعادة التجميع أو إعادة التشغيل، مما يسمح قراءة القيم وتعديلها أثناء التشغيل لاختبار التكوينات على الفور. يتم تنظيم هذه المعلمات في شجرة هرمية منخفضة. /proc/sys/ويتحكم كل واحد منها في سلوك محدد للنظام.

تُصنَّف الإعدادات في فئات متميزة، مما يُسهِّل تحديد ما تحتاج إلى تعديله عند مواجهة مشكلة معينة في الأداء أو الاستقرار. يُمكِّنك هذا الهيكل من التركيز، على سبيل المثال، على الشبكة (net.*) أو الذاكرة (vm.*) أو نظام الملفات (fs.*) فقط ، دون التشتت في بقية خيارات النواة.

الفئات الرئيسية التي ستجدها في /proc/sys/ وتشمل هذه، من بين أمور أخرى:

• kernel.*: خيارات النواة العامة (المجدول، معرف العملية، الرسائل، NUMA، إلخ).
• vm.*: إدارة الذاكرة الافتراضية، والتبديل، وذاكرة التخزين المؤقت، وسياسات تجاوز الالتزام.
• شبكة.*: حزمة بروتوكولات الشبكة IPv4/IPv6، ومخازن TCP/UDP المؤقتة، وقوائم الانتظار، والتحكم في الازدحام.
• fs.*: حدود الواصفات، والعقد، وinotify، وAIO، وسلوك VFS.
• dev.*: معايير محددة لأجهزة وبرامج تشغيل معينة.

مع sysctl -a يمكنك سرد جميع المعلمات المتاحة، وباستخدام أوامر مثل sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse قراءة قيم محددة، وهو أمر أساسي لـ قم بمراجعة التكوين الحالي قبل إجراء أي تغيير. للعثور على شيء محدد، من الشائع استخدام التصفية باستخدام grepعلى سبيل المثال: sysctl -a | grep tcp.

تعديل المعلمة أثناء التشغيل بسيط مثل استخدام sysctl -w clave=valorمع ذلك، من المهم فهم أن هذه التغييرات مؤقتة. لحفظها بعد إعادة التشغيل، من الضروري عمل نسخة احتياطية من الإعدادات. /etc/sysctl.conf أو في ملفات /etc/sysctl.d/وعادةً ما يتم استخدام ملفات مرقمة (على سبيل المثال 10-network.conf, 20-memory.conf, 99-custom.conf) التي تحدد ترتيب تطبيقها.

القياس قبل اللمس: المعايير الأساسية وأساسيات النظام

قبل البدء بتعديل الإعدادات، من الحكمة تحديد مستوى أداء أساسي موضوعي . فبدون بيانات سابقة، يستحيل معرفة ما إذا كانت التغييرات قد حسّنت النظام أم أساءت إليه، وستقع في فخ "يبدو لي أفضل"، وهو أمر غير مجدٍ لاتخاذ قرارات سليمة.

على مستوى النظام ككل، يُنصح بجمع إحصائيات وحدة المعالجة المركزية، والحمل، والذاكرة، والقرص، والشبكة لبضع دقائق تحت حمل نموذجي. أدوات مثل uptime, mpstat, vmstat, iostat -x o sar -n DEV تتيح لك هذه الأدوات رؤية كيفية عمل نواة النظام الأساسية، ومقدار الذاكرة الافتراضية التي تستخدمها، وكيفية استجابة عمليات الإدخال/الإخراج للقرص، وما إذا كانت الشبكة مشبعة أو تهدر عرض النطاق الترددي.

بالإضافة إلى تلك النظرة العامة، من الضروري إجراء اختبارات قياس أداء محددة للتطبيق الذي ترغب في تحسينه. على خوادم الويب، يمكنك استخدام ab (أباتشي بنش) أو أدوات مماثلة للقياس عدد الطلبات في الثانية، ومتوسط ​​زمن الاستجابة، والأخطاءفي قواعد البيانات، أدوات مثل mysqlslap o sysbench فهي تساعد في تقييم عدد المعاملات في الثانية الواحدة وأوقات الاستعلام.

على سبيل المثال، في سيناريو بدون تعديل، من الشائع إيجاد أرقام مثل 500 طلب HTTP/ثانية بمتوسط ​​زمن استجابة 200 مللي ثانية، وحوالي 250 استعلام SQL/ثانية بزمن استجابة 40 مللي ثانية، وسرعة شبكة تقارب 500 ميجابت/ثانية، وحمل نظام يقترب من حده الأقصى تحت الضغط. ستُستخدم هذه الأرقام للتحقق، بعد تطبيق تغييرات النواة، مما إذا كان قد تم تحقيق زيادة ملموسة في الإنتاجية وانخفاض في زمن الاستجابة.

أخيرًا، وثّق الأوامر والنتائج قبل إجراء أي تغييرات. سيُمكّنك وجود سجلّ من مقارنة مجموعات التعديلات المختلفة بدقة، كما سيساعدك على اكتشاف أيّ تراجع في الأداء بعد تحديث نواة النظام أو بعد إضافة ملف تعريف sysctl جديد في بيئة الإنتاج.

إعدادات الذاكرة المتقدمة: vm.*

تُعدّ الذاكرة أحد الأنظمة الفرعية التي تظهر فيها تغييرات النواة بشكلٍ ملحوظ. قد ينتهي الأمر بخادمٍ يمتلك ذاكرة وصول عشوائي (RAM) كبيرة، ولكنه مُهيّأ بشكلٍ سيئ، إلى استخدام مساحة التبديل دون داعٍ، مما يتسبب في... ارتفاعات مفاجئة في عمليات الإدخال/الإخراج وانخفاضات حادة في الأداءولهذا السبب توجد معايير مثل vm.swappinessتُعد نسب الصفحات المتسخة أو سلوك ذاكرة التخزين المؤقت لنظام الملفات الافتراضي بنفس القدر من الأهمية.

معامل vm.swappiness يتحكم هذا الإعداد في مقدار صفحات الذاكرة التي يرسلها نظام التشغيل إلى مساحة التبديل. في العديد من التوزيعات، يُضبط على 60، وهي قيمة مُخصصة لبيئات سطح المكتب المختلطة. أما بالنسبة لخوادم قواعد البيانات أو التطبيقات ذات زمن الاستجابة المنخفض، فمن الأفضل عادةً خفضه إلى 10 أو أقل، مما يُؤدي إلى نظام أكثر كفاءة. إعطاء الأولوية للاحتفاظ بالبيانات في ذاكرة الوصول العشوائي (RAM) وتقليل التبديلليس من غير المألوف أن نرى انخفاضًا حادًا في حركة مرور القرص واستجابة التطبيقات بتذبذب أقل بكثير بعد هذا التعديل.

لبنة بناء أساسية أخرى هي vm.dirty_ratio y vm.dirty_background_ratioتحدد هذه القيم النسبة المئوية للذاكرة التي يمكن ملؤها بالصفحات المتسخة قبل أن تبدأ النواة في كتابتها إلى القرص. قد تؤدي القيم المرتفعة للغاية إلى دفعات كبيرة من عمليات الكتابة، مع زمن استجابة هائل لجميع التطبيقات عند حدوث الكتابة. عادةً ما يؤدي خفض هذه النسب إلى أرقام مثل 15 و5 على التوالي إلى نمط إدخال/إخراج أكثر اتساقًا وقابلية للتنبؤ.

وضع vm.vfs_cache_pressure يُحدد هذا مدى سرعة قيام نواة النظام بتنظيف ذاكرة التخزين المؤقت للملفات (inode) والمجلدات. القيمة الافتراضية 100 تُسرّع عملية التنظيف، بينما تسمح الإعدادات التي تقارب 50 بالاحتفاظ بالبيانات الوصفية لفترة أطول، مما يزيد من معدل نجاح عمليات الملفات ويُحسّن الأداء. الأداء المتوقع لنظام الملفات، وهو أمر أساسي في الخوادم التي تتعامل مع ملايين الملفات الصغيرة.

من جانبها، vm.min_free_kbytes يُنصح بتخصيص حد أدنى من الذاكرة الحرة لضمان استجابة النظام لزيادة تخصيص الذاكرة دون حدوث أعطال مفاجئة. عادةً ما يكون تخصيص ما بين 0,5% إلى 1% من إجمالي ذاكرة الوصول العشوائي إجراءً وقائيًا فعالًا لمنع نواة النظام من نفاد المساحة تحت ضغط عالٍ، وبالتالي تجنب إيقاف العمليات الحيوية، مما يُحسّن الأداء. استقرار المضيف بشكل عام.

وأخيرًا، تستحق سياسة الالتزام الزائد الاهتمام: معايير مثل vm.overcommit_memory y vm.overcommit_ratio تحدد هذه الإعدادات مقدار الذاكرة الافتراضية المخصصة للعمليات نسبةً إلى ذاكرة الوصول العشوائي (RAM) وذاكرة التبديل المتاحة. في بعض الحالات (على سبيل المثال، مع Redis أو قواعد بيانات معينة) يُسمح بالتخصيص المفرط، بينما في حالات أخرى يُفضل اتباع سياسة أكثر تحفظًا للحد من مخاطر نفاد الذاكرة وحالات ضعف الذاكرة بشكل مفرطللاطلاع على تقنيات تحليل وتشخيص الحالات المعقدة، يُرجى الرجوع إلى تصحيح أخطاء الذاكرة في لينكس.

تحسين الشبكة المتقدم: net.* و TCP/IP

ربما تكون بنية الشبكة هي المجال الذي يظهر فيه التحسين بشكل ملحوظ في بيئات الإنتاج. يمكن لتغيير بسيط في قوائم انتظار الاتصال أو المخازن المؤقتة أن يُحدث فرقًا كبيرًا بين خادم يعاني من بطء شديد عند سرعة 500 ميجابت في الثانية وآخر يعمل بكفاءة أعلى. إنها تشبع بسهولة سرعة الجيجابت.المعايير ضمن net.core.* y net.ipv4.* في هذا المجال، هم أفضل حلفائك.

بدايةً، تؤثر أحجام مخزن المقابس بشكل مباشر على الحد الأقصى لإنتاجية الاتصال، خاصةً عند وجود زمن استجابة عالٍ أو روابط ذات سعة عالية. اضبط net.core.rmem_max y net.core.wmem_max إلى قيم سخية (عشرات أو مئات الميغابايت) وتحديدها بشكل صحيح net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (الحد الأدنى، والقيمة الافتراضية، والحد الأقصى) يسمح لكل مقبس بالحصول على المساحة اللازمة لتخفيف حدة الازدحام المروري دون الوقوع في القيود المصطنعة التي تفرضها قيم المصانع المحافظة للغاية.

ومن النقاط الرئيسية الأخرى حجم قوائم انتظار الاتصال. وتشمل المعلمات ما يلي: net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog تحدد هذه الحدود عدد الاتصالات المعلقة التي يمكن للنظام معالجتها قبل إسقاط الحزم أو رفض المصافحة. في خوادم الويب ذات حركة المرور العالية، يمكن أن يؤدي رفع هذه الحدود إلى منع ازدحام قوائم الانتظار وتقليل الحمل بشكل كبير. أخطاء الاتصال أثناء ذروة الأحمال.

يمكن أيضًا ضبط سلوك اتصالات TCP بدقة باستخدام العديد من الخيارات: تمكين net.ipv4.tcp_window_scaling لدعم النوافذ الكبيرة على الروابط ذات النطاق الترددي العالي، قم بتمكين net.ipv4.tcp_sack y net.ipv4.tcp_timestamps لتحسين إدارة الفقد وإعادة الإرسال، أو لتعديلها net.ipv4.tcp_fin_timeout وإدارة TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) من أجل التحكم في استهلاك الموارد على الخوادم التي ملايين الاتصالات القصيرة في الدقيقة.

يُعد اختيار خوارزمية التحكم في الازدحام أمرًا مهمًا أيضًا. على الرغم من ذلك cubic لا تزال هذه القيمة هي القيمة الافتراضية في العديد من التوزيعات؛ التغيير إلى bbr في النواة الحديثة (4.9 وما بعدها) بواسطة net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq يمكنه مضاعفة إنتاجية بروتوكول TCP في البيئات ذات الخسائر أو زمن الاستجابة المعقد، محققًا تحسينات تتراوح بين 2 و25 ضعفًا مقارنةً بالتكوينات التقليدية في سيناريوهات معينة، على حساب سلوك مختلف إلى حد ما في الشبكات المزدحمة.

يجب ألا ننسى معايير السلامة والموثوقية مثل: net.ipv4.tcp_syncookiesمعالجة عمليات إعادة التوجيه (net.ipv4.conf.all.accept_redirects, send_redirects) أو الترشيح في الجسور (net.bridge.bridge-nf-call-iptables في بيئات Kubernetes). عند تهيئتها بشكل صحيح، تسمح لك بحماية النظام من الهجمات الشائعة (مثل هجمات SYN flood، وانتحال الهوية، وما إلى ذلك) دون التضحية بـ أداء شبكة قويللحصول على دليل عملي حول القواعد والكشف، راجع تطبيق Netfilter و Suricata.

نظام الملفات، والوصفات، والحدود العامة: fs.* و ulimit

في الخوادم الحديثة، يُعدّ انخفاض حدّ مُعرّفات الملفات أسرع طريقة لتعطيل النظام خلال ساعات الذروة. عندما يواجه خادم الويب أو الخادم الوكيل العكسي أو قاعدة البيانات خطأ "عدد كبير جدًا من الملفات المفتوحة"، فغالبًا ما يكون ذلك بسبب عدم ضبط معلمات النواة وحدود المستخدم بما يتناسب مع الحمل الفعلي.

على الصعيد العالمي، fs.file-max يُحدد هذا عدد الواصفات التي يُمكن أن يفتحها النواة إجمالاً. بالنسبة للتطبيقات التي تحتوي على آلاف الاتصالات المتزامنة، من الشائع زيادة هذه القيمة إلى عدة ملايين، بالإضافة إلى زيادة في fs.nr_openوهذا يحدد الحد الأقصى لعدد المؤشرات لكل عملية. بالإضافة إلى ذلك، يلزم إجراء تعديلات. /etc/security/limits.conf بحيث يكون لدى المستخدمين (أو الخدمات التي يديرها نظام systemd) القيم المرنة والصلبة المتوافقة مع تكوين النواة.

يتم التحكم في النظام الفرعي inotify، المستخدم على نطاق واسع من قبل بيئات التطوير المتكاملة وأدوات تطوير الويب وأنظمة مراقبة الملفات، بواسطة معلمات مثل fs.inotify.max_user_watches y fs.inotify.max_user_instancesإذا واجهت أخطاءً متعلقة بالمراقبين أو العمليات التي تتوقف عن مراقبة تغييرات القرص، فربما تحتاج إلى قم بزيادة هذه الحدود لتجنب الاختناقات الصامتة.

ومن الميزات الأخرى ذات الصلة الإدخال/الإخراج غير المتزامن (AIO)، والذي يتم تحديد الحد الأقصى العالمي له بواسطة fs.aio-max-nrفي التطبيقات التي تعتمد بشكل كبير على الإدخال/الإخراج غير المتزامن (بعض محركات قواعد البيانات، وأنظمة قوائم الانتظار، وما إلى ذلك)، فإن زيادة ذلك تمنع النواة من نفاد الفتحات لعمليات الإدخال/الإخراج غير المتزامن تحت حمل طلبات هائل.

بالإضافة إلى هذه المعايير، يتأثر أداء النظام الفرعي للقرص بـ مُجدول الإدخال/الإخراج يتم تكوينها على كل وحدة تخزين. في الأنظمة التي تحتوي على أقراص SSD أو NVMe، يُنصح عادةً باستخدام مُجدولات خفيفة الوزن مثل none o mq-deadlineبينما قد تكون هناك خيارات أخرى منطقية في حالة الأقراص الميكانيكية، مثل bfq حسب نوع الحمل. اضبط المجدول من خلال /sys/block/<disco>/queue/scheduler وضبط الخيارات بدقة مثل عمق قائمة الانتظار (nr_requests) أو read_ahead_kb يمكن أن يحدث فرقًا ملحوظًا في زمن استجابة القراءة/الكتابة ومعدل نقل البياناتمن المهم أيضًا مراعاة أنظمة الملفات وبرامج التشغيل المستخدمة؛ على سبيل المثال، المقالات المتعلقة بـ نظام الملفات NTFSplus على لينكس ويمكن أن تساعد الأنظمة الأخرى عند تصميم الأحمال غير المتجانسة.

وأخيرًا، لا ينبغي أن ننسى أن هذه القيود على النواة يجب أن تترافق مع تكوينات النظام مثل تلك الخاصة بـ ulimit ووحدات systemd، لضمان قدرة الخدمات على استخدام الموارد الإضافية المحددة فعليًا وعدم حظرها بواسطة القيود في الطبقات العليا.

النواة العامة، وNUMA، وتقارب وحدة المعالجة المركزية، والصفحات الضخمة

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

معلمات مثل kernel.pid_max تحدد هذه الإعدادات الحد الأقصى لنطاق معرّفات العمليات التي يمكن للنظام تعيينها، وهو أمر مهم للعُقد التي تُشغّل عددًا كبيرًا من الحاويات أو العمليات المؤقتة. (تعديل خيارات تسجيل النواة (kernel.printkيساعد ) في تقليل الضوضاء الزائدة في سجل النظام (dmesg) مع الاستمرار في تسجيل الأحداث الهامة، مما يؤثر بشكل غير مباشر على القدرة التشخيصية والاستقرار.

فيما يتعلق ببنية الذاكرة، فإن المعلمة kernel.numa_balancing يتحكم هذا الخيار في مدى قيام النواة بنقل الصفحات تلقائيًا بين عقد NUMA. ويسمح تعطيله في بيئات معينة بإدارة أكثر دقة لتقارب العمليات والذاكرة، باستخدام أدوات مثل numactl لضمان بقاء العمليات التي تستهلك موارد المعالج والذاكرة بكثافة على نفس العقدة، مما يقلل من زمن الاستجابة الناتج عن الوصول عن بعدلفهم التفاعل بين الأجهزة وجدولة العمليات الأساسية بشكل أفضل، من المفيد أيضًا مراجعة تقنيات مثل مدير موضوع إنتل.

الصفحات الضخمة (vm.nr_hugepagesتُعدّ هذه العناصر مكونًا رئيسيًا آخر في أنظمة قواعد البيانات أو غيرها من أحمال العمل التي تتعامل مع مساحات كبيرة من الذاكرة المتجاورة. ويمكن لحجز عدد مناسب من الصفحات العملاقة (2 ميجابايت أو حتى 1 جيجابايت، حسب بنية النظام) أن يقلل من الحمل الزائد لذاكرة الترجمة السريعة (TLB) ويُحسّن بشكل ملحوظ أداء التطبيقات التي تعمل عليها. العديد من العمليات على كتل كبيرة من الذاكرةلكي يكون هذا فعالاً، يجب تنسيق تكوين النواة مع التطبيق نفسه، بحيث يستخدم تلك الذاكرة بشكل صريح.

في مجال زمن الاستجابة وجدولة المهام، توجد معلمات جدولة مثل: kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsتُحسّن هذه الإعدادات حجم "وحدات" المعالج المخصصة لكل مهمة، وسرعة نقل النواة للعمليات بين النوى. تشير القيم الأصغر إلى نظام أكثر قابلية للمقاطعة، مما يُتيح عادةً... أفضل إجابة للمهام التفاعلية أحيانًا على حساب القليل من الإنتاجية الخام.

في الأنظمة التي تُعد فيها الذاكرة مورداً حساساً، يختار بعض المسؤولين تفعيل وضع الطوارئ في حالة حدوث خطأ غير متوقع (vm.panic_on_oom) وضبط kernel.panic مع وقت إعادة تشغيل تلقائي. هذه الاستراتيجية، على الرغم من كونها جذرية إلى حد ما، يمكن أن تكون مفيدة في بيئات التوافر العالي حيث إعادة التشغيل السريعة والمتحكم بها أفضل من وجود مضيف متوقف وغير مستقر. خلال ساعات.

ملفات تعريف متخصصة: الويب، قواعد البيانات، زمن الاستجابة المنخفض، وKubernetes

بدلاً من تطبيق حل سحري واحد، من الأفضل إنشاء ملفات تعريف sysctl مُخصصة لأنواع مختلفة من أحمال العمل: خوادم الويب، وقواعد البيانات، ومنصات الحاويات، أو الأنظمة منخفضة زمن الاستجابة. يتم توزيع هذه الإعدادات في ملفات مثل 99-webserver.conf, 99-database.conf o 90-kubernetes.conf مساعدة ل الحفاظ على تكوين منظم وسهل التحديثيمكنك أيضًا النظر في التوزيعات والإصدارات الموجهة نحو الأداء مثل إصدار خادم CachyOS للبيئات المحددة للغاية.

بالنسبة لخوادم الويب (Nginx، Apache، الخوادم الوكيلة، إلخ)، فإن الشيء الأساسي هو التعامل مع كميات كبيرة من الاتصالات المتزامنة مع قوائم انتظار كبيرة وأوقات استجابة طويلة. FIN_WAIT مع الضبط الدقيق، ونطاق المنفذ المؤقت الموسع، وحدود الواصفات العالية جدًا، من الشائع الانتقال من بضع مئات من طلبات HTTP في الثانية إلى عدة آلاف، مما يقلل من متوسط ​​زمن الوصول ويقضي على الأخطاء. قوائم انتظار مشبعة أو منافذ ممتلئة.

على جانب قواعد البيانات (MySQL، PostgreSQL، وما شابهها)، تُعطى الأولوية لتقليل استخدام الذاكرة الافتراضية، وتحسين كتابة الصفحات المتغيرة، وإعدادات الذاكرة المشتركة والإشارات المناسبة للمحرك. وتشمل المعلمات ما يلي: kernel.shmmax, kernel.shmall, kernel.sem ويُحدث تكوين الصفحات الضخمة فرقًا من حيث عدد المعاملات في الثانية الواحدة ووقت الاستجابة، مما يؤدي إلى مضاعفة الأداء بمقدار اثنين أو ثلاثة مقارنة بالقيم الافتراضية في العديد من السيناريوهات.

بالنسبة للتطبيقات ذات زمن الاستجابة المنخفض للغاية (التداول، الألعاب عبر الإنترنت، المعالجة في الوقت الفعلي)، تتم إضافة إعدادات أكثر تحديدًا: net.ipv4.tcp_low_latency، تعطيل خاصية البدء البطيء بعد فترة من عدم النشاط، استخدام tcp_fastopenمعلمات استطلاع الانشغال (net.core.busy_poll, busy_read) وفي كثير من الحالات، تعطيل الصفحات الضخمة الشفافة بواسطة /sys/kernel/mm/transparent_hugepage/enabledيهدف كل هذا إلى الحد من يبلغ طول قائمة الانتظار وزمن الاستجابة ذروتهما عند النسب المئوية العالية.، محققاً تحسينات مذهلة في P99.

في بيئات الحاويات وKubernetes، تتعرض بنية الشبكة وتتبع الاتصالات لضغط شديد. وتتأثر معايير مثل net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxيُعد استخدام المنافذ المحجوزة لـ NodePort أو تعديل جداول ARP أمراً شائعاً في العُقد التي تتعامل مع مئات أو آلاف من الحاويات. ويؤدي تعديلها بشكل صحيح إلى تجنب حدوث مشاكل. الاتصالات المقطوعة، أو انتهاء المهلة، أو امتلاء الجدول باستخدام conntrack.

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

أدوات تحليل ومراقبة أداء النواة

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

من بين المرافق اليومية vmstat, iostat, sar, ss, slabtop, htop o pidstatوالتي توفر معلومات سريعة حول العمليات، ووحدة المعالجة المركزية، والإدخال/الإخراج، والمنافذ، واستخدام ذاكرة التخزين المؤقت. بالإضافة إلى سجلات النظام والمقاييس المصدرة إلى Prometheus أو Grafana أو collectd، ومع موارد مثل نظام مراقبة متقدم لنظام لينكسإنها تعطي صورة كاملة إلى حد ما عن كيفية تصرف المضيف قبل وبعد كل عملية ضبط.

وللخوض في مزيد من التفاصيل، أدوات مثل perf تتيح هذه الأدوات تحليل استخدام وحدة المعالجة المركزية على مستوى الوظائف، سواء على مستوى المستخدم أو النواة، وتسجيل الأحداث لبضع ثوانٍ أو دقائق، ثم تقديم تقرير تفاعلي. perf stat, perf record y perf report يمكنك ان ترى أين يتم استهلاك وقت وحدة المعالجة المركزية فعليًا وما هي النسبة التي تتوافق مع النواة، على سبيل المثال، تحديد عاصفة انقطاعات أو جدولة غير مضبوطة بشكل جيد.

إذا كنت بحاجة إلى مزيد من التفصيل، ftrace يُتيح نظام التتبع الفرعي في نواة النظام إمكانية تفعيل أدوات تتبع مُحددة (مثل أداة تتبع الدوال) وفحص الاستدعاءات التي تحدث في الوقت الفعلي أو بعد وقوع الحدث. يتم تفعيل أداة التتبع المناسبة وتحليل محتوياتها. /sys/kernel/debug/tracing/trace يكشف لك نقاط ساخنة داخل النواة نفسهايُعد هذا مفيدًا للغاية عندما لا تكفي المقاييس عالية المستوى.

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

وأخيرًا، في مراحل اختبار الإجهاد المطولة (24 ساعة أو أكثر)، تُستخدم أدوات مثل stress-ng بالإضافة إلى الجمع المستمر للمقاييس (عبر vmstat, iostat, sar) تسمح لك بتقييم استقرار النظام مع تكوين النواة الجديد، والتحقق من عدم وجود أحداث نفاد الذاكرة، أو أعطال، أو عمليات إعادة تشغيل غير متوقعة، أو تدهور تدريجي في الأداء تحت الحمل المستمر.

إن تحسين نواة لينكس باستخدام sysctl وآليات أخرى ليس مهمةً تُنجز لمرة واحدة، بل هو عملية متكررة تتضمن قياس النتائج، وتعديل المعايير، وتوثيق كل شيء بدقة. باتباع منهجية واضحة، وتحديد ملفات تعريف خاصة لكل نوع من أنواع أحمال العمل، واستخدام مجموعة قوية من أدوات تحليل الأداء، والتحكم الصارم في التغييرات، يُمكن تحقيق خوادم تستغل مواردها المادية بالكامل، مع زيادة في الإنتاجية، وتقليل زمن الاستجابة، واستقرار أكبر بكثير من التكوين الافتراضي للمصنع.