دبيان 12 على خادم افتراضي خاص ذي ذاكرة وصول عشوائي منخفضة: كيفية تقليل أعطال نفاد الذاكرة في MySQL

يمكنك تقليل خطر توقف MySQL بسبب نفاد الذاكرة (OOM killer) على خادم افتراضي خاص (VPS) يعمل بنظام Debian 12 ذي ذاكرة وصول عشوائي منخفضة، وذلك بتحديد السبب، وتوزيع الذاكرة على جميع الخدمات، والحد من تزامن قواعد البيانات، وتوفير مساحة تبديل (swap) حيثما يسمح الخادم بذلك. لا يُعدّ تقليل حجم مخزن InnoDB المؤقت وحده حلاً كاملاً. فمساحة التبديل أو إعدادات الحماية من نفاد الذاكرة لا تضمن استمرار تشغيل أحمال العمل الكبيرة.

تم إعداد هذا الدليل في 9 أكتوبر 2026، باستخدام نظام Debian 12 "bookworm"، ونظام Linux 6.1، ووثائق Oracle MySQL 8.0/8.4. الإعدادات المذكورة أدناه هي نقاط بداية توضيحية، وليست نتائج قياس أداء أو تكوينًا عامًا. يُنصح بعمل نسخة احتياطية من قاعدة البيانات والتكوين قبل إجراء أي تغييرات، وجدولة إعادة تشغيل قاعدة البيانات عندما يكون وقت التوقف مقبولًا.

1. حدد الخادم قبل نسخ إعدادات MySQL

تم التحقق: تعتمد حزمة خادم MySQL الافتراضي في Debian 12 على MariaDB. قد يقوم خادم افتراضي خاص (VPS) يُوصف بأنه يعمل بنظام "MySQL" بتشغيل MariaDB فعليًا، بينما قد يحتوي خادم آخر على Oracle MySQL من مستودع أو حاوية منفصلة.

mysql --version
systemctl status mysql mariadb

يُحدد الأمر الأول العميل، وليس بالضرورة الخادم قيد التشغيل. اتصل باستخدام حساب مسؤول قاعدة البيانات الخاص بك، ثم نفّذ الأمر التالي:

SELECT VERSION(), @@version_comment;

استخدم طريقة المصادقة الحالية لديك؛ قد تسمح عمليات تثبيت Debian MariaDB بالإدارة المحلية باستخدامها sudo mysql. سجّل إصدار الخادم واسم الخدمة الفعلي. تستخدم أوامر الخدمة اللاحقة الأمر `server.org` mysql.service؛ استبدل `server.org` mariadb.serviceعند الاقتضاء. لا تُضِف متغيرات خاصة بـ Oracle فقط إلى إعدادات MariaDB.

2. تأكد من أن الإغلاق كان بسبب نفاد الذاكرة

سوء فهم شائع: كل إعادة تشغيل غير مبررة لقاعدة البيانات هي عملية إنهاء بسبب نفاد الذاكرة. كما يمكن أن تؤدي أخطاء المصادقة، ونفاد مساحة القرص، والتكوين غير الصحيح، والتعطلات، وإعادة تشغيل المسؤول إلى انقطاع الخدمة.

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

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

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

تحقق من حدود نظام systemd أيضًا:

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

في نظام cgroup v2، استخدم مسار ControlGroup المُبلغ عنه لقراءة البيانات memory.eventsالموجودة memory.maxضمنه memory.swap.max. /sys/fs/cgroupتحقق أيضًا من مجموعات التحكم الأصلية. يشرح دليل Linux cgroup v2 هذه العدادات والحدود. قد تنفد ذاكرة مجموعة التحكم المسموح بها حتى لو كان لدى المضيف سعة كافية. oom_killيسجل عداد عمليات الإيقاف، ولكن يجب تفسيره مع الحدود والسجلات لتحديد السبب.

3. قم بقياس الخادم الافتراضي الخاص بالكامل، وليس فقط مجموعة التخزين المؤقت.

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

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

تم التحقق: يخصص MySQL ذاكرة تتجاوز مساحة التخزين المؤقت لـ InnoDB، بما في ذلك تخصيصات متعلقة بالاتصال والاستعلام. يوثق مرجع استخدام الذاكرة في MySQL هذه المكونات. تعامل مع الصيغة المستندة إلى المخازن المؤقتة المُهيأة كتقدير تخطيطي، وليس كحد أقصى دقيق.

الإجراء: خصص مساحة كافية لنواة النظام، وعمال الويب، والمراقبة، والنسخ الاحتياطية، وعمليات قاعدة البيانات المؤقتة. إن النصيحة الشائعة بتخصيص معظم ذاكرة الوصول العشوائي (RAM) لمحرك InnoDB غير مناسبة دون تعديل على خادم افتراضي خاص مشترك. إذا استهلك عمال PHP أو عملية بناء المساحة المتاحة، فقم بضبط أو نقل هذا الحمل بدلاً من تقليص حجم MySQL بشكل متكرر.

4. أضف مساحة التبديل كذاكرة مؤقتة، وليس كذاكرة وصول عشوائي بديلة.

يعتمد الأمر على السياق: يمكن لذاكرة التبديل استيعاب بعض الضغط المؤقت على الذاكرة المجهولة، ولكن استخدامها المستمر قد يُبطئ الاستعلامات بشكل كبير. قد يُقيّد خادم VPS المُعتمد على الحاويات استخدام ذاكرة التبديل، وقد تمنع الخدمة MemorySwapMaxاستخدامها حتى عندما يكون لدى المضيف ذاكرة تبديل.

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

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

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

بعد نجاح التفعيل، أضف هذا الإدخال مرة واحدة إلى /etc/fstab:

/swapfile none swap sw 0 0

يوثّق دليل Debian swapon قيود ملف التبديل. إذا رفضت بيئة الخادم الافتراضي الخاص (VPS) التفعيل، فاسأل المزوّد عن ملفات التبديل المدعومة أو قم بزيادة ذاكرة الخطة؛ ولا تحتفظ بإعداد فاشل.

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

5. تحديد خط أساس متواضع لقاعدة البيانات

على سبيل المثال، لنفترض خادمًا افتراضيًا خاصًا (VPS) بسعة 1 جيجابايت مع عبء عمل صغير لقاعدة بيانات InnoDB وعدد قليل من تطبيقات العامل. القيم التالية هي قيم مقترحة للتقييم، وليست دليلًا قاطعًا على ملاءمة عبء العمل هذا:

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

ضع خيارات الخادم في ملف تكوين مُضمّن فعليًا في تثبيتك. قد تتضمن حزمة Oracle MySQL ملفًا /etc/mysql/mysql.conf.d/؛ بينما يستخدم Debian MariaDB عادةً ملفًا آخر /etc/mysql/mariadb.conf.d/. تحقق من توجيهات التضمين الموجودة واحتفظ بنسخة احتياطية. يشرح توثيق ملف خيارات MySQL مجموعات خيارات الخادم وكيفية التعامل مع الملفات.

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

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

6. التحكم في الجداول المؤقتة والتزامن معًا

سوء فهم شائع: تحديد tmp_table_size=16Mالحد الأقصى لذاكرة الاستعلامات عند 16 ميجابايت. هذا غير صحيح. يمكن أن تتعايش جلسات متعددة، وجداول مؤقتة متعددة، وتخصيصات تنفيذ أخرى.

بالنسبة لـ Oracle MySQL 8.4 ، تتمثل نقطة البداية التوضيحية الإضافية فيما يلي:

temptable_max_ram=64M
temptable_max_mmap=0

أضف هذه الإعدادات إلى المجموعة الحالية [mysqld]فقط بعد التأكد من دعم المنتج. فهي تتحكم في حدّ ذاكرة الوصول العشوائي المشتركة لمحرك TempTable واستخدام الملفات المؤقتة المُرتبطة بالذاكرة. ولا تُقيّد هذه الإعدادات عملية mysqld بأكملها أو جميع عمليات تخصيص الذاكرة الخاصة بكل خيط. قد تؤدي الحدود المنخفضة إلى زيادة العمليات المُسندة إلى القرص.

توضح وثائق الجداول المؤقتة في MySQL 8.4 هذه القيود. أما في MySQL 8.0، فيعتمد السلوك على الإصدار: temptable_max_mmapفقد ظهرت هذه القيود في الإصدار 8.0.23، وأصبحت tmp_table_sizeحدًا فرديًا للجداول المؤقتة في الإصدار 8.0.28. يُرجى مراجعة مرجع MySQL 8.0 قبل تطبيق الإعدادات نفسها. لا تقم بنسخ هذه الخيارات الخاصة بـ Oracle إلى MariaDB.

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

7. تحقق من التغييرات وأعد التشغيل عمداً

بالنسبة لإصدارات Oracle MySQL التي تدعم هذا الخيار، تحقق من الإعدادات قبل إعادة التشغيل:

sudo mysqld --validate-config

استخدم نفس مسار ملف الإعدادات الافتراضية ومعاملات بدء التشغيل ذات الصلة المستخدمة في الخدمة إذا لم تكن تستخدم اكتشاف التكوين الافتراضي. تشير مرجعية التحقق من صحة MySQL إلى أن التحقق لا يُهيئ كل نظام فرعي. اجتيازه لا يُعد اختبارًا لقدرة النظام على تحمل الأحمال. لا تفترض أن MariaDB تدعم خيار Oracle هذا.

أعد تشغيل الخدمة الفعلية خلال الفترة الزمنية المخطط لها، ثم افحص بدء التشغيل واستعلم عن القيم الفعالة:

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

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

8. تحديد النجاح في ظل الحمل التمثيلي

free -h
vmstat 1
cat /proc/pressure/memory

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

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

مفاهيم خاطئة قد تزيد المشكلة سوءًا

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

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