> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/ar/albda/requirements/hardware-requirements.md).

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

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

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

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

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

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

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

### التوسّع

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

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

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

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

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

### التخزين

ننصح بعدم استخدام نظام الملفات الشبكي (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) (القيمة الافتراضية في المصدر) في **nginx-host**
* قيمة مخصّصة `NGINX_KEEPALIVE_TIMEOUT=100s`، استخدم [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (القيمة المخصّصة في المصدر) في **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://ayakaleaf-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.