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

# Апаратні вимоги

## Апаратні вимоги

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

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

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

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

{% 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 недостатньо під час підключення до 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 має бути більшим, ніж у попереднього проксі. Напр., якщо на 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://ayakaleaf-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.