تشغيل Debian 12 على خادم افتراضي خاص (VPS) ذي ذاكرة وصول عشوائي منخفضة دون حدوث أعطال ناتجة عن نفاد الذاكرة تؤدي إلى توقف MySQL

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

هل نظام Debian 12 يعمل بنظام MySQL أم MariaDB؟

تحقق من الخادم قبل تغيير إعداداته. يستخدم دبيان 12 (بوكوورم) برنامج MariaDB كحزمة افتراضية default-mysql-server؛ أما Oracle MySQL فيتم تثبيته بشكل منفصل. تشير معلومات حزمة دبيان إلى أن MariaDB هو أحد متطلبات الخادم لهذه الحزمة. نفّذ الأمر التالي:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

استخدم تعليمات MariaDB الموضحة أدناه فقط إذا كانت الخدمة المثبتة هي MariaDB. يستخدم Oracle MySQL أسماء خيارات تبدو متوافقة في كثير من الحالات، ولكن قد تختلف هياكل الحزم وأسماء الخدمات والمتغيرات المتاحة والقيم الافتراضية. راجع الدليل لمعرفة إصدار MySQL المُثبَّت لديك.

المراجع الأساسية: حزمة خادم MySQL الافتراضي لنظام Debian Bookworm ودليل استخدام الذاكرة لـ MySQL 8.0 .

كيف يمكنك معرفة ما إذا كان خطأ نفاد الذاكرة (OOM) قد تسبب في إغلاق قاعدة البيانات؟

أولاً، ميّز بين إنهاء عملية النواة بسبب نفاد الذاكرة (OOM kill) وبين خطأ في قاعدة البيانات، أو إعادة تشغيل الخدمة، أو إعادة تشغيل النظام، أو مشكلة في القرص. في نظام دبيان، journalctlاقرأ سجل النظام (systemd journal). ابحث في سجل الإقلاع الحالي وافحص سجل خدمة MariaDB.

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

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

قم بتسجيل خط الأساس أثناء تعرض الخادم لحركة مرور نموذجية، وليس فقط أثناء الخمول:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

في نظام vmstatالتشغيل، راقب عمودَي ` siforward` و`forward` soبحثًا عن نشاط مستمر لعمليات التبديل (التبديل للداخل والخارج). لا يُعد تخصيص مساحة تبديل غير صفرية بحد ذاته مشكلة؛ فالتبديل المستمر مع بطء أوقات الاستجابة يشير إلى ضغط على الذاكرة. تُوثّق لينكس معالجة أخطاء نفاد الذاكرة (OOM) كحل أخير عندما يتعذر استعادة الذاكرة بشكل كافٍ. راجع مفاهيم إدارة الذاكرة في نواة لينكس ودليل `journalctl` الخاص بدبيان .

ما الذي يجب قياسه قبل الضبط؟

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

بالنسبة لـ MariaDB، افحص الإعدادات الحالية المتعلقة بالذاكرة وذروة الاتصال:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

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

كيف يمكنك ضبط حجم قاعدة بيانات MariaDB بشكل مناسب على خادم افتراضي صغير؟

قم بإجراء تغيير واحد في كل مرة، واحتفظ بنسخة من الإعدادات الأصلية، واختبر التغييرات خلال فترة الصيانة للتأكد من عدم تأثير إعادة التشغيل على المستخدمين. تتضمن حزمة إعدادات MariaDB الخاصة بنظام Debian عادةً ملفات ضمن مجلد معين /etc/mysql/mariadb.conf.d/؛ تحقق من مجلدات التضمين النشطة في تثبيتك قبل التعديل. من الأسهل إزالة ملف صغير مُضاف بدلاً من استبدال الملف الرئيسي الخاص بالمورد.

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

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

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

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

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

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

هل يمكن أن يمنع التبديل حدوث عطل بسبب نفاد الذاكرة؟

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

إذا كان ذلك مدعومًا، يمكن إنشاء ملف تبديل بحجم 1 جيجابايت كما يلي. اضبط الحجم وفقًا لإرشادات الموفر والمساحة المتاحة على القرص، وتحقق من نتيجة كل أمر:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

لتفعيلها بعد إعادة التشغيل، أضف هذا الإدخال /etc/fstabبعد التأكد من عدم وجود إدخال مماثل بالفعل:

/swapfile none swap sw 0 0

ثم تحقق من صحة الملف sudo findmnt --verify --verboseوتأكد من ظهوره في المسار المحدد swapon --show. إذا fallocateكان الملف غير مدعوم من قِبل نظام الملفات أو إذا كان مزود الخدمة يحظر التبديل، فتوقف عن استخدامه واستخدم الإجراء المدعوم من قِبل مزود الخدمة. لا تُعطّل خاصية إيقاف العمليات بسبب نفاد الذاكرة (OOM killer) أو تُعيّن درجة حماية عالية جدًا من نفاد الذاكرة لـ MySQL: فهذا لا يُنشئ ذاكرة وقد يُعرّض باقي مكونات خادم VPS الصغير لمخاطر أكبر.

كيف تعرف أن التغييرات قد نجحت؟

راقب الخادم الافتراضي الخاص (VPS) خلال فترة انشغال عادية واحدة على الأقل. للنتيجة المفيدة عدة علامات:

• لم يتم تسجيل أي إدخالات جديدة لـ kernel OOM-kill أثناء عبء العمل الذي تسبب في الحادث سابقًا.
• يبقى MariaDB نشطًا ولا يرتفع عدد مرات إعادة تشغيله بشكل غير متوقع.
• vmstat 1لا يُظهر عمليات التبديل المستمرة في ظل حركة المرور العادية.
• يظل التطبيق سريع الاستجابة، وتبقى ذروة اتصالات قاعدة البيانات أقل من الحد الأقصى الجديد دون حدوث أخطاء في الاتصال.
• اكتملت عمليات النسخ الاحتياطي، وما زالت استعلامات قاعدة البيانات تلبي زمن الاستجابة المقبول للتطبيق.

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

متى يصبح التعديل غير مناسب كحل؟

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

في حال استخدام Oracle MySQL بدلاً من MariaDB الافتراضي في Debian، تأكد من اسم الخدمة ومسار ملف الخيارات ومتغيرات الذاكرة بالرجوع إلى دليل الخادم المُحدّث قبل تطبيق هذه الأمثلة. في كلا النظامين، احتفظ بنسخ احتياطية مُختبرة، وغيّر متغيرًا واحدًا في كل مرة. لا يضمن هذا النجاح عدم حدوث أخطاء نفاد الذاكرة في Linux، بل هو دليل على أن الخادم الافتراضي الخاص (VPS) لديه سعة كافية لأحمال العمل القصوى، وأن MySQL أو MariaDB لم تعد تُسبب هذه الأخطاء بشكل متكرر.

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