> 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/pl/pierwsze-kroki/requirements/hardware-requirements.md). # Wymagania sprzętowe ## Wymagania sprzętowe Przy zapewnianiu sprzętu do uruchomienia Overleaf najważniejszym czynnikiem, który należy wziąć pod uwagę, jest liczba jednoczesnych użytkowników wykonujących kompilacje. Na przykład, jeśli masz licencję na 100 użytkowników łącznie, ale spodziewasz się, że jednocześnie będzie pracować tylko około 5 z nich, minimalna instalacja będzie wystarczająca. Jeśli oczekujesz, że większy odsetek użytkowników będzie pracował (i kompilował) równocześnie, powinieneś rozważyć zapewnienie serwera o wyższej specyfikacji. ### Minimalna instalacja Do podstawowych operacji z około 5 jednoczesnymi użytkownikami wymagane jest minimum 2 rdzeni i 3 GB pamięci. To minimalne wymaganie będzie również wystarczające dla większych grup, w których jednoczesne użycie jest mniejsze, lub tam, gdzie akceptowalne są dłuższe czasy kompilacji podczas większego obciążenia. {% hint style="danger" %} Jeśli rozważasz użycie systemu plików opartego na NFS (Network File System) dla swojej niewielkiej instancji, zapoznaj się z tą sekcją w [Rozwiązywanie problemów](/on-premises/pl/wsparcie/troubleshooting.md) sekcji. {% endhint %} ### Skalowanie Przyjmuje się orientacyjnie, że aby zapewnić wysoki i spójny poziom usług, do minimalnej instalacji należy dodać 1 rdzeń CPU i 1 GB pamięci na każde 5–10 jednoczesnych użytkowników. Należy traktować to wyłącznie jako wskazówkę, ponieważ na wymagany poziom zapewnienia zasobów wpływają takie czynniki jak rozmiar typowych dokumentów (większe dokumenty zużywają więcej zasobów kompilacji), częstotliwość kompilowania przez użytkowników oraz tolerancja na dłuższe czasy kompilacji podczas dużego obciążenia. Wielu naszych klientów wdraża Server Pro w całej organizacji lub w dużych zespołach. W takich sytuacjach trudno jest nam doradzać konkretne wymagania dotyczące konfiguracji, ponieważ przypadki użycia i dostępny sprzęt bazowy mogą się znacznie różnić. | Przykład 1 | Przykład 2 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Jeśli uruchamiasz instalację Server Pro dla 300 użytkowników łącznie i regularnie spodziewasz się, że 30–60 z nich będzie jednocześnie kompilować dokumenty, 8 GB i 7 rdzeni (5 rdzeni + 5 GB + baza 2 rdzenie i 3 GB) powinny zapewnić wystarczające zasoby, aby użytkownicy mieli konsekwentnie wysoki poziom usług. | Dla przykładu wymagań sprzętowych dla większego wdrożenia: instalację Server Pro dla 1000 użytkowników łącznie udało się pomyślnie uruchomić na jednym serwerze wyposażonym w dwa 4-rdzeniowe procesory i 32 GB pamięci systemowej. To wystarczyło do potrzeb zespołu przez ostatni rok użytkowania. | Klienci, którzy przekraczają możliwości jednego dużego serwera, mogą zapoznać się z [Skalowaniem poziomym](/on-premises/pl/utrzymanie/horizontal-scaling.md) dla Server Pro. ### Przechowywanie Odradzamy używanie Network File System (NFS)/Amazon EFS/Amazon EBS do przechowywania projektów/historii w większych konfiguracjach i wyraźnie **nie wspieramy tego** w skalowaniu poziomym. Zachowanie tych systemów plików nie zapewnia wydajności i niezawodności, których Server Pro potrzebuje przy pracy na dużą skalę. Gdy system plików nie nadąża za obciążeniem, aplikacja zatrzymuje się z powodu zbyt wielu blokujących operacji I/O. Takie zatrzymania mogą prowadzić do przekroczenia limitu blokad opartych na Redisie, co z kolei może skutkować uszkodzeniem danych projektu. Zalecamy użycie [obiektowej pamięci masowej zgodnej z S3](/on-premises/pl/pierwsze-kroki/what-is-the-overleaf-toolkit.md) zamiast tego. Powolna wydajność S3 wpływa jedynie na przesyłanie i pobieranie plików, co skutkuje jedynie zwiększoną liczbą otwartych połączeń do dostawcy S3 i z kolei nie wpływa na zachowanie pozostałej części aplikacji. Dodatkowo Server Pro może określić rozsądne limity czasu dla żądań S3, co nie jest możliwe w przypadku operacji na systemie plików/I/O na poziomie aplikacji. {% hint style="info" %} Dla porównania GitLab zajmuje podobne stanowisko, [nie wspierając NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) w swojej ofercie samodzielnie zarządzanej. {% endhint %} ### Konfiguracja specyficzna dla Nginx dla dużych wdrożeń Domyślnie instancja Overleaf Server ogranicza liczbę połączeń do 768. Obejmuje to trwałe połączenia WebSocket, nawigację HTML najwyższego poziomu oraz żądania ajax. Po osiągnięciu limitu edytor może nie być w stanie się połączyć, strona edytora może nie załadować się w całości, a żądania kompilacji mogą się nie powieść. Nginx zwróci odpowiedzi ze statusem 500 i zapisze `worker_connections are not enough while connecting to upstream` do `var/log/nginx/error`.log wewnątrz kontenera `sharelatex` . Ustawienie [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) ogranicza liczbę jednoczesnych połączeń, które nginx będzie akceptował na jednego workera. Liczba workerów jest kontrolowana przez ustawienie [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) i domyślnie wynosi 4 w naszej konfiguracji nginx. Nginx nie wykonuje dużo pracy w porównaniu z innymi częściami systemu, więc te limity działają jako zabezpieczenie, zapobiegające przeciążeniu systemu przez zbyt wiele połączeń. Lepiej wcześniej odrzucić nadmiarowe połączenia, niż spowalniać każde połączenie. Instancje Overleaf Server udostępniają zmienne środowiskowe do dostosowywania tych ustawień nginx: * `NGINX_WORKER_PROCESSES` dla [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (domyślnie `4`) * `NGINX_WORKER_CONNECTIONS` dla [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (domyślnie `768`) * `NGINX_KEEPALIVE_TIMEOUT` dla [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (domyślnie `65`)

Podczas uruchamiania kolejnego proxy przed sharelatex kontenerem (np. w celu zakończenia TLS), NGINX_KEEPALIVE_TIMEOUT w instancji Overleaf Server musi być większy niż w poprzednim proxy. Np. przy innym procesie nginx na hoście Docker nginx-host, oto dwa przykłady:

* Wartość domyślna `NGINX_KEEPALIVE_TIMEOUT`, użyj [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (wartość domyślna w upstream) w **nginx-host** * Wartość niestandardowa `NGINX_KEEPALIVE_TIMEOUT=100s`, użyj [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (wartość niestandardowa w upstream) w **nginx-host** ### Prędkość CPU LaTeX jest programem jednowątkowym, co oznacza, że może wykorzystywać tylko jeden rdzeń CPU naraz. CPU jest też głównym ograniczeniem podczas kompilowania dokumentu. Dlatego im szybsza jest wydajność jednego rdzenia twojego CPU, tym szybciej będziesz mógł kompilować dokument. Więcej rdzeni pomoże tylko wtedy, gdy próbujesz kompilować więcej dokumentów, niż masz wolnych rdzeni 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/pl/pierwsze-kroki/requirements/hardware-requirements.md?ask=&goal= ``` `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.