> 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/on-premises-cs/zaciname/requirements/hardware-requirements.md).

# Požadavky na hardware

## Hardwarové požadavky

Při zajišťování hardwaru pro provoz Overleafu je hlavním faktorem, který je třeba zvážit, kolik souběžných uživatelů bude provádět kompilace.

Například pokud máte licenci pro celkem 100 uživatelů, ale očekáváte, že budou současně pracovat jen asi 5 z nich, postačí minimální instalace. Pokud očekáváte, že vyšší podíl uživatelů bude pracovat (a kompilovat) současně, měli byste zvážit zajištění serveru s vyšší specifikací.

### Minimální instalace

Pro základní provoz s přibližně 5 souběžnými uživateli je vyžadován minimální základní požadavek 2 jader a 3 GB paměti. Tento minimální požadavek bude dostačující i pro větší skupiny, kde je menší souběžné využití, nebo kde nevadí delší časy kompilace při vyšší zátěži.

{% hint style="danger" %}
Pokud uvažujete o použití souborového systému založeného na NFS (Network File System) pro vaši malou instanci, podívejte se prosím na tuto část v [Řešení problémů](/on-premises/on-premises-cs/podpora/troubleshooting.md) sekci.
{% endhint %}

### Škálování

Jako orientační pravidlo platí, že pro zajištění vysoké a konzistentní úrovně služby by mělo být k minimální instalaci přidáno 1 CPU jádro a 1 GB paměti na každých 5–10 souběžných uživatelů.

Toto by mělo sloužit pouze jako vodítko, protože na požadovanou úroveň zajištění mají vliv faktory, jako je velikost typických dokumentů (větší dokumenty spotřebují více kompilovaných prostředků), jak často uživatelé kompilují a jaká je tolerance pro delší časy kompilace při vysokém vytížení.

Mnoho našich zákazníků se snaží nasadit Server Pro v celé organizaci nebo napříč velkými týmy. V takových situacích je pro nás obtížné radit ohledně konkrétních požadavků na nastavení, protože případy použití i dostupný základní hardware se mohou značně lišit.

| Příklad 1                                                                                                                                                                                                                                                                                   | Příklad 2                                                                                                                                                                                                                                                                    |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pokud provozujete instalaci Server Pro pro celkem 300 uživatelů a pravidelně očekáváte, že 30–60 z nich bude současně kompilovat dokumenty, mělo by 8 GB a 7 jader (5 jader + 5 GB + základ 2 jader a 3 GB) poskytnout vašim uživatelům dostatečné zdroje pro trvale vysokou úroveň služby. | Pro představu o hardwarových požadavcích pro větší nasazení byla instalace Server Pro pro celkem 1 000 uživatelů úspěšně zprovozněna na jediném serveru vybaveném dvěma 4jádrovými procesory a 32 GB systémové paměti. To za poslední rok provozu dostačovalo potřebám týmu. |

Zákazníci, kteří překračují limity jednoho velkého serveru, se mohou podívat na [Horizontální škálování](/on-premises/on-premises-cs/udrzba/horizontal-scaling.md) pro Server Pro.

### Úložiště

Pro úložiště projektů/historie ve větších instalacích nedoporučujeme používat Network File System (NFS)/Amazon EFS/Amazon EBS a výslovně **jej nepodporujeme** pro horizontální škálování.

Chování těchto souborových systémů neposkytuje potřebný výkon a spolehlivost, které Server Pro při provozu ve velkém měřítku potřebuje. Když souborový systém nestíhá zátěž, aplikace se zasekává kvůli příliš mnoha blokujícím I/O operacím. Tato zasekávání mohou vést k překročení zámků založených na Redis, což může následně způsobit poškození projektových dat.

Doporučujeme používat [objektové úložiště kompatibilní se S3](/on-premises/on-premises-cs/zaciname/what-is-the-overleaf-toolkit.md) místo toho. Pomalý výkon S3 pak ovlivňuje pouze nahrávání/stahování souborů, což vede jen ke zvýšenému počtu otevřených spojení k vašemu poskytovateli S3 a nemá vliv na chování zbytku aplikace. Server Pro navíc může u požadavků na S3 nastavit rozumné časové limity, což na úrovni aplikace není možné pro operace se souborovým systémem/I/O.

{% hint style="info" %}
Pro srovnání, GitLab zaujímá podobný postoj k [nepodporování NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) ve své self-managed nabídce.
{% endhint %}

### Konfigurace specifická pro Nginx pro velká nasazení

Ve výchozím nastavení instance Overleaf Server omezují počet spojení na 768. To zahrnuje trvalá WebSocket spojení, navigaci na úrovni hlavního HTML i požadavky AJAX. Jakmile je limit dosažen, editor se nemusí být schopen připojit, stránka editoru se nemusí načíst celá a požadavky na kompilaci mohou selhat. Nginx vrátí odpovědi se stavem 500 a zapíše `worker_connections are not enough while connecting to upstream` do `var/log/nginx/error`.log uvnitř `sharelatex` kontejneru.

Skript [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) nastavení omezuje počet souběžných spojení, která nginx přijme na jednoho workeru. Počet workerů je řízen nastavením [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) a v naší konfiguraci nginx je ve výchozím nastavení nastaveno na 4.

Nginx ve srovnání s ostatními částmi systému neprovádí tolik práce, takže tato omezení slouží jako pojistka, která zabraňuje tomu, aby systém zahltil příliš velký počet spojení. Je lepší některá nadbytečná spojení odmítnout včas, než zpomalit každé spojení.

Instance Overleaf Server vystavují proměnné prostředí pro úpravu těchto nastavení nginx:

* `NGINX_WORKER_PROCESSES` pro [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (výchozí `4`)
* `NGINX_WORKER_CONNECTIONS` pro [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (výchozí `768`)
* `NGINX_KEEPALIVE_TIMEOUT` pro [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (výchozí `65`)

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Při spuštění dalšího proxy serveru před <code>sharelatex</code> kontejnerem (např. pro ukončení TLS), musí být <code>NGINX_KEEPALIVE_TIMEOUT</code> v instanci Overleaf Server větší než u předchozího proxy serveru. Např. s dalším procesem nginx na hostiteli Dockeru <strong>nginx-host</strong>, zde jsou dva příklady:</p></div>
* Výchozí hodnota `NGINX_KEEPALIVE_TIMEOUT`, použijte [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (výchozí hodnota v upstreamu) v **nginx-host**
* Vlastní hodnota `NGINX_KEEPALIVE_TIMEOUT=100s`, použijte [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (vlastní hodnota v upstreamu) v **nginx-host**

### Rychlost CPU

LaTeX je jednovláknový program, což znamená, že může využívat vždy jen jedno CPU jádro. CPU je také hlavním omezením při kompilaci dokumentu. Čím vyšší je tedy výkon vašeho CPU na jednom jádře, tím rychleji budete moci dokument kompilovat. Více jader pomůže pouze tehdy, pokud se snažíte kompilovat více dokumentů, než máte volných CPU jader.


---

# 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/on-premises-cs/zaciname/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.