> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/ar/albda/requirements/hardware-requirements.md).

# متطلبات الأجهزة

## متطلبات الأجهزة

عند توفير الأجهزة لتشغيل Overleaf، فإن العامل الرئيسي الذي يجب أخذه في الاعتبار هو عدد المستخدمين المتزامنين الذين سيجرون عمليات التجميع.

على سبيل المثال، إذا كانت لديك رخصة لـ 100 مستخدم إجمالي، لكنك تتوقع أن يعمل حوالي 5 فقط في الوقت نفسه، فسيكون التثبيت الأدنى كافيًا. وإذا كنت تتوقع أن تكون نسبة أكبر تعمل (وتجري التجميع) في الوقت نفسه، فيجب أن تفكر في توفير خادم بمواصفات أعلى.

### التثبيت الأدنى

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

{% hint style="danger" %}
إذا كنت تفكر في استخدام نظام ملفات قائم على NFS (Network File System) لنسختك الصغيرة، فيرجى إلقاء نظرة على هذا القسم في [استكشاف الأخطاء وإصلاحها](/on-premises/ar/aldam/troubleshooting.md) القسم.
{% endhint %}

### التوسّع

كقاعدة عامة، لتوفير مستوى عالٍ وثابت من الخدمة، ينبغي إضافة نواة CPU واحدة و1 جيجابايت من الذاكرة إلى التثبيت الأدنى لكل 5-10 مستخدمين متزامنين.

ينبغي أن يُؤخذ هذا على أنه مجرد إرشاد، إذ إن عوامل مثل حجم المستندات المعتادة (فالمستندات الأكبر تستهلك موارد تجميع أكثر)، ومدى تكرار قيام المستخدمين بالتجميع، ومدى التحمّل لأوقات تجميع أطول أثناء الاستخدام المكثف، كلها تؤثر في مستوى الموارد المطلوب توفيرها.

يسعى كثير من عملائنا إلى نشر Server Pro على مستوى المؤسسة، أو عبر فرق كبيرة. في تلك الحالات، يصعب علينا تقديم نصيحة بشأن متطلبات إعداد محددة، لأن حالات الاستخدام والأجهزة المتاحة الأساسية قد تختلف كثيرًا.

| المثال 1                                                                                                                                                                                                                                                                                                     | المثال 2                                                                                                                                                                                                                                           |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| إذا كنت تدير تثبيتًا لـ Server Pro لعدد إجمالي قدره 300 مستخدم، وتتوقع بانتظام أن يقوم 30-60 من هؤلاء المستخدمين بتجميع المستندات في الوقت نفسه، فإن 8 جيجابايت و7 أنوية (5 أنوية + 5 جيجابايت + الأساس البالغ نواتين و3 جيجابايت) ينبغي أن توفر موارد كافية ليحصل المستخدمون على مستوى خدمة عالٍ بشكل متسق. | ولتقديم مثال على متطلبات الأجهزة للنشر الأكبر، تم إعداد تثبيت Server Pro لـ 1,000 مستخدم إجمالي بنجاح باستخدام خادم واحد مزوّد بمعالجين رباعيي النوى و32 جيجابايت من ذاكرة النظام. وقد كان ذلك كافيًا لاحتياجات الفريق خلال سنة الاستخدام الماضية. |

يمكن للعملاء الذين يتجاوزون حدود خادم كبير واحد أن يلقوا نظرة على [التوسّع الأفقي](/on-premises/ar/alsyanh/horizontal-scaling.md) لـ Server Pro.

### التخزين

ننصح بعدم استخدام Network File System (NFS)/Amazon EFS/Amazon EBS لتخزين المشاريع/السجل في الإعدادات الأكبر، ونؤكد صراحةً **أننا لا ندعمه** للتوسّع الأفقي.

إن سلوك أنظمة الملفات هذه لا يوفر الأداء والموثوقية اللازمين اللذين يحتاجهما Server Pro عند التشغيل على نطاق واسع. وعندما يعجز نظام الملفات عن مجاراة الحمل، يتوقف التطبيق بسبب كثرة عمليات الإدخال/الإخراج الحاجزة. وقد تؤدي هذه التوقفات إلى تجاوز الأقفال المعتمدة على Redis، مما قد يؤدي بدوره إلى تلف بيانات المشروع.

ننصح باستخدام [تخزين كائنات متوافق مع S3](/on-premises/ar/albda/what-is-the-overleaf-toolkit.md) بدلاً من ذلك. إن بطء أداء S3 يؤثر فقط في رفع/تنزيل الملفات، مما يؤدي فقط إلى زيادة عدد الاتصالات المفتوحة مع مزود S3 لديك، وبالتالي لا يؤثر في سلوك بقية التطبيق. بالإضافة إلى ذلك، يمكن لـ Server Pro تحديد مهلات معقولة لطلبات S3، وهو أمر غير ممكن لعمليات نظام الملفات/الإدخال والإخراج على مستوى التطبيق.

{% hint style="info" %}
وللإشارة، يتبع GitLab موقفًا مشابهًا يتمثل في [عدم دعم NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) في عرضه المُدار ذاتيًا.
{% endhint %}

### إعدادات خاصة بـ Nginx للنشرات الكبيرة

بشكل افتراضي، تحدّ نسخة Overleaf Server عدد الاتصالات إلى 768. ويشمل ذلك اتصالات Websocket المستمرة، وتصفح HTML على المستوى الأعلى، وطلبات ajax. بمجرد الوصول إلى الحد، قد لا يتمكن المحرر من الاتصال، وقد لا يتم تحميل صفحة المحرر بالكامل، وقد تفشل طلبات التجميع. سيعيد Nginx استجابات بحالة 500 ويسجل `worker_connections are not enough while connecting to upstream` في `var/log/nginx/error`.log داخل `sharelatex` الحاوية.

إن [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) يحدّ الإعداد من عدد الاتصالات المتزامنة التي سيقبلها nginx لكل عامل. ويتم التحكم في عدد العمال بواسطة [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) ويُضبط على 4 افتراضيًا في إعدادات nginx لدينا.

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

تعرض نسخ Overleaf Server متغيرات بيئية لضبط إعدادات nginx هذه:

* `NGINX_WORKER_PROCESSES` لـ [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (الافتراضي `4`)
* `NGINX_WORKER_CONNECTIONS` لـ [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (الافتراضي `768`)
* `NGINX_KEEPALIVE_TIMEOUT` لـ [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (الافتراضي `65`)

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>عند تشغيل وكيل آخر أمام <code>sharelatex</code> الحاوية (مثلًا لإنهاء TLS)، فإن <code>NGINX_KEEPALIVE_TIMEOUT</code> في نسخة Overleaf Server يجب أن تكون أكبر من الوكيل السابق. على سبيل المثال، مع عملية nginx أخرى على مضيف Docker <strong>nginx-host</strong>، فيما يلي مثالان:</p></div>
* القيمة الافتراضية `NGINX_KEEPALIVE_TIMEOUT`، استخدم [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (القيمة الافتراضية في upstream) في **nginx-host**
* قيمة مخصصة `NGINX_KEEPALIVE_TIMEOUT=100s`، استخدم [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (قيمة مخصصة في upstream) في **nginx-host**

### سرعة وحدة المعالجة المركزية

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/on-premises/ar/albda/requirements/hardware-requirements.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.