> ## 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) для небольшого экземпляра, ознакомьтесь с соответствующим пунктом в разделе [Устранение неполадок](/ru/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 ГБ оперативной памяти. Этого было достаточно для нужд команды на протяжении последнего года использования. | Клиенты, которым не хватает возможностей одного большого сервера, могут ознакомиться с разделом [Горизонтальное масштабирование](/ru/on-premises/maintenance/horizontal-scaling) для Server Pro. ### Хранилище Мы не рекомендуем использовать Network File System (NFS)/Amazon EFS/Amazon EBS для хранения проектов и истории в крупных установках и явно **не поддерживаем это** при горизонтальном масштабировании. Эти файловые системы не обеспечивают необходимой производительности и надёжности, которые требуются Server Pro при работе в большом масштабе. Когда файловая система не справляется с нагрузкой, приложение зависает из-за слишком большого количества блокирующих операций ввода-вывода. Такие зависания могут приводить к истечению блокировок на основе Redis, что, в свою очередь, может повредить данные проектов. Вместо этого мы рекомендуем использовать [S3-совместимое объектное хранилище](/ru/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) в своём самостоятельно управляемом предложении. ### Настройка 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.