حل مشكلة تأخر التحرير المشترك في ONLYOFFICE على خادم Docker مُستضاف ذاتيًا

إذا شعرتَ ببطء في التحرير التعاوني باستخدام ONLYOFFICE على خادم Docker مُستضاف ذاتيًا، فلا تبدأ بتغيير إعدادات المُحرر غير الموثقة. قسّم المشكلة أولًا إلى ثلاثة جوانب قابلة للقياس: ضغط موارد الخادم، وسلوك الخادم الوكيل العكسي/WebSocket، وأخطاء على مستوى التخزين أو الحاوية. يعتمد التحرير التعاوني على اتصال طويل الأمد وفي الوقت الفعلي، لذا قد يبدو الخادم الذي يفتح المستندات بنجاح بطيئًا عند قيام عدة أشخاص بالكتابة في وقت واحد.

يستخدم هذا الدليل مثالًا افتراضيًا : فريق صغير يُشغّل برنامج ONLYOFFICE Docs في بيئة Docker خلف خادم NGINX. يستطيع مستخدم أو اثنان التحرير بشكل طبيعي، ولكن عند فتح ستة أشخاص للمستند نفسه، تتأخر تحديثات المؤشر وتظهر تغييرات المستخدمين الآخرين بعد فترة توقف ملحوظة. هذا المثال هو مجرد سيناريو تعليمي، وليس معيارًا أو تقريرًا عن تطبيق حقيقي.

اعتبارًا من أكتوبر 2026، يُعد ONLYOFFICE Docs 9.4 الإصدار الحالي المُدرج في سجل التغييرات الرسمي. كما غيّر الإصدار 9.4 بنية الإصدار المجاني بإزالة الاعتماد على RabbitMQ وقواعد البيانات، لذا قد لا تتوافق النصائح المكتوبة للإصدارات القديمة مع حاوية الإصدار المجاني الحالية. تأكد دائمًا من الإصدار المُثبّت لديك قبل نسخ نصائح الضبط من منشور قديم في المنتدى.

1. قم بقياس التأخير قبل إجراء أي تغيير.

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

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

يُوضح دليل تثبيت Docker الرسمي متطلبات نشر Docker الأساسية لـ ONLYOFFICE . أما بالنسبة لـ Docker Compose، فيُرجى اتباع تعليمات Docker Compose الرسمية .

2. تحقق من ضغط وحدة المعالجة المركزية والذاكرة أثناء قيام المستخدمين بالتحرير

على مضيف Docker، قم بتشغيل ما يلي:

docker stats

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

free -h
uptime
vmstat 1
df -h

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

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

المرجع الرسمي لإرشادات السعة المنشورة هو متطلبات نظام Docker في وثائق ONLYOFFICE .

3. تحقق من مساحة القرص، ومواقع التثبيت، وذاكرة التخزين المؤقت للملفات

تُحدد وثائق Docker الخاصة بـ ONLYOFFICE مواقع التخزين الدائمة، بما في ذلك /var/log/onlyofficeمواقع سجلات /var/lib/onlyofficeالنظام وذاكرة التخزين المؤقت للملفات. تحقق من نظام الملفات الذي يدعم هذه المسارات، وليس فقط نظام الملفات الجذر الخاص بالجهاز المضيف.

df -h
docker inspect documentserver --format '{json .Mounts}'

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

يوصي المشروع أيضًا بتخزين البيانات ذات الصلة خارج الحاوية عند الحاجة إلى سجلات دائمة، أو تخزين مؤقت، أو خدمات قواعد بيانات خارجية/Redis/RabbitMQ. راجع إرشادات Docker الرسمية لوحدات التخزين .

4. تحقق من أن الخادم الوكيل العكسي يحافظ على الاتصال في الوقت الفعلي

تستخدم العديد من عمليات النشر ذاتية الاستضافة ONLYOFFICE خلف خوادم وسيطة مثل NGINX أو Apache أو HAProxy أو Traefik. وتشترط وثائق ONLYOFFICE الرسمية للخوادم الوسيطة صراحةً توجيه رؤوس مثل `<header>` X-Forwarded-Protoو`<header>` X-Forwarded-Host. كما يستخدم التكوين المُرفق مع ONLYOFFICE بروتوكول HTTP/1.1 ومعالجة ترقية WebSocket.

بالنسبة لـ NGINX، قارن إعداداتك مع المثال الرسمي لـ ONLYOFFICE بدلاً من لصق جزء عام من كود WebSocket من منتج آخر. يتضمن النمط النموذجي ما يلي:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

تُعدّ التوجيهات المحيطة mapومواقع الوكيل مهمة. استخدم مثال المورّد الكامل لشبكتك. تجد التكوينات المدعومة منشورة في وثائق استخدام ONLYOFFICE خلف الوكيل .

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

5. تأكد من جلسة WebSocket في المتصفح

افتح أدوات مطوري المتصفح، واختر لوحة الشبكة، ثم قم بتصفية حركة مرور WebSocket، وأعد تحميل المحرر. عادةً ما تُظهر عملية مصافحة WebSocket الناجحة بروتوكول HTTP 101 Switching Protocolsواتصالًا يبقى مفتوحًا. لا تعتبر حالة "الانتظار" الطويلة في WebSocket فشلًا بحد ذاتها؛ فمن المتوقع أن يبقى اتصال WebSocket النشط مفتوحًا.

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

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

6. تحقق من الحاويات المتوقعة والبنية الخاصة بكل إصدار

يجري:

docker compose ps
# or
docker ps

لا تفترض أن جميع عمليات نشر ONLYOFFICE الحديثة يجب أن تتضمن نفس مجموعة حاويات Redis أو PostgreSQL أو RabbitMQ. هنا تكمن أهمية الإصدار. تشير ONLYOFFICE إلى أنه بدءًا من Docs 9.4، تم تبسيط إصدار Community مفتوح المصدر إلى بنية أحادية العملية، وإزالة الاعتماد على RabbitMQ وقواعد البيانات. قد تختلف إصدارات Enterprise وDeveloper وإصدارات Community القديمة، بالإضافة إلى حزم Compose المخصصة.

هذا يعني أن مقالة استكشاف الأخطاء وإصلاحها لعام 2023 التي تقول "ربما يكون RabbitMQ هو عنق الزجاجة" قد لا تكون ذات صلة بنسخة Community Edition الحالية. حدد الصورة والإصدار اللذين تستخدمهما فعليًا:

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

تُشير قائمة التغييرات الرسمية لبرنامج ONLYOFFICE Docs إلى الإصدار 9.4.0 مع تاريخ إصدار مُحدد في 20 مايو 2026. ويُوضح إعلان إصدار Docs 9.4 من الشركة المُصنّعة التغييرات في بنية الإصدار المُشترك.

7. قم بتفعيل تسجيل التصحيح مؤقتًا واربطه بالتأخير

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

DS_LOG_LEVEL=DEBUG

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

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

تشير الوثائق الرسمية إلى أن سجلات Docker متاحة أيضًا داخل /var/log/onlyoffice/documentserverالحاوية، وفي دليل السجلات المُثبَّت على المضيف في حال تثبيته. يُفيد سجل المُحوِّل عند بطء فتح الملفات أو تحويلها، بينما ينبغي ربط مشكلات التأليف المشترك بسجلات خادم المستندات وملاحظات المتصفح/الشبكة.

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

8. قم بالتحديث بعناية إذا كنت تستخدم صورة قديمة

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

سجّل أولاً علامة الصورة الحالية، وملف الإنشاء، وإعدادات JWT، ووحدات التخزين المُثبّتة، ​​وتكوين الخادم الوكيل العكسي، وتكوين التكامل. استخدم نسخة مُثبّتة عندما تتطلب عملية التغيير إمكانية إعادة إنتاجها. يشرح دليل تثبيت Docker الخاص بـ ONLYOFFICE كيفية تحديد إصدار مُعيّن، ويُبيّن سجل التغييرات الرسمي التغييرات التي طرأت.

قبل إيقاف خادم مستندات الإنتاج المُستخدم بشكل مُتعمّد، اتبع إرشادات إيقاف التشغيل الخاصة بـ ONLYOFFICE لإصدارك ونشرك لضمان التعامل الآمن مع جلسات التحرير النشطة. لا تستخدم مستندًا مرجعيًا يحتوي على عمل مستخدم غير محفوظ كاختبار للترقية.

كيف تُضيّق الحالة الافتراضية نطاق الحل الحقيقي

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

أساس عملي لعمليات نشر Docker

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

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

ما لا يجب فعله

• لا تقم بتغيير القيم غير الموثقة local.jsonلمجرد أن منشورًا في المنتدى يسميها "تحسينات الأداء".
• لا تفترض أن اتصال WebSocket المستمر الذي يظهر على أنه "معلق" معطل؛ فمن المتوقع وجود اتصالات WebSocket طويلة الأمد.
• لا تُضف Redis أو RabbitMQ أو PostgreSQL لمجرد أن مخطط نشر قديم استخدمها. تحقق أولاً من بنية إصدارك ونسختك.
• لا تقم بتعطيل التحقق من TLS أو أمان JWT أو حماية الوكيل كاختصار لتقليل زمن الاستجابة.
• لا تقارن مقياس الخادم الخامل بالفترة التي يبلغ فيها المستخدمون فعليًا عن التأخير.
• لا تقم بترقية نسخة الإنتاج دون الحفاظ على وحدات التخزين والتكوين ومسار التراجع.

خلاصة القول

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

للحصول على تفاصيل النشر الحالية، استخدم وثائق تثبيت ONLYOFFICE Docker ، وأمثلة الوكيل العكسي الرسمية ، ودليل تسجيل التصحيح ، وسجل تغييرات الوثائق الرسمي .