> 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/pl/pierwsze-kroki/requirements/hardware-requirements.md). # Wymagania sprzętowe ## Wymagania sprzętowe Przy przydzielaniu sprzętu do uruchomienia Overleaf głównym czynnikiem do rozważenia jest liczba jednoczesnych użytkowników, którzy będą wykonywać kompilacje. Na przykład, jeśli masz licencję dla łącznie 100 użytkowników, ale oczekujesz, że w tym samym czasie będzie pracować tylko około 5, minimalna instalacja będzie wystarczająca. Jeśli spodziewasz się, że większy odsetek będzie pracował (i kompilował) jednocześnie, powinieneś rozważyć uruchomienie serwera o wyższej specyfikacji. ### Minimalna instalacja Minimalne podstawowe wymagania to 2 rdzenie i 3 GB pamięci dla podstawowych operacji przy około 5 jednoczesnych użytkownikach. To minimalne wymaganie będzie również wystarczające dla większych grup, w których jednoczesne użycie jest mniejsze, lub gdy 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 małej instancji, prosimy zajrzeć do tej sekcji w [Rozwiązywanie problemów](/on-premises/pl/wsparcie/troubleshooting.md) sekcji. {% endhint %} ### Skalowanie Z grubsza, 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 to traktować wyłącznie jako wskazówkę, ponieważ 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 akceptowalność dłuższych czasów kompilacji podczas dużego obciążenia — wszystko to wpływa na poziom wymaganych zasobów. Wielu naszych klientów planuje wdrożyć Server Pro w całej organizacji lub w dużych zespołach. W takich sytuacjach trudno nam doradzać w sprawie konkretnych wymagań 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 łącznie 300 użytkowników i regularnie oczekujesz, że 30–60 z nich będzie kompilować dokumenty w tym samym czasie, 8 GB i 7 rdzeni (5 rdzeni + 5 GB + baza 2 rdzenie i 3 GB) powinno zapewnić wystarczające zasoby, aby użytkownicy mieli konsekwentnie wysoki poziom usług. | Dla przykładu, jeśli chodzi o wymagania sprzętowe dla większego wdrożenia, instalację Server Pro dla łącznie 1000 użytkowników udało się pomyślnie uruchomić na pojedynczym serwerze wyposażonym w dwa 4-rdzeniowe procesory i 32 GB pamięci systemowej. Było to wystarczające dla potrzeb zespołu w ciągu ostatniego roku użytkowania. | Klienci, którzy przekraczają możliwości pojedynczego dużego serwera, mogą zapoznać się z [Skalowaniem poziomym](/on-premises/pl/konserwacja/horizontal-scaling.md) dla Server Pro. ### Pamięć masowa Odradzamy używanie Network File System (NFS)/Amazon EFS/Amazon EBS do przechowywania projektów/historii w większych konfiguracjach i wyraźnie **nie obsługujemy tego** w skalowaniu poziomym. Zachowanie tych systemów plików nie zapewnia niezbędnej 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. Te zatrzymania mogą prowadzić do wygaśnięcia blokad opartych na Redis, co z kolei może skutkować uszkodzeniem danych projektu. Zalecamy użycie [magazynu obiektowego zgodnego z S3](/on-premises/pl/pierwsze-kroki/what-is-the-overleaf-toolkit.md) zamiast tego. Niska wydajność S3 wpływa jedynie na wysyłanie/pobieranie plików, co powoduje jedynie zwiększoną liczbę otwartych połączeń do dostawcy S3 i z kolei nie wpływa na działanie pozostałej części aplikacji. Dodatkowo Server Pro może określać rozsądne limity czasu dla żądań S3, co nie jest możliwe dla operacji systemu plików/I/O na poziomie aplikacji. {% hint style="info" %} Dla porównania GitLab przyjmuje podobne stanowisko, polegające na [nieobsługiwaniu NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) w swojej ofercie self-managed. {% 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ę na najwyższym poziomie HTML 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 `liczba worker_connections nie jest wystarczająca podczas łączenia z upstreamem` do `var/log/nginx/error`.log w `sharelatex` kontenerze. Ustawienie [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) ogranicza liczbę jednoczesnych połączeń, które nginx zaakceptuje na jednego workera. Liczba workerów jest kontrolowana przez ustawienie [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) i jest domyślnie ustawiona na 4 w naszej konfiguracji nginx. Nginx nie wykonuje zbyt wiele pracy w porównaniu z innymi częściami systemu, więc te limity działają jako zabezpieczenie, zapobiegające przeciążeniu systemu przez zbyt dużą liczbę połączeń. Lepiej jest wcześnie odrzucić część nadmiarowych połączeń 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`)

Gdy przed kontenerem działa inny proxy (np. do zakończenia TLS), ustawienie sharelatex w instancji Overleaf Server musi być większe niż w poprzednim proxy. Np. przy innym procesie nginx na hoście Docker NGINX_KEEPALIVE_TIMEOUT nginx-host , oto dwa przykłady:Przykład wartości domyślnej

* Wartość domyślna `NGINX_KEEPALIVE_TIMEOUT`, użyj [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (domyślna wartość w upstreamie) w **, oto dwa przykłady:** * Wartość niestandardowa `NGINX_KEEPALIVE_TIMEOUT=100s`, użyj [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (niestandardowa wartość w upstreamie) w **, oto dwa przykłady:** ### Prędkość CPU LaTeX jest programem jednowątkowym, co oznacza, że może wykorzystywać tylko jeden rdzeń CPU naraz. CPU jest również głównym ograniczeniem podczas kompilowania dokumentu. Dlatego im szybsza jest wydajność jednego rdzenia Twojego procesora, tym szybciej będziesz mógł skompilować dokument. Większa liczba 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://ayakaleaf-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.