> 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/de/erste-schritte/requirements/hardware-requirements.md). # Hardwareanforderungen ## Hardwareanforderungen Bei der Bereitstellung von Hardware für den Betrieb von Overleaf ist der wichtigste Faktor, wie viele gleichzeitige Benutzer Kompilierungen ausführen werden. Wenn Sie beispielsweise eine Lizenz für insgesamt 100 Benutzer haben, aber nur erwarten, dass etwa 5 gleichzeitig arbeiten, ist die minimale Installation ausreichend. Wenn Sie erwarten, dass ein höherer Anteil gleichzeitig arbeitet (und kompiliert), sollten Sie die Bereitstellung eines Servers mit einer höheren Spezifikation in Betracht ziehen. ### Minimale Installation Eine minimale Grundanforderung von 2 Kernen und 3 GB Arbeitsspeicher ist für grundlegende Vorgänge mit rund 5 gleichzeitigen Benutzern erforderlich. Diese Mindestanforderung ist auch für größere Gruppen ausreichend, bei denen es weniger gleichzeitige Nutzung gibt oder es in Ordnung ist, wenn die Kompilierzeiten bei höherer Auslastung länger sind. {% hint style="danger" %} Wenn Sie erwägen, für Ihre kleine Instanz ein auf NFS (Network File System) basierendes Dateisystem zu verwenden, werfen Sie bitte einen Blick auf diesen Abschnitt im [Fehlerbehebung](/on-premises/de/support/troubleshooting.md) Abschnitt. {% endhint %} ### Skalierung Als Faustregel gilt: Um ein hohes und gleichbleibendes Serviceniveau bereitzustellen, sollte der Minimalinstallation für jeweils 5–10 gleichzeitige Benutzer 1 CPU-Kern und 1 GB Speicher hinzugefügt werden. Dies sollte nur als Richtwert verstanden werden, da Faktoren wie die Größe typischer Dokumente (größere Dokumente verbrauchen mehr Kompilierressourcen), wie oft Benutzer kompilieren und wie hoch die Toleranz für längere Kompilierzeiten bei hoher Auslastung ist, alle das erforderliche Bereitstellungsniveau beeinflussen. Viele unserer Kunden planen den unternehmensweiten Einsatz von Server Pro oder den Einsatz in großen Teams. In solchen Situationen ist es für uns schwierig, konkrete Anforderungen an das Setup zu empfehlen, 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 erwarten, dass 30–60 dieser Benutzer gleichzeitig Dokumente kompilieren, sollten 8 GB und 7 Kerne (5 Kerne + 5 GB + Basis von 2 Kernen und 3 GB) ausreichende Ressourcen bieten, damit Ihre Benutzer ein konstant hohes Serviceniveau 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 hat den Anforderungen des Teams im vergangenen Nutzungsjahr genügt. | 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, Network File System (NFS)/Amazon EFS/Amazon EBS für die Projekt-/Historien-Speicherung in größeren Setups zu verwenden, und unterstützen dies ausdrücklich **nicht** für 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 mithalten kann, bleibt die Anwendung aufgrund zu vieler blockierender IO-Operationen stehen. Diese Stillstände können dazu führen, dass Redis-basierte Sperren überlaufen, was wiederum zu beschädigten Projektdaten führen kann. Wir empfehlen stattdessen die Verwendung von [S3-kompatiblem Objektspeicher](/on-premises/de/erste-schritte/what-is-the-overleaf-toolkit.md) 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 angemessene Timeouts für S3-Anfragen festlegen, was auf Anwendungsebene für Dateisystem-/IO-Operationen nicht möglich ist. {% hint style="info" %} Zum Vergleich verfolgt GitLab eine ähnliche Haltung und [unterstützt NFS/Amazon EFS nicht](https://docs.gitlab.com/ee/administration/nfs.html) für sein selbstverwaltetes Angebot. {% endhint %} ### Nginx-spezifische Konfiguration für große Bereitstellungen Standardmäßig beschränkt die Overleaf-Server-Instanz die Anzahl der Verbindungen auf 768. Dazu gehören dauerhafte WebSocket-Verbindungen, HTML-Navigation auf oberster Ebene und Ajax-Anfragen. Sobald das Limit erreicht ist, kann sich der Editor möglicherweise nicht verbinden, die Editorseite wird möglicherweise nicht vollständig geladen, und Kompilierungsanfragen können fehlschlagen. Nginx gibt Status-500-Antworten zurück und protokolliert `worker_connections reichen beim Verbinden mit dem Upstream nicht aus` in `var/log/nginx/error`.log innerhalb des `sharelatex` Containers. 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 Begrenzungen als Schutzmaßnahme, damit nicht zu viele Verbindungen das System überlasten. Es ist besser, überschüssige Verbindungen frühzeitig abzulehnen, anstatt jede Verbindung zu verlangsamen. Overleaf-Server-Instanzen stellen Umgebungsvariablen zur Anpassung dieser nginx-Einstellungen bereit: * `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 vor dem sharelatex Container (z. B. für TLS-Terminierung) ein weiterer Proxy läuft, muss das NGINX_KEEPALIVE_TIMEOUT im Overleaf-Server-Container 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-Thread-Programm, was bedeutet, dass es jeweils nur einen CPU-Kern nutzen kann. Die CPU ist außerdem die wichtigste Begrenzung 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://ayakaleaf-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.