> 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/ru/nachalo-raboty/requirements/hardware-requirements.md).

# Требования к оборудованию

## Требования к оборудованию

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

Например, если у вас лицензия на 100 пользователей всего, но вы ожидаете, что одновременно будут работать лишь \~5, минимальной установки будет достаточно. Если вы ожидаете, что более высокая доля пользователей будет работать (и компилировать) одновременно, следует рассмотреть сервер с более высокой спецификацией.

### Минимальная конфигурация

Минимальное базовое требование — 2 ядра и 3 ГБ памяти — необходимо для базовых операций примерно с 5 одновременными пользователями. Этого минимального требования также будет достаточно для больших групп, где одновременная нагрузка ниже, или где допустимо, чтобы время компиляции было дольше при более высокой нагрузке.

{% hint style="danger" %}
Если вы рассматриваете использование файловой системы на основе NFS (Network File System) для вашего небольшого экземпляра, пожалуйста, взгляните на этот раздел в [Устранение неполадок](/on-premises/ru/podderzhka/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/ru/obsluzhivanie/horizontal-scaling.md) для Server Pro.

### Хранилище

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

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

Мы рекомендуем использовать [объектное хранилище, совместимое с S3](/on-premises/ru/nachalo-raboty/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. Число 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/ru/nachalo-raboty/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.