> ## Documentation Index > Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Вимоги до обладнання ## Вимоги до обладнання Під час підготовки обладнання для роботи Overleaf головним чинником є кількість користувачів, які одночасно запускатимуть компіляцію. Наприклад, якщо у вас ліцензія на 100 користувачів загалом, але ви очікуєте, що одночасно працюватимуть лише \~5, мінімальної інсталяції буде достатньо. Якщо ви очікуєте, що одночасно працюватиме (і компілюватиме) більша частка користувачів, варто розглянути сервер із потужнішою конфігурацією. ### Мінімальна інсталяція Для базової роботи приблизно з 5 одночасними користувачами потрібно щонайменше 2 ядра та 3 ГБ пам'яті. Цієї мінімальної конфігурації також вистачить для більших груп із меншим одночасним використанням або там, де під час пікового навантаження допустимий довший час компіляції. Якщо ви плануєте використовувати файлову систему на основі NFS (Network File System) для свого невеликого екземпляра, ознайомтеся з відповідним розділом у [Troubleshooting](/uk/on-premises/support/troubleshooting). ### Масштабування Як загальне правило, щоб забезпечити високий і стабільний рівень обслуговування, до мінімальної інсталяції слід додавати 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 ГБ системної пам'яті. Цього було достатньо для потреб команди протягом останнього року використання. | Клієнти, яким уже не вистачає можливостей одного великого сервера, можуть ознайомитися з [Horizontal scaling](/uk/on-premises/maintenance/horizontal-scaling) для Server Pro. ### Сховище Ми не радимо використовувати Network File System (NFS)/Amazon EFS/Amazon EBS для зберігання проєктів та історії у великих інсталяціях і явно **не підтримуємо цього** для горизонтального масштабування. Ці файлові системи не забезпечують необхідної продуктивності та надійності, яких потребує Server Pro під час роботи у великому масштабі. Коли файлова система не встигає за навантаженням, застосунок зависає через надмірну кількість блокувальних операцій вводу-виводу. Такі зависання можуть призвести до перевищення часу дії блокувань на основі Redis, що, своєю чергою, може пошкодити дані проєктів. Натомість радимо використовувати [S3-сумісне об'єктне сховище](/uk/on-premises/getting-started/what-is-the-overleaf-toolkit). Низька продуктивність S3 впливає лише на завантаження та вивантаження файлів, що призводить лише до збільшення кількості відкритих з'єднань із вашим постачальником S3 і не впливає на поведінку решти застосунку. Крім того, Server Pro може задавати розумні тайм-аути для запитів до S3, що неможливо для операцій файлової системи/вводу-виводу на рівні застосунку. Для довідки: GitLab дотримується схожої позиції щодо [непідтримки NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) у своїй self-managed пропозиції. ### Специфічна конфігурація 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) і в нашій конфігурації 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`) Якщо перед контейнером `sharelatex` працює інший проксі (наприклад, для термінації TLS), значення `NGINX_KEEPALIVE_TIMEOUT` в екземплярі Overleaf Server має бути більшим, ніж у попереднього проксі. Наприклад, з іншим процесом nginx на хості Docker nginx-host, ось два приклади: * Значення `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.