منع خادم مستندات ONLYOFFICE من نفاد ذاكرة الخادم الافتراضي الخاص (VPS).

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

1. أثبت أن ضغط الذاكرة هو سبب الفشل

ابدأ من خادم Linux VPS، وليس من إعدادات تكامل ONLYOFFICE. قد يكون سبب ظهور رسالة في المتصفح مثل "لا يمكن تحميل المستند" مشاكل في الشبكة أو المصادقة، لذا من المهم التأكد مما إذا كان نظام Linux المُستخدم لإنهاء العمليات بسبب نفاد الذاكرة (OOM) قد أنهى العملية بالفعل.

نفّذ هذه الأوامر عبر SSH. استبدل onlyoffice-document-serverباسم الحاوية الموضح بواسطة docker ps -a:

free -h
docker ps -a
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' onlyoffice-document-server

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

إذا توقف الحاوية، docker statsفلن تتمكن من عرض ذروتها السابقة. بدلاً من ذلك، تحقق من سجل النواة ورسائل التطبيق الأخيرة.

sudo journalctl -k --since "-2 hours" | grep -Ei 'out of memory|killed process|oom'
docker logs --tail 100 onlyoffice-document-server

تُساعد رسائل النواة التي تُشير إلى "نفاد الذاكرة" أو "إنهاء العملية" في تحديد العملية المعنية. OOMKilled=trueيُعدّ هذا دليلاً قوياً على حدوث نفاد ذاكرة في الحاوية، ولكنه falseلا يستبعد قيام نواة النظام المضيف بإنهاء عملية فرعية بينما تبقى الحاوية قيد التشغيل. وبالمثل، يُشير رمز الخروج 137 فقط إلى إنهاء SIGKILL، وليس سببه. في حال عدم وجود دليل على نفاد الذاكرة، يُنصح بفحص السجلات وحالات فشل الاتصال قبل شراء المزيد من ذاكرة الوصول العشوائي (RAM).

2. امنح الخادم الافتراضي الخاص (VPS) ذاكرة وصول عشوائي (RAM) كافية قبل ضبط أي شيء آخر.

اعتبارًا من أكتوبر 2026، يُشير ملف README الرسمي لخادم مستندات Docker الخاص بـ ONLYOFFICE إلى ضرورة توفر 4 جيجابايت أو أكثر من ذاكرة الوصول العشوائي (RAM) و2 جيجابايت على الأقل من مساحة التبديل (swap) ضمن متطلباته الموصى بها. وتُحدد وثائق التثبيت الرسمية المنفصلة، ​​التي تُتيح التثبيت بنقرة واحدة، 4 جيجابايت من ذاكرة الوصول العشوائي لبيئات اختبار Docker، وتوصي بـ 8 جيجابايت أو أكثر لبيئات الإنتاج، وتُحدد 4 جيجابايت على الأقل من مساحة التبديل ضمن متطلبات التثبيت. تُوضح هذه الوثائق سياقات نشر مختلفة، لذا لا يُمكن اعتبار 4 جيجابايت ضمانًا لأداء موثوق في بيئة الإنتاج.

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

على خادم مزدحم، استخدم هذه الطريقة ps aux --sort=-rss | headلتحديد العمليات التي تستهلك ذاكرة كبيرة، وكررها docker statsخلال جلسة تحرير نموذجية. احتفظ بمساحة كافية لبقية الجهاز بدلاً من تخصيص كل ذاكرة الوصول العشوائي المتاحة لبرنامج ONLYOFFICE. إذا تجاوز الطلب المستمر سعة الخادم، انقل الخدمات المنافسة أو قم بترقية الخادم الافتراضي الخاص؛ لا يمكن لتعديل على مستوى التطبيق أن يُسبب نقصًا في الذاكرة الفعلية.

تحقق من وجود حد أقصى غير مقصود لذاكرة Docker

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

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

3. أضف مخزن تبديل مؤقت إذا لم يكن لدى الخادم الافتراضي الخاص أي مخزن تبديل مؤقت.

يمكن لملف التبديل استيعاب زيادة مؤقتة في استهلاك الذاكرة، ولكنه يُخزّن على القرص وهو أبطأ بكثير من ذاكرة الوصول العشوائي (RAM). تحقق swapon --showمن ذلك df -h /أولاً. يضيف المثال التالي ملف تبديل بحجم 2 جيجابايت إلى خادم افتراضي خاص (VPS) باستخدام نظام ملفات محلي متوافق مثل ext4، في حال /swapfileعدم وجود ملف تبديل مسبقًا وسماح مزود الخدمة باستخدامه.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h

اجعل ملف التبديل الجديد دائمًا بعد swaponنجاح العملية. تحقق من وجود إدخال سابق باستخدام الأمر grep -F '/swapfile' /etc/fstab`fm`؛ إذا لم يكن موجودًا، فأضفه مرة واحدة فقط.

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

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

4. أعد فحص الخادم تحت عبء تحرير واقعي

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

عندما تصبح الخدمة جاهزة، تحقق من تشغيل الحاوية وافحص ذاكرتها مرة أخرى:

docker ps --filter name=onlyoffice-document-server
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}}' onlyoffice-document-server
docker exec onlyoffice-document-server curl -fsS http://localhost:8000/info/info.json

يستخدم الفحص الأخير نقطة النهاية الداخلية للمعلومات الموضحة في فحص السلامة الرسمي لـ ONLYOFFICE Docker Compose ؛ قم بتشغيله داخل الحاوية لأن المنفذ 8000 قد لا يكون متاحًا على الخادم الافتراضي الخاص. تشير استجابة نقطة النهاية إلى توفر الخدمة، وليس بالضرورة إلى أن جميع عمليات تكامل التخزين أو عمليات حفظ البيانات تعمل بشكل صحيح.

تأكد من حل مشكلة الذاكرة

أعد فتح مستند صغير، ثم مستند كبير واحد يمثله، من خلال حسابك الفعلي على Nextcloud أو ownCloud أو أي منصة تكامل أخرى. احفظ تعديلًا بسيطًا وتأكد من ظهوره بعد إعادة فتح الملف. راقب free -hسجلات docker statsنفاد الذاكرة (OOM) الخاصة بـ kernel خلال فترة الاستخدام التي تسببت في حدوث الأعطال سابقًا.

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