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

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

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

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

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

### Минимальная установка

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

{% 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) в своем self-managed предложении.
{% 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.


---

# 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/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.