> 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/de/erste-schritte/requirements/hardware-requirements.md). # Hardwareanforderungen ## Hardwareanforderungen Wenn Sie Hardware bereitstellen, um Overleaf auszuführen, ist der wichtigste zu berücksichtigende Faktor, wie viele gleichzeitige Benutzer Kompilierungen ausführen werden. Zum Beispiel: Wenn Sie eine Lizenz für insgesamt 100 Benutzer haben, aber erwarten, dass nur etwa 5 gleichzeitig arbeiten, reicht die Minimalinstallation aus. Wenn Sie erwarten, dass ein größerer Anteil gleichzeitig arbeitet (und kompiliert), sollten Sie die Bereitstellung eines Servers mit höherer Spezifikation in Betracht ziehen. ### Minimalinstallation Eine minimale Grundanforderung von 2 Kernen und 3 GB Speicher ist für grundlegende Aufgaben mit etwa 5 gleichzeitigen Benutzern erforderlich. Diese Mindestanforderung reicht auch für größere Gruppen aus, bei denen die gleichzeitige Nutzung geringer ist oder bei denen längere Kompilierzeiten bei höherer Auslastung akzeptabel sind. {% hint style="danger" %} Wenn Sie für Ihre kleine Instanz ein auf NFS (Network File System) basierendes Dateisystem in Betracht ziehen, werfen Sie bitte einen Blick auf diesen Abschnitt im [Fehlerbehebung](/on-premises/de/support/troubleshooting.md) Abschnitt. {% endhint %} ### Skalierung Als Faustregel gilt: Um einen hohen und gleichbleibenden Servicegrad zu gewährleisten, sollte für jeweils 5–10 gleichzeitige Benutzer 1 CPU-Kern und 1 GB Speicher zur Minimalinstallation hinzugefügt werden. Dies sollte nur als Richtlinie verstanden werden, da Faktoren wie die Größe typischer Dokumente (größere Dokumente verbrauchen mehr Kompilierungsressourcen), wie oft Benutzer kompilieren und wie viel Toleranz für längere Kompilierzeiten bei hoher Auslastung besteht, alle den erforderlichen Bereitstellungsumfang beeinflussen. Viele unserer Kunden möchten Server Pro unternehmensweit oder für große Teams einsetzen. In solchen Situationen ist es für uns schwierig, konkrete Anforderungen an das Setup zu nennen, da die Anwendungsfälle und die zugrunde liegende verfügbare Hardware sehr unterschiedlich sein können. | Beispiel 1 | Beispiel 2 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Wenn Sie eine Server-Pro-Installation für insgesamt 300 Benutzer betreiben und regelmäßig damit rechnen, dass 30–60 dieser Benutzer gleichzeitig Dokumente kompilieren, sollten 8 GB und 7 Kerne (5 Kerne + 5 GB + Basis von 2 Kernen & 3 GB) ausreichende Ressourcen bieten, damit Ihre Benutzer dauerhaft einen hohen Servicegrad erhalten. | Um ein Beispiel für die Hardwareanforderungen einer größeren Bereitstellung zu geben: Eine Server-Pro-Installation für insgesamt 1.000 Benutzer wurde erfolgreich mit einem einzelnen Server eingerichtet, der mit zwei 4-Kern-Prozessoren und 32 GB Systemspeicher ausgestattet war. Dies reichte im vergangenen Nutzungsjahr für die Anforderungen des Teams aus. | Kunden, die die Grenzen eines einzelnen großen Servers überschreiten, können sich [Horizontale Skalierung](/on-premises/de/wartung/horizontal-scaling.md) für Server Pro ansehen. ### Speicher Wir raten davon ab, in größeren Setups Network File System (NFS)/Amazon EFS/Amazon EBS für die Projekt-/Verlaufspeicherung zu verwenden, und unterstützen dies ausdrücklich **nicht** für die horizontale Skalierung. Das Verhalten dieser Dateisysteme bietet nicht die notwendige Leistung und Zuverlässigkeit, die Server Pro bei Betrieb in großem Maßstab benötigt. Wenn das Dateisystem mit der Last nicht Schritt halten kann, bleibt die Anwendung aufgrund zu vieler blockierender I/O-Operationen hängen. Diese Hänger können zu überlaufenen Redis-basierten Locks führen, was wiederum zu beschädigten Projektdaten führen kann. Wir empfehlen die Verwendung von [S3-kompatiblem Objektspeicher](/on-premises/de/erste-schritte/what-is-the-overleaf-toolkit.md) stattdessen. Eine langsame S3-Performance wirkt sich wiederum nur auf das Hoch- und Herunterladen von Dateien aus, was lediglich zu einer erhöhten Anzahl offener Verbindungen zu Ihrem S3-Anbieter führt und sich wiederum nicht auf das Verhalten des restlichen Systems auswirkt. Außerdem kann Server Pro sinnvolle Timeouts für S3-Anfragen festlegen, was auf Anwendungsebene für Dateisystem-/I/O-Operationen nicht möglich ist. {% hint style="info" %} Als Referenz verfolgt GitLab eine ähnliche Position, nämlich [NFS/Amazon EFS nicht zu unterstützen](https://docs.gitlab.com/ee/administration/nfs.html) mit seinem selbstverwalteten Angebot. {% endhint %} ### Nginx-spezifische Konfiguration für große Bereitstellungen Standardmäßig begrenzt die Overleaf-Server-Instanz die Anzahl der Verbindungen auf 768. Dazu gehören persistente WebSocket-Verbindungen, HTML-Navigation auf oberster Ebene und AJAX-Anfragen. Sobald das Limit erreicht ist, kann der Editor möglicherweise keine Verbindung herstellen, die Editorseite wird möglicherweise nicht vollständig geladen und Kompilierungsanfragen können fehlschlagen. Nginx gibt dann 500-Statusantworten zurück und protokolliert `worker_connections reichen beim Verbinden mit dem Upstream nicht aus` in `var/log/nginx/error`.log im `sharelatex` -Container. Die [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) Einstellung begrenzt die Anzahl gleichzeitiger Verbindungen, die nginx pro Worker akzeptiert. Die Anzahl der Worker wird durch die [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) Einstellung gesteuert und ist in unserer nginx-Konfiguration standardmäßig auf 4 gesetzt. Nginx erledigt im Vergleich zu anderen Teilen des Systems nicht viel Arbeit, daher dienen diese Grenzen als Schutz, damit nicht zu viele Verbindungen das System überlasten. Es ist besser, einige überschüssige Verbindungen frühzeitig abzulehnen, als jede Verbindung zu verlangsamen. Overleaf-Server-Instanzen stellen Umgebungsvariablen bereit, um diese nginx-Einstellungen anzupassen: * `NGINX_WORKER_PROCESSES` für [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (Standard `4`) * `NGINX_WORKER_CONNECTIONS` für [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (Standard `768`) * `NGINX_KEEPALIVE_TIMEOUT` für [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (Standard `65`)

Wenn ein weiterer Proxy vor dem sharelatex Container (z. B. für TLS-Terminierung) ausgeführt wird, muss der NGINX_KEEPALIVE_TIMEOUT in der Overleaf-Server-Instanz größer sein als der des vorherigen Proxys. Z. B. mit einem weiteren nginx-Prozess auf dem Docker-Host nginx-host, hier sind zwei Beispiele:

* Standardwert `NGINX_KEEPALIVE_TIMEOUT`, verwenden Sie [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (Standardwert im Upstream) in **nginx-host** * Benutzerdefinierter Wert `NGINX_KEEPALIVE_TIMEOUT=100s`, verwenden Sie [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (benutzerdefinierter Wert im Upstream) in **nginx-host** ### CPU-Geschwindigkeit LaTeX ist ein Single-Threaded-Programm, was bedeutet, dass es immer nur einen CPU-Kern gleichzeitig nutzen kann. Die CPU ist auch die Hauptbegrenzung beim Kompilieren eines Dokuments. Daher gilt: Je schneller die Single-Core-Leistung Ihrer CPU ist, desto schneller können Sie ein Dokument kompilieren. Mehr Kerne helfen nur, wenn Sie versuchen, mehr Dokumente zu kompilieren, als Sie freie CPU-Kerne haben. --- # 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/de/erste-schritte/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.