> 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/uk/pochatok-roboti/requirements/hardware-requirements.md).

# Вимоги до апаратного забезпечення

## Вимоги до апаратного забезпечення

Під час підбору апаратного забезпечення для запуску Overleaf головний чинник, який слід врахувати, — це скільки одночасних користувачів виконуватимуть компіляції.

Наприклад, якщо у вас є ліцензія на 100 користувачів загалом, але ви очікуєте, що одночасно працюватимуть лише близько 5, мінімальної інсталяції буде достатньо. Якщо ви очікуєте, що більша частка користувачів працюватиме (і компілюватиме) одночасно, слід розглянути розгортання сервера з вищою специфікацією.

### Мінімальна інсталяція

Для базових операцій із приблизно 5 одночасними користувачами потрібен мінімум 2 ядра та 3 ГБ пам’яті. Ці мінімальні вимоги також будуть достатніми для більших груп, де одночасне використання менше, або де прийнятно, щоб час компіляції був довшим під час інтенсивнішого використання.

{% hint style="danger" %}
Якщо ви розглядаєте використання файлової системи на основі NFS (Network File System) для вашого невеликого інстансу, будь ласка, перегляньте цей розділ у [Усунення несправностей](/on-premises/uk/pidtrimka/troubleshooting.md) розділі.
{% endhint %}

### Масштабування

Як правило, щоб забезпечити високий і стабільний рівень обслуговування, до мінімальної інсталяції слід додавати 1 ядро 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/uk/obslugovuvannya/horizontal-scaling.md) для Server Pro.

### Сховище

Ми не радимо використовувати Network File System (NFS)/Amazon EFS/Amazon EBS для зберігання проєктів/історії у великих розгортаннях і явно **не підтримуємо це** для горизонтального масштабування.

Поведінка цих файлових систем не забезпечує необхідної продуктивності та надійності, які потрібні Server Pro під час роботи в дуже великому масштабі. Коли файлова система не встигає за навантаженням, застосунок зупиняється через надто велику кількість блокувальних операцій введення-виведення. Ці зупинки можуть призвести до прострочення блокувань на основі Redis, що, своєю чергою, може спричинити пошкодження даних проєкту.

Ми радимо використовувати [об’єктне сховище, сумісне з S3](/on-premises/uk/pochatok-roboti/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. Кількість workerів визначається параметром [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) і за замовчуванням у нашій конфігурації nginx встановлена на 4.

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**

### Швидкість CPU

LaTeX — це однопотокова програма, тобто вона може використовувати лише одне ядро CPU за раз. CPU також є головним обмеженням під час компіляції документа. Тому чим вища продуктивність вашого 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/uk/pochatok-roboti/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.