ارفع الحد الأقصى لذاكرة حاوية التعليمات البرمجية دون تخمين

لزيادة سعة الذاكرة لحاوية Collabora Online CODE، ارفع حدّ Docker في الإعدادات التي أنشأتها، ثم أعد إنشاء الحاوية وتأكد من الحدّ الفعلي باستخدام docker inspectالأمر المناسب docker stats. زيادة إعدادات التطبيق لا ترفع حدّ Docker للحاويات، ويجب أن يتوفر لدى المضيف أو الجهاز الظاهري لـ Docker Desktop ذاكرة كافية لتطبيق حدّ أعلى.

مثال افتراضي مُستخدم في جميع أنحاء هذا النص: يدير رايلي نشر Docker Compose على مضيف واحد. لنفترض docker statsأن الحد الأقصى لحجم البيانات هو 2 جيجابايت، وأن الاستخدام يقترب من هذا الحد أثناء فتح عدة مستندات. يفكر رايلي في تحديد حد أقصى قدره 4 جيجابايت. هذه الأرقام أمثلة توضيحية فقط، وليست توصية بشأن حجم Collabora، أو ادعاءً بالأداء، أو نتيجة اختبار؛ يجب أن يستند الحد الأقصى إلى الحمل الفعلي وسعة المضيف.

1. تأكد من أن الحاوية تلامس غطائها بالفعل

قم بتشغيل هذه الأوامر على مضيف Docker، collaboraمع استبدال باسم الحاوية الفعلي:

docker stats --no-stream collabora
docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora

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

قبل زيادة الحد الأقصى، تحقق من مقدار ذاكرة الوصول العشوائي (RAM) المتبقية لنظام التشغيل والخدمات الأخرى. توصي إرشادات موارد Docker باختبار متطلبات التطبيق وتشغيل الحاويات على مضيفين ذوي موارد كافية. في Docker Desktop، تحقق أيضًا من الإعدادات > الموارد : الذاكرة المخصصة لجهاز Docker الظاهري هي حد أقصى منفصل مشترك بين حاوياته. لا يمكن لزيادة حد CODE عن هذا التخصيص إنشاء ذاكرة فعلية إضافية؛ راجع إعدادات موارد Docker Desktop .

2. تغيير حد خدمة Compose

عدّل خدمة CODE الحالية في ملف Compose الخاص بك. احتفظ بعلامة الصورة والمنافذ والبيئة ووحدات التخزين والشبكات وسياسة إعادة التشغيل الحالية؛ أضف أو حدّث إعدادات الذاكرة فقط. بالنسبة لمثال رايلي الافتراضي بحجم 4 جيجابايت:

services:
  collabora:
    image: collabora/code:your-current-tag
    mem_limit: 4g
    # Keep the service’s existing settings below

يستخدم هذا المثال صورة Docker الرسمية من Collabora (CODE) ؛ احتفظ بالوسم المستخدم بالفعل في عملية النشر. mem_limitيمثل هذا حدًا أقصى ثابتًا، وليس حجزًا: يمكن لـ Docker السماح للحاوية باستخدام ما يصل إلى هذا المقدار، لكن هذا الإعداد لا يحجز هذا القدر من ذاكرة الوصول العشوائي (RAM) على المضيف. يحدد مرجع خدمة Docker Composemem_limit هذا الحد ، وينص على وجوب توافقه مع هذا deploy.resources.limits.memoryالحد في حال وجود كليهما. إذا كانت عملية النشر تستخدم مُنسقًا أو ملف Compose مُدارًا من قِبل النظام الأساسي، فاستخدم حقل الموارد المدعومة في ذلك النظام الأساسي، وحافظ على اتساق قيم الحد المكررة.

إذا شغّلتَ الكود مباشرةً باستخدام الأمر `cd` docker run، فأعد إنشاءه من الأمر الأصلي باستخدام الأمر `cd` --memory=4gمع الاحتفاظ بجميع خياراته الحالية. ولإجراء تغيير سريع أثناء تشغيل حاوية لينكس موجودة، يدعم Docker أيضًا الأمر `cd` docker update --memory 4g <container_name>. اعتبر ملف Compose أو أمر التشغيل الأصلي هو المصدر الموثوق، حتى لا يؤدي استبداله لاحقًا إلى استعادة الإعدادات القديمة. راجع مرجع تحديث حاوية Docker .

3. أعد كتابة الكود بحيث يتم تطبيق الحد المحفوظ

من الدليل الذي يحتوي على ملف Compose النشط، تحقق من صحة التكوين المدمج، ثم أعد إنشاء خدمة CODE فقط:

docker compose config
docker compose up -d --no-deps --force-recreate collabora

استخدم مفتاح الخدمة من ملفك بدلاً من المفتاح الافتراضي collabora. راجع الإعدادات المُعالجة للحد الجديد قبل تطبيقه. إعادة إنشاء الكود تُقاطع جلسات التحرير التي تعتمد على هذا الحاوية لفترة وجيزة، لذا جدوِل التغيير عندما يكون انقطاع الخدمة لفترة قصيرة مقبولاً. لا تُزِل وحدات التخزين أو تُشغّل الأمر docker compose down -v؛ فهذه العمليات غير ضرورية لتغيير حد الذاكرة، وقد تُؤدي إلى حذف بيانات دائمة تابعة لخدمات أخرى.

4. تحقق من الغطاء الجديد وتحقق من سلوكه تحت الحمل

بعد عودة الخدمة، تحقق من الحاوية الفعلية - وليس فقط ملف YAML:

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora
docker stats --no-stream collabora

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

إذا استمرت المشكلة

إذا كان الحد الأقصى الجديد موجودًا ولكن لا يزال CODE يُعاد تشغيله، فافحص docker inspectالحالة، docker logsوسجل أحداث نواة النظام المضيف أو أحداث Docker بحثًا عن سجل نفاد الذاكرة. إذا ظل الحاوية سليمًا ولكن معالجة المستندات لا تزال تُؤدي إلى عملية التنظيف، فقد لا يكون Docker هو عنق الزجاجة النشط. يتميز تكوين Collabora بسلوك إدارة ذاكرة منفصل عن حد مجموعة التحكم (cgroup) الخاص بـ Docker؛ ويوثق قالب تكوينcoolwsd المشروع عناصر التحكم الخاصة به من جانب الخادم. تحقق من تكوين إصدار CODE المُثبَّت لديك قبل إجراء أي تغييرات.

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