Startseite
» MS OFFICE
»
So erhöhen Sie das Speicherlimit für einen Collabora Online CODE-Container
So erhöhen Sie das Speicherlimit für einen Collabora Online CODE-Container
Wenn ein Collabora Online Development Edition (CODE)-Container unter Last beendet wird oder ständig nahe an seiner Docker-Speichergrenze läuft, besteht die praktische Lösung in der Regel darin, das Docker-Speicherlimit des Containers zu erhöhen, anstatt eine Einstellung in Collabora selbst zu ändern. Docker setzt Speicherlimits auf Container-Laufzeitebene, und Collabora läuft innerhalb dieser Grenzen.
Dieser Leitfaden verwendet durchgehend ein rein hypothetisches Beispiel: Stellen Sie sich ein kleines Team vor, das einen Container codeauf einem Linux-Docker-Host ausführt. Der Container hat ein festes Speicherlimit von 2 GiB, das in Phasen intensiver Bearbeitung fast erreicht wird. Das Team beschließt, ein Limit von 4 GiB zu testen, wobei genügend RAM für das Betriebssystem und andere Dienste verfügbar bleiben soll. Die Zahlen und Auslastungswerte in diesem Beispiel dienen der Veranschaulichung und stellen keine Messergebnisse aus einer realen Implementierung dar.
Stand Oktober 2026 entsprechen die folgenden Befehle der aktuellen Docker-Dokumentation. Collaboras eigene Docker-Dokumentation bezeichnet das CODE-Image als eine Docker-basierte Option von Collabora Online; Docker ist die Komponente, die die Ressourcenbeschränkungen der Container durchsetzt. Beachten Sie bei der Anpassung der Schritte an Ihre Umgebung die offizielle Collabora Online CODE Docker-Dokumentation sowie die Dokumentation zu Docker- Ressourcenbeschränkungen .
Was ändert sich tatsächlich durch die Erhöhung des Speicherlimits?
Ein Docker-Speicherlimit begrenzt die RAM-Nutzung eines Containers. Durch Anheben dieses Limits erhält der Code mehr Spielraum, bevor Speicherengpässe oder ein Speichermangel auftreten. Der gesamte Speicher wird jedoch nicht im Voraus reserviert, und eine schnellere Dokumentenbearbeitung ist nicht garantiert. CPU-Auslastung, Speicherlatenz, Netzwerkbedingungen, Dokumentkomplexität, gleichzeitige Benutzer und das Verhalten der Anwendung können weiterhin Engpässe darstellen.
Docker dokumentiert --memory(oder -m) als feste Speichergrenze für Container. Docker bietet außerdem --memory-swap, das die kombinierte RAM- und Swap-Speicherzuweisung steuert, wenn eine Speichergrenze festgelegt ist. Swap kann als Puffer dienen, aber häufiges Auslagern beeinträchtigt die Leistung. Bei einem Office-Bearbeitungsprogramm sollte Swap nicht als Ersatz für ausreichend physischen Speicher betrachtet werden.
Schritt 1: Bestätigen Sie, dass Speicherdruck das eigentliche Problem ist.
Beginnen Sie damit, den laufenden CODE-Container zu identifizieren und dessen aktuelle Ressourcennutzung zu beobachten:
docker ps
docker stats code
Im hypothetischen Szenario docker statsbelegt der codeContainer etwa 1,8 GiB von einem Limit von 2,0 GiB. Dies wäre ein Grund für weitere Untersuchungen, aber ein einzelner Snapshot reicht nicht aus, um eine dauerhafte Änderung zu rechtfertigen. Beobachten Sie die Speichernutzung während der Arbeitslast, die zu Fehlern führt, und prüfen Sie die Containerprotokolle auf Anzeichen für Beendigung oder Neustart.
Beispielhafter Schritt 1: Überprüfen Sie den laufenden CODE-Container und beobachten Sie die Speichernutzung im Verhältnis zu seinem aktuellen Limit.
Eine hilfreiche Entscheidungsregel ist einfach: Wenn der Container wiederholt an seine konfigurierte Speichergrenze stößt und gleichzeitig Benutzer Sitzungsabbrüche, Neustarts oder OOM-bezogene Ereignisse feststellen, ist eine Erhöhung des Limits ein sinnvoller nächster Schritt. Bleibt der Speicher hingegen deutlich unter der Grenze, wird eine Änderung des Limits das zugrundeliegende Problem wahrscheinlich nicht lösen.
Schritt 2: Lesen Sie das konfigurierte Docker-Speicherlimit ab.
Überprüfen Sie direkt den konfigurierten Speicherwert des Containers:
Docker meldet diesen Wert in Bytes. Beispielsweise 2147483648entsprechen 1 Bytes 2 GiB. Sie können ihn manuell oder mit Shell-Arithmetik umrechnen:
echo $((2147483648 / 1024 / 1024 / 1024))
Beispielhafter Schritt 2: Überprüfen Sie das tatsächliche Docker-Speicherlimit, anstatt es nur aus dem Host-RAM abzuleiten.
Wenn der Wert von `inspect` auf `true` gesetzt ist 0, behandelt Docker den Container normalerweise so, als hätte er kein explizites Speicherlimit. In diesem Fall könnte ein Speichermangel auf Hostebene, ein anderer Orchestrator oder eine andere Einschränkung die eigentliche Ursache sein. Docker gibt an, dass Container standardmäßig keine Ressourcenbeschränkungen haben, sofern keine Limits konfiguriert sind.
Schritt 3: Erhöhen Sie das Limit eines bestehenden Linux-Containers
Docker unterstützt die Änderung des Speicherlimits eines bestehenden Containers mit docker update. Für die hypothetische Änderung von 2 GiB auf 4 GiB:
docker update --memory 4g --memory-swap 4g code
Durch die Einstellung --memory-swapauf denselben Wert --memorywird verhindert, dass der Container gemäß den dokumentierten Speicherauslagerungsregeln von Docker Swap-Speicher verwendet. Wenn Ihre Betriebsrichtlinie Swap-Speicher zulässt, wählen Sie einen Wert bewusst, anstatt dieses Beispiel zu kopieren. Beispielsweise --memory-swaperlaubt ein höherer Wert Swap-Speicher über das RAM-Limit hinaus, während -1unbegrenzter Swap-Speicher vorbehaltlich des verfügbaren Swap-Speichers des Hosts erlaubt ist.
Die aktuelle Docker -Dokumentation zu Docker-Container-Updates listet `<option>` --memory, --memory-reservation`<option>` und --memory-swap`<option>` als aktualisierbare Einstellungen auf. Docker weist außerdem darauf hin, dass ` docker update<option>` für Windows-Container nicht unterstützt wird; CODE-Bereitstellungen verwenden normalerweise einen Linux-Container, aber diese Unterscheidung ist relevant, wenn Sie den Befehl an anderer Stelle anpassen.
Beispielhafter Schritt 3: Erhöhen Sie das Limit für laufende Container und überprüfen Sie sofort den gemeldeten Höchstwert erneut.
Überprüfen Sie nach der Aktualisierung sowohl die Konfiguration als auch den Laufzeitstatus:
Ein niedrigerer Prozentsatz nach der Änderung sollte nicht als Beweis dafür interpretiert werden, dass der Dienst nun weniger RAM benötigt. Der Prozentsatz sinkt, weil der Nenner größer ist. Entscheidend ist, ob der Container unter der Last, die zuvor zu Speicherengpässen geführt hat, stabil bleibt.
Schritt 4: Die Änderung in Docker Compose dauerhaft speichern
Wird der Container mit Docker Compose verwaltet, aktualisieren Sie die Compose-Konfiguration als maßgebliche Quelle. Andernfalls kann eine zukünftige Neuerstellung des Dienstes das alte Limit wiederherstellen oder die Änderung, die nur zur Laufzeit wirksam ist, entfernen.
Bei modernen Docker Compose-Versionen legt die Service-Level- mem_limitEigenschaft die Speichermenge fest, die der Container belegen kann:
Die Compose-Servicereferenz für `mem_limit` in Docker legt fest, dass damit mem_limitdas Speicherlimit für einen Service-Container konfiguriert wird. Compose unterstützt auch Ressourcenlimits unter `<source_limit>` deploy.resources.limits.memory. Wenn Sie beide Formen verwenden, müssen die Speicherwerte laut Docker konsistent sein.
Konfiguration anwenden:
docker compose up -d
Überprüfen Sie anschließend den neu erstellten oder neu gestarteten Dienst:
Beispielhafter Schritt 4: Speichern Sie die neue Speicherobergrenze in Compose, damit eine spätere Container-Neuerstellung die beabsichtigte Einstellung beibehält.
Wie viel Arbeitsspeicher sollten Sie zuweisen?
Es gibt keine allgemeingültige, sichere Anzahl an Containern für jede CODE-Installation. Das geeignete Limit hängt von der Anzahl gleichzeitiger Bearbeiter, der Dokumentgröße und -komplexität, der Hostkapazität, anderen Containern und der Art der Integration des Dienstes ab. Das aktuelle SDK-Handbuch von Collabora enthält Beispielkonfigurationen für Kubernetes-Ressourcen, darunter ein produktionsorientiertes Beispiel mit Speicheranforderungen und -limits im Gigabyte-Bereich. Diese sollten jedoch nicht als universelle Docker-Dimensionierungsformel verstanden werden.
Für den hypothetischen Server sollte die Erhöhung des Arbeitsspeichers von 2 GiB auf 4 GiB als kontrollierte Kapazitätsänderung betrachtet werden. Das Team sollte sicherstellen, dass der Host über ausreichend freien Arbeitsspeicher verfügt, um die höhere Lastspitze abzufangen, ohne andere kritische Dienste zu überlasten. Auf einem Host mit nur wenig freiem Arbeitsspeicher kann eine Erhöhung des CODE-Limits den Fehler lediglich vom Container auf den Host verlagern.
Ein praktischer Dimensionierungsprozess
Erfassen Sie den aktuellen Grenzwert und die Spitzennutzung während typischer Stoßzeiten.
Die Grenze sollte lieber schrittweise erhöht werden, anstatt sie faktisch unbegrenzt zu machen.
Lassen Sie ausreichend Platz für das Host-Betriebssystem, den Reverse-Proxy, Nextcloud oder andere Integrationsdienste, Datenbanken und Überwachungsagenten.
Wiederholen Sie die Arbeitslast und beobachten Sie den tatsächlichen Speicherverbrauch, die Container-Neustarts und die für den Benutzer sichtbaren Fehler.
Wenn die Nutzung immer weiter ansteigt und sich jeder neuen Grenze nähert, sollten Sie das Anwendungsverhalten, Dokumentmuster und Protokolle untersuchen, anstatt immer wieder RAM hinzuzufügen.
Wie sieht es mit Speicherreservierung und Auslagerung aus?
Docker unterscheidet zwischen einem festen Speicherlimit und einer flexiblen Speicherreservierung. Eine Reservierung kann das Verhalten beeinflussen, wenn der Host stark ausgelastet ist, während das feste Limit die absolute Obergrenze darstellt. Bei vielen Single-Host-CODE-Setups ist es einfacher, mit einem expliziten festen Limit zu beginnen. Fügen Sie eine Reservierung nur dann hinzu, wenn Sie eine klare Richtlinie zur Ressourcenteilung auf Hostebene haben.
Beim Swap-Speicher ist besondere Vorsicht geboten. Die Docker-Dokumentation erklärt, dass der Wert --memory-swapden gesamten Arbeitsspeicher plus Swap-Speicher darstellt, wenn er positiv eingestellt ist. Bei einem Wert von 1 --memory=4gund --memory-swap=6g2 kann der Container bis zu 4 GiB RAM und bis zu 2 GiB zusätzlichen Swap-Speicher nutzen. Dies kann in manchen Situationen einen plötzlichen Ausfall verhindern, aber anhaltende Swap-Aktivität kann die interaktive Bearbeitung verlangsamen. Überwachen Sie daher den Swap-Speicher, anstatt anzunehmen, dass mehr Swap-Speicher automatisch sicherer ist.
Woran man erkennt, ob die Änderung funktioniert hat
Erfolg bedeutet nicht einfach nur, 4 GiBetwas zu sehen docker stats. Die aussagekräftigen Anzeichen sind operativ:
Der gemeldete konfigurierte Grenzwert docker inspectentspricht dem Sollwert.
Der Container bleibt während der Arbeitsbelastung, die zuvor Probleme verursacht hat, unterhalb der neuen Decke.
Unerwartete Neustarts oder OOM-bedingte Ausfälle treten unter vergleichbaren Bedingungen nicht mehr auf.
Der Docker-Host verfügt weiterhin über ausreichend freien Speicher und beginnt nicht, stark auszulagern.
Die Bearbeitung bleibt reaktionsfähig und dient nicht nur dazu, eine Kündigung zu vermeiden.
Falls der Container auch deutlich unterhalb des neuen Limits noch fehlschlägt, sollten Sie die Vorgehensweise ändern. Überprüfen Sie docker logs codedie Host-Kernel-Logs, Reverse-Proxy-Fehler, Integrationsserver-Logs sowie die CPU- oder I/O-Auslastung. Ein Speicherlimit ist nur ein Aspekt einer Collabora-Bereitstellung.
Häufige Fehler, die es zu vermeiden gilt
Eine Änderung nur des laufenden Containersdocker update kann das unmittelbare Limit beheben, allerdings müssen auch die von Compose verwalteten Dienste in der Compose-Datei aktualisiert werden.
Wenn CODE den gesamten Hostspeicher erhält, benötigen sowohl der Host als auch benachbarte Dienste zusätzlichen Speicherplatz. Ein uneingeschränkter Container kann zu Instabilität auf dem gesamten Host führen.
Vorausgesetzt, der Auslagerungsspeicher ist freier Speicher: Auslagerungsspeicher ist langsamer als RAM, und Docker warnt ausdrücklich vor Leistungseinbußen, wenn Anwendungen häufig auslagern.
Verwechslung von Container-Speicher und PHP-Speicher: Das Containerlimit von Docker CODE ist von den PHP-Einstellungen, die von Anwendungen wie Nextcloud verwendet werden, getrennt.
Als Beleg dient eine Momentaufnahme: Messen Sie während einer repräsentativen Nachfrage und vergleichen Sie das Verhalten vor und nach der Änderung.
Fazit
Um das Speicherlimit für einen Collabora Online CODE-Container zu erhöhen, prüfen Sie zunächst, ob das bestehende Docker-Limit tatsächlich erreicht wird. Bei einem bestehenden Linux-Container docker update --memory ...kann das Limit zur Laufzeit geändert werden. Bei einer Compose-verwalteten Bereitstellung speichern Sie das Limit mithilfe mem_limiteiner konsistenten Compose-Ressourcenkonfiguration, erstellen oder aktualisieren Sie anschließend den Dienst neu und überprüfen Sie das Ergebnis.
Das hypothetische Beispiel mit 2 GiB bis 4 GiB ist hilfreich, da es den gesamten Entscheidungsprozess aufzeigt: Auslastung beobachten, konfiguriertes Limit bestätigen, es gezielt erhöhen, die Konfiguration speichern und unter derselben Last validieren. Dieses Vorgehen ist zuverlässiger, als einfach einen hohen Wert zuzuweisen und anzunehmen, das Problem sei gelöst.