So beheben Sie die hohe CPU-Auslastung von Collabora Online (von loolwsd / coolwsd)

Wenn Collabora Online plötzlich einen Großteil der Server-CPU beansprucht, ist es wichtig, nicht wiederholt neu zu starten oder sofort ein sehr niedriges CPU-Limit festzulegen. Ermitteln Sie zunächst, ob die Last durch normale Dokumentbearbeitung, eine fehlerhafte Dokumentsitzung, zu viele parallele Prozesse, eine nicht beendete Leerlaufsitzung oder eine versionsspezifische Regression verursacht wird. Der Prozessname kann sowohl coolwsdin aktuellen als auch loolwsdin älteren Installationen variieren.

Beispiel: Stellen Sie sich einen Server mit 8 vCPUs vor, auf dem Collabora Online hinter Nextcloud läuft. Nur wenige Personen bearbeiten Dokumente, doch der Collabora-Container beansprucht mehrere Minuten lang 250 bis 350 % der CPU. Dies ist ein hypothetisches Beispiel, das in diesem Leitfaden verwendet wird, und kein gemessener Benchmark oder Bericht aus einer realen Implementierung.

Stand Oktober 2026 ist die aktuelle stabile Version von Collabora 26.04. Die offiziellen Versionshinweise geben Collabora Online 26.04.3.3 als Veröffentlichungsdatum am 14. September 2026 an. Aktuelle Konfigurationsvorlagen verwenden noch den coolwsdalten Namen. Die Migrationstools von Collabora dokumentieren weiterhin den älteren /etc/loolwsd/loolwsd.xmlPfad für Installationen aus der Versionsära 6.4 oder älter. Daher können Administratoren noch auf beide Namen stoßen.

1. Prüfen Sie, welcher Prozess tatsächlich die CPU-Leistung beansprucht.

Beginnen Sie auf Betriebssystem- oder Containerebene. Eine hohe Zahl daneben coolwsdbedeutet nicht automatisch, dass der koordinierende Daemon die gesamte rechenintensive Dokumentenverarbeitung übernimmt. Collabora verwendet außerdem Kit-/Forkit-Prozesse für Dokumentensitzungen. Prüfen Sie daher die Prozessstruktur und die CPU-Auslastung pro Prozess, bevor Sie Konfigurationsänderungen vornehmen.

ps -eo pid,ppid,pcpu,pmem,etime,cmd --sort=-pcpu | head -n 25
top -H -p $(pgrep -d, -f 'coolwsd|loolwsd|coolkit|loolkit|forkit')

Bei Docker sollten Sie auch den Container als Ganzes überprüfen:

docker stats --no-stream

Angenommen, der Container liegt in diesem Beispiel bei nahezu 300 % CPU-Auslastung und ein bestimmter Kit-Prozess befindet sich konstant an der Spitze der Prozessliste. Dies deutet eher auf eine spezifische aktive Dokumentensitzung hin als auf eine allgemeine Überlastung des gesamten Servers.

2. Prüfen Sie die Metriken von Collabora selbst, anstatt sich nur auf die Top-Bewertungen zu verlassen.

Collabora Online stellt Prometheus-kompatible Metriken unter [URL] bereit /cool/getMetrics. Laut aktuellem SDK-Handbuch kann dieser Endpunkt CPU- und Speicherauslastung, laufende Kit-Prozesse, Ansichten und weitere Servernutzungsdaten melden. Er verwendet dieselbe Authentifizierung wie die Administrationskonsole, sofern die Metriken nicht explizit für den Zugriff ohne Authentifizierung konfiguriert sind.

Geben Sie den Metrik-Endpunkt nicht öffentlich preis, nur um die Fehlersuche zu vereinfachen. Die offizielle Helm-Konfiguration enthält sogar Beispiele für Blockierungs- /cool/getMetricsund Admin-URLs am Ingress. Verwenden Sie nach Möglichkeit einen authentifizierten, internen Pfad.

Prüfen Sie den Zusammenhang zwischen CPU-Auslastung und aktiven Dokumenten oder Ansichten. Steigt und fällt die CPU-Auslastung bei legitimer Bearbeitung, könnte ein Kapazitäts- oder Parallelitätsproblem vorliegen. Bleibt die CPU-Auslastung ohne entsprechende interaktive Aktivitäten hoch, untersuchen Sie veraltete Sitzungen, ein fehlerhaftes Dokument, wiederholte Hintergrundprozesse oder ein Softwareproblem.

3. Lesen Sie die Protokolle ungefähr zu dem Zeitpunkt, an dem die CPU-Auslastung ansteigt.

Für eine von systemd verwaltete Paketinstallation:

journalctl -u coolwsd --since "15 minutes ago" --no-pager
journalctl -u coolwsd -f

Für Docker:

docker logs collabora --since 15m
docker logs -f collabora

Wenn Ihr Dienst oder Container einen anderen Namen hat, verwenden Sie diesen. Achten Sie auf wiederholtes Laden von Dokumenten, wiederholtes Erstellen von Kits, fehlgeschlagene Speichervorgänge, Abstürze, Verbindungsschleifen oder das wiederholte Auftreten desselben Dokumentschlüssels. Eine kurzzeitig erhöhte CPU-Auslastung beim Öffnen, Neuberechnen, Rendern, Konvertieren oder Exportieren von Dokumenten kann normal sein. Ein deutlicheres Warnsignal ist jedoch eine anhaltend hohe CPU-Auslastung ohne erkennbaren Fortschritt oder das Wiederauftreten desselben Fehlers.

4. Reproduzieren Sie den Fehler mit jeweils einem Dokument.

Kehren Sie zum hypothetischen Server zurück. Falls ein Kit-Prozess stark ausgelastet ist, schließen oder isolieren Sie das verdächtige Dokument und beobachten Sie, ob die CPU-Auslastung sinkt. Öffnen Sie anschließend dieselbe Datei in einer ruhigen Phase und überwachen Sie dabei die Prozessliste und die Metriken. Wiederholen Sie den Vorgang mit einem einfachen Testdokument.

Dieser Vergleich ist sinnvoller als ein sofortiger Neustart des gesamten Dienstes:

• Wenn nur eine einzige Datei zuverlässig den Lastanstieg auslöst, sind der Inhalt der Datei, Formeln, eingebettete Objekte, die Rendering-Last oder ein dokumentspezifischer Fehler die wahrscheinlichsten Ursachen.
• Wenn jede Datei eine ähnliche Auslastung verursacht, sobald mehrere Benutzer aktiv sind, sollten Sie die Serverkapazität und die Parallelität untersuchen.
• Wenn die CPU-Auslastung auch nach Beendigung aller Benutzeraktivitäten hoch bleibt, konzentrieren Sie sich auf Aufräumarbeiten, veraltete Kits, wiederholte Hintergrundaufgaben oder eine Regression.
• Wenn das Problem unmittelbar nach einem Upgrade auftrat, notieren Sie sich die alte und die neue Version, bevor Sie viele andere Variablen ändern.

5. Reduzierung der gleichzeitigen Verarbeitung pro Dokument, wenn ein Dokument mehrere Kerne gleichzeitig belegen kann

Die aktuelle Collabora-Konfigurationsvorlage legt per_document.max_concurrencydie maximale Anzahl der Threads fest, die bei der Verarbeitung eines Dokuments verwendet werden. Der Standardwert der Vorlage ist 4. Auf leistungsschwächeren Systemen oder wenn ein einzelnes komplexes Dokument die Systemlast stark beansprucht, kann eine Reduzierung dieses Wertes die CPU-Auslastung besser vorhersagen.

Sie könnten beispielsweise den Wert 2 testen:

<per_document>
    <max_concurrency>2</max_concurrency>
</per_document>

Die Zahl 2 sollte nicht unreflektiert übernommen werden. Wenn Benutzer regelmäßig große Tabellen oder Präsentationen bearbeiten und der Server über ausreichend Prozessorkerne verfügt, kann ein niedrigerer Wert die Arbeit sogar verlangsamen. Ändern Sie eine Einstellung, wiederholen Sie die gleiche Arbeitslast und vergleichen Sie CPU-Auslastung, Reaktionsfähigkeit und Bearbeitungszeit.

6. Überprüfen Sie die Einstellungen für Bereinigung und Leerlaufsitzungen, bevor Sie sie aggressiv einstellen.

Die aktuelle coolwsd.xmlVorlage enthält eine Bereinigungslogik für ressourcenintensive, inaktive Dokumente. Zum Zeitpunkt der Erstellung dieses Dokuments weist die Vorlage ein Bereinigungsintervall von 10.000 ms, eine kritische Wartezeit von 60 Sekunden, eine Leerlaufzeit von 300 Sekunden und eine CPU-Auslastung von 85 % auf, ab der ein Dokument als Kandidat für die Bereinigung gilt. Zusätzlich ist ein Leerlauf-Timeout von 3.600 Sekunden pro Dokument festgelegt.

Die gleiche Vorlage enthält Timeouts pro Ansicht. Aktuell werden 300 Sekunden angezeigt, bevor eine nicht fokussierte Browseransicht abgedunkelt und Aktualisierungen gestoppt werden, und 900 Sekunden, bevor eine inaktive Ansicht analog behandelt wird. Diese Ansichts-Timeouts entsprechen nicht dem sofortigen Beenden einer gesamten Dokumentsitzung.

Vermeiden Sie es, den CPU-Schwellenwert extrem niedrig anzusetzen, nur um die Grafik optisch ansprechender zu gestalten. Die Bereinigung dient dazu, ressourcenintensive, fehlerhafte oder inaktive Dokumente zu erkennen, nicht aber, die normale Bearbeitung zu beenden, sobald sie rechenintensiv wird.

7. Starten Sie das System erst nach dem Speichern einer kontrollierten Konfigurationsänderung neu.

Sichern Sie zunächst die aktive Konfiguration. Paketinstallationen verwenden typischerweise eine Konfigurationsdatei /etc/coolwsd/coolwsd.xml. Docker-Bereitstellungen können Optionen als Umgebungsvariablen oder Befehlszeilenbefehle übergeben oder eine Konfigurationsdatei in den Container einbinden. Prüfen Sie, welche Quelle tatsächlich aktiv ist, bevor Sie Änderungen vornehmen.

Für eine Paketinstallation:

sudo cp /etc/coolwsd/coolwsd.xml /etc/coolwsd/coolwsd.xml.before-cpu-tuning
sudo systemctl restart coolwsd
systemctl status coolwsd --no-pager

Für einen Docker-Container:

docker restart collabora
docker ps --filter name=collabora

Wenn ein Neustart das Problem mit der CPU vorübergehend behebt, es aber wiederholt auftritt, handelt es sich dabei um eine Diagnoseinformation, nicht um eine dauerhafte Lösung. Fahren Sie fort, bis Sie erklären können, welche Arbeitslast oder welcher Zustand das erneute Auftreten verursacht.

8. Vergleichen Sie den Zustand vor und nach der Umsetzung unter gleicher Arbeitslast.

Verwenden Sie dasselbe Dokument, annähernd dieselbe Anzahl an Benutzern und dieselbe Abfolge von Aktionen. Messen Sie über mehrere Minuten, anstatt nur einen einzelnen Zeitpunkt zu vergleichen. Im Beispiel bedeutet Erfolg, dass der Server während der simulierten Arbeitslast nicht mehr überlastet ist und das Öffnen, Bearbeiten, Speichern und die Zusammenarbeit an Dokumenten weiterhin zufriedenstellend funktionieren.

Wann sollte man ein Update durchführen anstatt nur die Einstellungen zu optimieren?

Wenn das Verhalten mit einer bestimmten Collabora-Version begann und sich mit einer bestimmten Datei oder Operation reproduzieren lässt, kann eine Konfigurationsoptimierung einen Softwarefehler lediglich verschleiern. Collabora empfiehlt die Verwendung der neuesten Version aus dem aktuellen stabilen Zweig. Auf der offiziellen Seite mit den Versionshinweisen zu Collabora 26.04 wird seit dem 7. Oktober 2026 die Version 26.04.3.3 als aktuellste dort aufgeführte Collabora Online-Version genannt.

Für CODE-Nutzer gilt: Collabora beschreibt die Development Edition als geeignet für kleine Teams, den Heimgebrauch, die Entwicklung und das Testen neuer Funktionen, weist aber gleichzeitig darauf hin, dass sie nicht für Produktionsumgebungen vorgesehen ist. Ein Produktionsvorfall in CODE kann daher den Wechsel zum unterstützten Collabora Online-Produkt rechtfertigen, anstatt sich endlos mit dem Verhalten der Development Edition herumzuschlagen.

Was man nicht tun sollte

• Gehen Sie nicht davon aus, dass eine hohe coolwsdZahl auf ein Speicherleck oder eine Endlosschleife hinweist.
• Aktivieren Sie die Debug- oder Trace-Protokollierung während eines CPU-Vorfalls nicht dauerhaft, es sei denn, Sie benötigen sie tatsächlich; ausführliche Protokollierung verursacht zusätzlichen Aufwand und Speicherdruck.
• Die Administrationskonsole oder der Metrik-Endpunkt sollten nicht aus Gründen der Überwachungsfreundlichkeit öffentlich im Internet zugänglich gemacht werden.
• Die Bereinigungsschwellenwerte sollten erst gesenkt werden, wenn normale aktive Sitzungen beendet werden.
• Verwenden Sie CPU-Kontingente nicht als ersten Diagnoseschritt. Ein festes Limit kann zwar Nachbarn auf einem gemeinsam genutzten Host schützen, aber es kann ein CPU-Problem in langsames Dokumentenrendering und Timeouts umwandeln, ohne die Ursache aufzudecken.

Empfohlene Reihenfolge bei der Fehlerbehebung

1. Prüfen Sie, ob es sich bei dem ausgelasteten Prozess um coolwsdeinen älteren Prozess loolwsdoder einen Kindprozess handelt.
2. Docker- oder Host-CPU, Arbeitsspeicher, aktive Dokumente und Ansichten aufzeichnen.
3. Korrelieren Sie die Protokolle mit dem exakten Spitzenfenster.
4. Reproduzieren Sie den Vorgang mit einem verdächtigen Dokument und anschließend mit einem einfachen Kontrolldokument.
5. Testen Sie per_document.max_concurrencynur, ob ein Dokument zu viel parallele CPU-Leistung beansprucht.
6. Überprüfen Sie die Einstellungen für Bereinigung und Leerlauf, ohne sie unnötig aggressiv zu gestalten.
7. Nach jeder kontrollierten Konfigurationsänderung einen Neustart durchführen und den Zustand des Dienstes überprüfen.
8. Vergleichen Sie die gleiche Arbeitslast vor und nach der Anwendung und prüfen Sie dann in der aktuellen stabilen Version, ob das Verhalten versionsspezifisch erscheint.

Offizielle Referenzen

Die Konfigurationsdetails in diesem Leitfaden basieren auf der aktuellen Collabora Online-Quellvorlage: Collabora Online coolwsd.xml-Konfigurationsvorlage . Das offizielle SDK-Handbuch dokumentiert Protokollierung, Leistungssteuerung und den Prometheus-kompatiblen Metrik-Endpunkt: Collabora Online SDK-Handbuch . Versionsinformationen finden Sie in den Versionshinweisen zu Collabora Online 26.04 des Herstellers . Informationen zum vorgesehenen Verwendungszweck der Development Edition finden Sie in der offiziellen CODE 26.04-Versionsankündigung .

Das praktische Ziel besteht nicht darin, Collabora Online zu zwingen, so wenig CPU-Leistung wie möglich zu verbrauchen. Vielmehr soll der CPU-Verbrauch nachvollziehbar und proportional zur tatsächlichen Arbeitsleistung sein, während gleichzeitig eine akzeptable Bearbeitungs- und Kollaborationsleistung erhalten bleibt.