> ## 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. # Hardwarové požadavky ## Hardwarové požadavky Při zajišťování hardwaru pro provoz Overleafu je hlavním faktorem, kolik souběžných uživatelů bude spouštět kompilace. Pokud máte například licenci pro celkem 100 uživatelů, ale očekáváte, že současně jich bude pracovat jen \~5, postačí minimální instalace. Pokud očekáváte, že současně bude pracovat (a kompilovat) větší podíl uživatelů, měli byste zvážit server s vyššími parametry. ### Minimální instalace Pro základní provoz s přibližně 5 souběžnými uživateli jsou minimálním požadavkem 2 jádra a 3 GB paměti. Tento minimální požadavek bude stačit i pro větší skupiny s nižším souběžným využitím nebo tam, kde nevadí delší doby kompilace při vyšší zátěži. Pokud pro svou malou instanci zvažujete souborový systém založený na NFS (Network File System), podívejte se prosím na tuto pasáž v části [Řešení problémů](/cs/on-premises/support/troubleshooting). ### Škálování Jako orientační pravidlo platí, že pro zajištění vysoké a stálé úrovně služby je třeba k minimální instalaci přidat 1 jádro CPU a 1 GB paměti na každých 5–10 souběžných uživatelů. Berte to pouze jako vodítko, protože potřebnou úroveň prostředků ovlivňují faktory jako velikost typických dokumentů (větší dokumenty spotřebují více prostředků pro kompilaci), jak často uživatelé kompilují a jaká je tolerance k delším dobám kompilace při vysoké zátěži. Mnoho našich zákazníků chce nasadit Server Pro v celé organizaci nebo napříč velkými týmy. V takových situacích je pro nás obtížné doporučit konkrétní požadavky na nastavení, protože případy použití a dostupný 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, 8 GB a 7 jader (5 jader + 5 GB + základ 2 jádra a 3 GB) by mělo poskytnout dostatek prostředků, aby vaši uživatelé měli trvale vysokou úroveň služby. | Jako příklad hardwarových požadavků pro větší nasazení: instalace Server Pro pro celkem 1 000 uživatelů byla úspěšně provozována na jediném serveru se dvěma 4jádrovými procesory a 32 GB systémové paměti. To potřebám týmu stačilo po celý uplynulý rok používání. | Zákazníci, kteří překračují limity jednoho velkého serveru, se mohou podívat na [Horizontální škálování](/cs/on-premises/maintenance/horizontal-scaling) pro Server Pro. ### Úložiště U větších nasazení nedoporučujeme pro úložiště projektů a historie používat Network File System (NFS)/Amazon EFS/Amazon EBS a pro horizontální škálování je výslovně **nepodporujeme**. Chování těchto souborových systémů neposkytuje 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 IO operacím. Tato zaseknutí mohou vést k překročení zámků založených na Redisu, což může následně vést k poškození dat projektů. Místo toho doporučujeme používat [objektové úložiště kompatibilní s S3](/cs/on-premises/getting-started/what-is-the-overleaf-toolkit). Pomalý výkon S3 ovlivňuje pouze nahrávání a stahování souborů, což vede jen ke zvýšenému počtu otevřených spojení k vašemu poskytovateli S3 a neovlivňuje chování zbytku aplikace. Server Pro navíc může pro požadavky S3 nastavit rozumné časové limity, což u operací souborového systému/IO na úrovni aplikace není možné. Pro srovnání, GitLab zastává u své self-managed nabídky podobný postoj a [nepodporuje NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html). ### Konfigurace Nginx pro velká nasazení Ve výchozím nastavení instance Overleaf Server omezuje počet spojení na 768. To zahrnuje trvalá spojení Websocket, navigaci HTML nejvyšší úrovně i požadavky AJAX. Po dosažení limitu se editor nemusí být schopen připojit, stránka editoru se nemusí načíst celá a požadavky na kompilaci mohou selhat. Nginx bude vracet odpovědi se stavem 500 a do `var/log/nginx/error`.log uvnitř kontejneru `sharelatex` zapíše `worker_connections are not enough while connecting to upstream`. Nastavení [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) omezuje počet souběžných spojení, která nginx přijme na jeden worker. 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 stavu nastaven na 4. Nginx ve srovnání s ostatními částmi systému nevykonává mnoho práce, takže tyto limity slouží jako pojistka, která brání tomu, aby systém zahltilo příliš mnoho spojení. Je lepší zahodit některá nadbytečná spojení včas, než zpomalit všechna spojení. Instance Overleaf Server zpřístupňují 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`) Pokud před kontejnerem `sharelatex` běží další proxy (např. pro ukončení TLS), musí být `NGINX_KEEPALIVE_TIMEOUT` v instanci Overleaf Server větší než u předřazené proxy. Například s dalším procesem nginx na hostiteli Dockeru nginx-host uvádíme dva příklady: * 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 v jednu chvíli využívat pouze jedno jádro CPU. CPU je také hlavním omezením při kompilaci dokumentu. Čím rychlejší je jednojádrový výkon vašeho CPU, tím rychleji budete moci dokument zkompilovat. Více jader pomůže pouze tehdy, pokud se snažíte kompilovat více dokumentů, než máte volných jader CPU. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.