كيفية زيادة حد الذاكرة لحاوية التعليمات البرمجية على منصة Collabora Online

إذا تم إيقاف حاوية Collabora Online Development Edition (CODE) تحت ضغط عالٍ أو كانت تعمل باستمرار بالقرب من الحد الأقصى لذاكرة Docker المخصصة لها، فإن الحل العملي عادةً ما يكون رفع حد ذاكرة Docker للحاوية، وليس تغيير أي إعداد داخل Collabora نفسها. يطبق Docker حدود الذاكرة على مستوى وقت تشغيل الحاوية، وتعمل Collabora ضمن هذا الحد.

يستخدم هذا الدليل مثالًا افتراضيًا واضحًا: تخيّل فريقًا صغيرًا يُشغّل حاويةً باسمٍ ما codeعلى مضيف دوكر يعمل بنظام لينكس. تبلغ سعة الذاكرة الثابتة للحاوية 2 جيجابايت، وتقترب من هذا الحدّ خلال فترات التحرير المكثفة. قرر الفريق اختبار حدّ أقصى قدره 4 جيجابايت مع الحفاظ على ذاكرة وصول عشوائي كافية متاحة لنظام التشغيل والخدمات الأخرى. الأرقام وقيم الاستخدام في هذا المثال توضيحية فقط، وليست نتائج مُقاسة من عملية نشر حقيقية.

اعتبارًا من أكتوبر 2026، تتوافق الأوامر المذكورة أدناه مع وثائق Docker الحالية. تُعرّف وثائق Docker الخاصة بـ Collabora صورة CODE كخيار Collabora Online مُوزّع باستخدام Docker؛ وDocker هو المكوّن المسؤول عن فرض حدود موارد الحاوية. يُرجى الرجوع إلى وثائق Collabora Online CODE Docker الرسمية ووثائق قيود موارد Docker عند تكييف الخطوات مع بيئتك.

ما الذي يتغير فعلياً بزيادة حد الذاكرة

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

تُحدد وثائق Docker --memory(أو -m) الحد الأقصى لذاكرة الحاوية. كما يوفر Docker --memory-swapخيارًا للتحكم في إجمالي سعة ذاكرة الوصول العشوائي (RAM) وذاكرة التبديل (swap) عند تحديد حد أقصى للذاكرة. يمكن أن توفر ذاكرة التبديل هامش أمان، ولكن كثرة استخدامها تؤثر سلبًا على الأداء. لذا، يُنصح بتجنب استخدام ذاكرة التبديل كبديل عن الذاكرة الفعلية الكافية في خدمات تحرير النصوص المكتبية.

الخطوة الأولى: التأكد من أن ضغط الذاكرة هو المشكلة الحقيقية

ابدأ بتحديد حاوية التعليمات البرمجية قيد التشغيل ومراقبة استخدامها الحالي للموارد:

docker ps
docker stats code

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

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

الخطوة 2: قراءة حد ذاكرة Docker المُكوّن

تحقق من قيمة الذاكرة المُهيأة للحاوية مباشرةً:

docker inspect code --format '{{.HostConfig.Memory}}'

يعرض Docker هذه القيمة بالبايت. على سبيل المثال، 2147483648البايت يساوي 2 جيجابايت. يمكنك تحويلها يدويًا أو باستخدام عمليات حسابية في سطر الأوامر.

echo $((2147483648 / 1024 / 1024 / 1024))

إذا كانت قيمة الفحص فارغة 0، فإن Docker عادةً ما يتعامل مع الحاوية على أنها لا تملك حدًا أقصى صريحًا للذاكرة. في هذه الحالة، قد يكون السبب الحقيقي هو نقص في موارد المضيف، أو وجود مُنسق آخر، أو قيد مختلف. ينص Docker على أن الحاويات لا تملك قيودًا على الموارد افتراضيًا ما لم يتم تكوين حدود لها.

الخطوة 3: زيادة الحد الأقصى على حاوية لينكس موجودة

يدعم Docker تغيير حد الذاكرة لحاوية موجودة باستخدام الأمر `docker-component` docker update. على سبيل المثال، لتغيير الحد من 2 جيجابايت إلى 4 جيجابايت:

docker update --memory 4g --memory-swap 4g code

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

تُدرج وثائق تحديث حاويات Docker الحالية الإعدادات التالية كإعدادات قابلة للتحديث --memory: --memory-reservationو و --memory-swap. وتشير Docker أيضًا إلى أن docker updateغير مدعوم في حاويات Windows؛ إذ تستخدم عمليات نشر CODE عادةً حاويات Linux، ولكن هذا التمييز مهم إذا كنت تُكيّف الأمر في مكان آخر.

بعد التحديث، تحقق من كل من حالة التكوين وحالة وقت التشغيل:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

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

الخطوة الرابعة: اجعل التغيير دائمًا في Docker Compose

إذا كانت الحاوية مُدارة بواسطة Docker Compose، فقم بتحديث إعدادات Compose لتكون المصدر الموثوق. وإلا، فإن إعادة تشغيل الخدمة لاحقًا قد تُعيد الحد القديم أو تُزيل التغيير الذي طرأ أثناء التشغيل فقط.

بالنسبة لـ Docker Compose الحديث، تحدد خاصية مستوى الخدمة mem_limitمقدار الذاكرة التي يمكن للحاوية تخصيصها:

services:
  collabora:
    image: collabora/code
    container_name: code
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "9980:9980"

يوضح مرجع خدمات Docker Compose الخاص بـ mem_limit أنه mem_limitيُستخدم لضبط حد الذاكرة لحاوية الخدمة. يدعم Compose أيضًا حدود الموارد ضمن deploy.resources.limits.memory; إذا كنت تستخدم كلا الشكلين، فإن Docker يشترط أن تكون قيم الذاكرة متطابقة.

قم بتطبيق الإعدادات:

docker compose up -d

ثم تحقق من الخدمة التي تم إعادة إنشائها أو إعادة تشغيلها:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

ما مقدار الذاكرة التي يجب تخصيصها؟

لا يوجد حد آمن واحد لجميع عمليات تثبيت CODE. يعتمد الحد المناسب على عدد المحررين المتزامنين، وحجم المستند وتعقيده، وسعة المضيف، والحاويات الأخرى، وطريقة دمج الخدمة. يتضمن دليل SDK الحالي لـ Collabora أمثلة على تكوينات موارد Kubernetes، بما في ذلك مثال موجه للإنتاج مع طلبات وحدود ذاكرة متعددة الجيجابايت، ولكن لا ينبغي اعتبار ذلك صيغة عامة لتحديد حجم Docker.

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

عملية تحديد المقاسات العملية

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

ماذا عن حجز الذاكرة والتبديل؟

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

يتطلب استخدام مساحة التبديل (Swap) عناية فائقة. توضح وثائق Docker أن --memory-swapيمثل إجمالي الذاكرة بالإضافة إلى مساحة التبديل عند ضبطه على قيمة موجبة. إذا كانت --memory=4gو --memory-swap=6g، فيمكن للحاوية استخدام ما يصل إلى 4 جيجابايت من ذاكرة الوصول العشوائي (RAM) وما يصل إلى 2 جيجابايت من مساحة التبديل الإضافية. قد يمنع ذلك حدوث عطل مفاجئ في بعض الحالات، ولكن استمرار استخدام مساحة التبديل قد يُبطئ عملية التحرير التفاعلي. لذا، يُنصح بمراقبة مساحة التبديل بدلاً من افتراض أن زيادة مساحة التبديل تُعدّ تلقائيًا أكثر أمانًا.

كيف تعرف ما إذا كان التغيير قد نجح

النجاح لا يقتصر على الرؤية فحسب 4 GiB، docker statsبل إن العلامات المهمة هي تلك التي تُشير إلى العمل الفعلي.

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

إذا استمر فشل الحاوية حتى قبل الوصول إلى الحد الجديد، فغيّر المسار. افحص docker logs codeسجلات نواة النظام المضيف، وأخطاء الخادم الوكيل العكسي، وسجلات خادم التكامل، واستهلاك وحدة المعالجة المركزية أو عمليات الإدخال/الإخراج. يُعدّ حدّ الذاكرة مجرد طبقة واحدة من طبقات نشر Collabora.

أخطاء شائعة يجب تجنبها

• تغيير الحاوية قيد التشغيل فقط: docker update يمكن أن يحل الحد الفوري، ولكن يجب أيضًا تحديث الخدمات التي يديرها Compose في ملف Compose.
• منح البرنامج كل ذاكرة المضيف: يحتاج المضيف والخدمات المجاورة إلى مساحة كافية. قد يُساهم استخدام حاوية غير مقيدة في عدم استقرار المضيف ككل.
• بافتراض أن الذاكرة الافتراضية هي ذاكرة حرة: فإن الذاكرة الافتراضية أبطأ من ذاكرة الوصول العشوائي، ويحذر Docker صراحة من انخفاض الأداء عندما تقوم التطبيقات بالتبديل بشكل متكرر.
• الخلط بين ذاكرة الحاوية وذاكرة PHP: إن حد حاوية Docker CODE منفصل عن إعدادات PHP المستخدمة بواسطة تطبيقات مثل Nextcloud.
• باستخدام لقطة واحدة كدليل: قم بالقياس أثناء الطلب التمثيلي وقارن السلوك قبل التغيير وبعده.

خلاصة القول

لزيادة حد الذاكرة لحاوية Collabora Online CODE، تحقق أولاً من الوصول إلى حد Docker الحالي. بالنسبة لحاوية Linux موجودة، docker update --memory ...يمكنك تغيير الحد الأقصى أثناء التشغيل. أما بالنسبة للنشر المُدار بواسطة Compose، فاحفظ الحد باستخدام mem_limitإعدادات موارد Compose متسقة، ثم أعد إنشاء الخدمة أو حدّثها وتحقق من النتيجة.

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