Wymagania sprzętowe

Wymagania sprzętowe

Przy przygotowywaniu sprzętu do uruchomienia Overleaf głównym czynnikiem, który należy wziąć pod uwagę, jest liczba użytkowników jednocześnie uruchamiających kompilacje.

Na przykład, jeśli masz licencję na łącznie 100 użytkowników, ale spodziewasz się, że jednocześnie będzie pracować tylko ~5 z nich, minimalna instalacja będzie wystarczająca. Jeśli spodziewasz się, że jednocześnie pracować (i kompilować) będzie większy odsetek użytkowników, rozważ przygotowanie serwera o wyższej specyfikacji.

Minimalna instalacja

Do podstawowej pracy przy około 5 jednoczesnych użytkownikach wymagane są co najmniej 2 rdzenie i 3 GB pamięci. Te minimalne wymagania wystarczą również dla większych grup, w których jednoczesne użycie jest mniejsze lub w których dopuszczalne jest wydłużenie czasu kompilacji w okresach większego obciążenia.

Jeśli rozważasz użycie systemu plików opartego na NFS (Network File System) dla swojej małej instancji, zapoznaj się z odpowiednim fragmentem sekcji Rozwiązywanie problemów.

Skalowanie

Zgodnie z ogólną zasadą, aby zapewnić wysoki i stały poziom usług, do minimalnej instalacji należy dodać 1 rdzeń CPU i 1 GB pamięci na każdych 5–10 jednoczesnych użytkowników.

Należy to traktować wyłącznie jako wskazówkę, ponieważ na wymagany poziom 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 przy dużym obciążeniu.

Wielu naszych klientów chce wdrażać Server Pro w całej organizacji lub w dużych zespołach. W takich sytuacjach trudno nam doradzić konkretne wymagania konfiguracyjne, ponieważ przypadki użycia i dostępny sprzęt mogą być bardzo zróżnicowane.

Przykład 1	Przykład 2
Jeśli prowadzisz instalację Server Pro dla łącznie 300 użytkowników 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 rdzeni i 3 GB) powinno zapewnić wystarczające zasoby, aby użytkownicy mieli stale wysoki poziom usług.	Jako przykład wymagań sprzętowych dla większego wdrożenia: instalacja Server Pro dla łącznie 1000 użytkowników została z powodzeniem uruchomiona na pojedynczym serwerze wyposażonym w dwa 4-rdzeniowe procesory i 32 GB pamięci systemowej. Przez ostatni rok użytkowania w pełni wystarczało to na potrzeby zespołu.

Klienci, którzy przekraczają możliwości pojedynczego dużego serwera, mogą zapoznać się z sekcją Skalowanie poziome dla Server Pro.

Pamięć masowa

Odradzamy używanie Network File System (NFS)/Amazon EFS/Amazon EBS do przechowywania projektów i historii w większych instalacjach, a w przypadku skalowania poziomego wprost tego nie wspieramy.

Te systemy plików nie zapewniają wydajności i niezawodności, których Server Pro potrzebuje przy działaniu na dużą skalę. Gdy system plików nie nadąża z obciążeniem, aplikacja zawiesza się z powodu zbyt wielu blokujących operacji wejścia/wyjścia. Takie przestoje mogą prowadzić do przekroczenia czasu blokad opartych na Redis, co z kolei może skutkować uszkodzeniem danych projektów.

Zamiast tego zalecamy używanie pamięci obiektowej zgodnej z S3. Niska wydajność S3 wpływa jedynie na przesyłanie i pobieranie plików, co prowadzi wyłącznie do zwiększonej liczby otwartych połączeń z dostawcą S3 i 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 na systemie plików/IO na poziomie aplikacji.

Dla porównania GitLab przyjmuje podobne stanowisko, nie wspierając NFS/Amazon EFS w swojej ofercie do samodzielnego hostowania.

Konfiguracja 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 nawiązać połączenia, strona edytora może nie załadować się w całości, a żądania kompilacji mogą kończyć się niepowodzeniem. Nginx będzie zwracał odpowiedzi ze statusem 500 i zapisywał worker_connections are not enough while connecting to upstream w var/log/nginx/error.log wewnątrz kontenera sharelatex.

Ustawienie worker_connections ogranicza liczbę jednoczesnych połączeń, które nginx przyjmie na jeden proces roboczy. Liczba procesów roboczych jest kontrolowana przez ustawienie worker_processes, które w naszej konfiguracji nginx domyślnie wynosi 4.

Nginx wykonuje niewiele pracy w porównaniu z innymi częściami systemu, więc te limity pełnią rolę zabezpieczenia, które zapobiega przeciążeniu systemu przez zbyt wiele połączeń. Lepiej wcześnie 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 (domyślnie 4)

• NGINX_WORKER_CONNECTIONS dla worker_connections (domyślnie 768)

• NGINX_KEEPALIVE_TIMEOUT dla keepalive_timeout (domyślnie 65)

  Jeśli przed kontenerem sharelatex działa inne proxy (np. do terminacji TLS), wartość NGINX_KEEPALIVE_TIMEOUT w instancji Overleaf Server musi być większa niż w poprzedzającym proxy. Na przykład przy innym procesie nginx na hoście Docker nginx-host, oto dwa przykłady:

• Domyślna wartość NGINX_KEEPALIVE_TIMEOUT: użyj keepalive_timeout 60s (wartość domyślna w upstream) w nginx-host

• Własna wartość NGINX_KEEPALIVE_TIMEOUT=100s: użyj keepalive_timeout 90s (własna wartość w upstream) w nginx-host

Szybkość CPU

LaTeX jest programem jednowątkowym, co oznacza, że w danym momencie może korzystać tylko z jednego rdzenia CPU. CPU jest również głównym ograniczeniem podczas kompilowania dokumentu. Dlatego im wyższa wydajność jednordzeniowa procesora, tym szybciej będzie można skompilować dokument. Więcej rdzeni pomoże tylko wtedy, gdy próbujesz kompilować więcej dokumentów, niż masz wolnych rdzeni CPU.