Wenn die Wolke lahmt: Nextcloud-Datenbankoptimierung jenseits der Standardkonfiguration
Wer Nextcloud betreibt, kennt das Phänomen: Die Instanz läuft monatelang problemlos, doch ab einer bestimmten Größe – sagen wir 50.000 Dateien oder 200 Benutzern – wird der Zugriff spürbar langsamer. Die Weboberfläche tröpfelt, Syncs haken, und plötzlich steht man vor der Frage: Liegt es am Server, an der Netzwerkanbindung – oder an der Datenbank? In neun von zehn Fällen ist es die Datenbank. Das Herz jeder Nextcloud-Instanz schlägt in den Tabellen, und wenn die nicht richtig gepflegt und konfiguriert sind, hilft auch der schnellste NVMe-Speicher nichts.
Nextcloud selbst gibt in der Dokumentation einige Basis-Empfehlungen: Redis einrichten, Cron-Jobs nutzen, den Query-Cache nicht vergessen. Aber die Praxis zeigt, dass diese Maßnahmen oft nur die offensichtlichsten Symptome behandeln. Wer wirklich Performance aus seiner Cloud holen will – ob für den Eigenbedarf im Verein, im Mittelstand oder in der öffentlichen Verwaltung – muss tiefer graben. Dabei zeigt sich, dass die Datenbankoptimierung weniger eine Frage der teuren Hardware ist, sondern vielmehr des Verständnisses für die Arbeitsweise des Systems. Ein interessanter Aspekt ist, dass viele Administratoren scheuen, an den Datenbankeinstellungen zu schrauben, aus Angst, das System zu destabilisieren. Dabei sind die Hebel, an denen man drehen kann, durchaus überschaubar – und die meisten Änderungen sind reversibel.
Nicht zuletzt hat Nextcloud in den letzten Jahren selbst nachgebessert. Ab Version 26 gibt es eine überarbeitete Datenbankabstraktion, und die Entwickler haben einige der berüchtigten N+1-Probleme adressiert. Dennoch: Eine optimierte Konfiguration bleibt ein Eckpfeiler für den Betrieb in größeren Umgebungen. Lassen Sie uns also einen Blick unter die Haube werfen – jenseits der Standard-Ratgeber, mit dem nötigen journalistischen Abstand zur Hype-Kultur, aber ohne die technischen Details zu scheuen.
Warum ausgerechnet die Datenbank?
Die kurze Antwort: Nextcloud speichert nicht nur Dateien, sondern auch deren Metadaten, Berechtigungen, Teilungsinformationen, Kommentare, Chat-Nachrichten aus Talk, Kalenderdaten und vieles mehr. Jede Aktion – ob eine Datei gesynct, ein Kalender aktualisiert oder eine Suche ausgelöst wird – erzeugt eine Kaskade von Datenbankabfragen. Die Architektur ist eigentlich solide: Eine relationale Datenbank (meist MariaDB oder PostgreSQL) verwaltet die Struktur, während Redis als In-Memory-Cache die heißen Daten puffert. Aber genau hier liegt das Problem: Viele Admins installieren Nextcloud mit den Standardeinstellungen des Datenbankservers, die oft für kleine WordPress-Seiten ausgelegt sind, nicht aber für eine Cloud-Plattform mit tausenden von Objekten.
Ein Beispiel: Die Standardkonfiguration von MariaDB verwendet oft einen sehr kleinen innodb_buffer_pool_size – manchmal nur 128 Megabyte. Das mag für ein Portal mit ein paar Dutzend Artikeln reichen, aber nicht für eine Nextcloud mit 100.000 Dateien. Der Buffer Pool ist der zentrale Zwischenspeicher für Daten und Indizes. Ist er zu klein, muss die Datenbank ständig auf die Festplatte ausweichen – und das kostet Zeit. Da hilft auch der schnellste SSD-Speicher nichts, denn die Latenz ist immer noch um Größenordnungen höher als der Zugriff auf den Arbeitsspeicher. Ein interessanter Aspekt ist, dass viele Admins den Fehler machen, ausschließlich auf den Redis-Cache zu setzen, aber die Datenbank selbst zu vernachlässigen. Redis ist kein Ersatz für eine gut konfigurierte relationale Datenbank. Es ist die Spitze des Eisbergs – das Fundament bleibt die Engine.
Die Wahl der Datenbank: PostgreSQL vs. MariaDB
Nextcloud unterstützt offiziell sowohl MariaDB/MySQL als auch PostgreSQL. Die Debatte, welche Datenbank besser geeignet ist, wird in Foren mit missionarischem Eifer geführt. Dabei zeigt sich: Beide Systeme können hervorragend arbeiten, wenn sie richtig konfiguriert sind. PostgreSQL hat den Ruf, bei komplexen Abfragen und vielen gleichzeitigen Verbindungen die Nase vorn zu haben. Vor allem die Planungsqualität des Query-Optimizers wird gelobt. MariaDB (und MySQL) punkten hingegen mit einer größeren Verbreitung und einem einfacheren Einstieg. In der Praxis hängt die Wahl oft von den vorhandenen Kenntnissen des Teams ab. Ein interessanter Aspekt ist, dass Nextcloud selbst in den letzten Versionen den PostgreSQL-Support deutlich verbessert hat – einige Funktionen wie die Transaktionsisolation auf Row-Ebene lassen sich in MariaDB nicht ganz so elegant abbilden.
Allerdings gibt es einen Haken: Die Standardkonfiguration beider Datenbanken ist für Nextcloud suboptimal. Ein PostgreSQL, das ohne Anpassung aus den Paketquellen installiert wird, hat oft einen zu kleinen shared_buffers und einen deaktivierten effective_cache_size. Dazu kommen konservative Einstellungen bei work_mem und maintenance_work_mem. Wer seine Nextcloud also auf einem Standard-PostgreSQL betreibt, verschenkt Performance, auch wenn die Datenbank selbst als solche leistungsfähig ist. Bei MariaDB ist es ähnlich: Der innodb_flush_log_at_trx_commit steht oft auf dem sicheren Wert 1, was zwar die Datenintegrität garantiert, aber die Schreibleistung massiv beeinträchtigt. Für viele Nextcloud-Szenarien reicht der Wert 2 völlig aus – das ist ein kleiner Hebel mit großer Wirkung.
Nicht zuletzt sollte man bedenken: Die Datenbank ist nur dann der Flaschenhals, wenn sie nicht richtig dimensioniert ist. Eine gut geölte Nextcloud mit PostgreSQL auf einem Server mit 32 GB RAM kann problemlos mehrere hunderttausend Dateien verwalten, vorausgesetzt, die Datenbankparameter sind angepasst. Das klingt banal, wird aber in der Praxis oft ignoriert. Ich habe schon Instanzen gesehen, die mit 8 GB RAM und einer Standard-Datenbank liefen – und dann wunderte man sich, warum die Syncs abbrechen. Die Lösung war nicht mehr CPU, sondern eine Stunde Konfigurationsarbeit.
Redis ist kein Allheilmittel – aber manche Administration kommt ohne ihn nicht aus
Redis wird in der Nextcloud-Welt oft als die „Wunderwaffe“ gegen Langsamkeit angepriesen. Zu Recht, denn Redis übernimmt zwei zentrale Aufgaben: Es dient als Lock-Provider (damit keine zwei Prozesse gleichzeitig auf die gleiche Datei zugreifen) und als Zwischenspeicher für den Dateisystem-Cache. Ohne Redis muss Nextcloud auf die Datenbank ausweichen, um Sperren zu setzen und Cache-Einträge zu verwalten – das erzeugt unnötige Last. Insofern ist Redis für jede produktive Nextcloud-Instanz jenseits von zehn Benutzern ein Muss.
Auch hier gilt jedoch: Redis allein optimiert die Datenbank nicht. Es entlastet sie zwar, aber die zugrundeliegenden Tabellen bleiben die gleichen. Ein schlecht konfigurierter Redis-Server kann sogar kontraproduktiv sein, wenn er etwa mit voller Persistenz (AOF + RDB) läuft und die Schreiblast zu hoch wird. Die Faustregel: Redis sollte mit minimaler Persistenz betrieben werden – als reiner Cache ist er für den Verlust von Daten bei einem Neustart ausgelegt. Wenn die Nextcloud-Instanz einmal abstürzt, wird der Cache von der Datenbank neu aufgebaut. Das mag ein paar Minuten dauern, aber das ist akzeptabel. Wer Redis als dauerhaften Speicher missbraucht (etwa für die Session-Daten), riskiert Inkonsistenzen.
Ein interessanter Aspekt ist die Verwendung von Redis als Transaction File Locking. Nextcloud unterstützt verschiedene Locking-Mechanismen, und die Wahl des richtigen hat direkte Auswirkungen auf die Datenbank. Der Standard-Lock-Provider „database“ schreibt Sperren in die Datenbanktabelle oc_file_locks – das kann bei vielen gleichzeitigen Uploads zu Deadlocks und entsprechenden Transaktionskonflikten führen. Mit Redis als Lock-Provider werden diese Sperren im schnellen Speicher gehalten, was die Datenbank entlastet. Das ist ein Paradebeispiel dafür, wie eine geschickte Architektur die Last auf der Datenbank reduziert – aber auch hier gilt: Es ist kein Ersatz für die Optimierung der Datenbank selbst.
Konkrete Handgriffe: Indexe, Tabellen und die Kunst der richtigen Konfiguration
Kommen wir zu den praktischen Maßnahmen. Die erste und einfachste Optimierung, die jeder Administrator vornehmen sollte, ist die regelmäßige Wartung der Datenbank. Nextcloud bietet dazu den Befehl occ db:add-missing-indices an, der fehlende Datenbankindizes ergänzt. Das klingt trivial, wird aber oft übersehen. Bei einem Update von Nextcloud 25 auf 26 werden beispielsweise neue Indizes hinzugefügt, die alte Installationen nicht automatisch nachziehen. Ein fehlender Index auf der Tabelle oc_filecache kann dazu führen, dass jeder Dateizugriff einen Full Table Scan auslöst – bei 200.000 Dateien bedeutet das Latenzen im Sekundenbereich.
Ich empfehle daher, nach jedem größeren Update den Befehl occ db:add-missing-indices sowie occ db:add-missing-primary-keys und occ db:convert-filecache-bigint auszuführen. Letzterer sorgt dafür, dass die Datei-IDs als 64-Bit-Integer gespeichert werden – unverzichtbar für Installationen, die mehr als 2^31 Dateien erreichen könnten. Das ist zwar eher ein Thema für große Rechenzentren, aber vorbeugend schadet es nicht. Ein erfahrener Admin sollte diese Befehle ohnehin in sein Update-Skript integrieren.
Weiter geht es mit der Tabelle oc_share (oder oc_shares je nach Version). Shares sind ein zentrales Element von Nextcloud, und sie erzeugen eine erhebliche Last. Die Tabelle kann schnell auf mehrere hunderttausend Einträge anwachsen. Hier ist ein Index auf den Spalten share_type und uid_owner sinnvoll. Nextcloud legt diese Indizes standardmäßig an, aber bei großen Instanzen kann es vorkommen, dass der Query-Optimizer den falschen Plan wählt. Abhilfe schafft die Verwendung von ANALYZE TABLE in MariaDB oder VACUUM in PostgreSQL, um die Statistiken aktuell zu halten. Das sollte Teil der nächtlichen Cron-Jobs sein.
Ein häufig übersehener Punkt ist die Partitionierung von Tabellen. Für sehr große Installationen mit mehr als einer Million Dateien kann es sinnvoll sein, die oc_filecache-Tabelle nach Datum oder nach einer Hash-Funktion zu partitionieren. Allerdings: Nextcloud unterstützt das nicht nativ. Man müsste also manuell Partitionen einrichten und die Anwendung entsprechend anpassen – das ist eher etwas für fortgeschrittene Administratoren. In der Praxis reicht oft eine gut dimensionierte Datenbank mit ausreichendem Buffer Pool. Wer wirklich an die Grenzen stößt, sollte über die Verwendung von mehreren Shards nachdenken – aber das ist dann eher eine Frage der Architektur und nicht mehr der reinen Optimierung.
Die Datenbank-Engine: InnoDB vs. MyISAM (und warum Sie MyISAM meiden sollten)
Nextcloud verwendet standardmäßig InnoDB (bei MariaDB) – das ist auch gut so. MyISAM ist tabellenbasiert und unterstützt keine Transaktionen, was in einer Multi-User-Umgebung zu Inkonsistenzen führt. Dennoch gibt es immer wieder Admins, die aus Performance-Gründen auf MyISAM setzen, weil es bei reinen Lesezugriffen schneller ist. Das ist ein fataler Irrtum: Nextcloud schreibt bei jedem Sync, bei jedem Teilen, bei jeder Kalenderänderung – und ohne Transaktionsschutz sind Datenkorruptionen vorprogrammiert. Wer MyISAM verwendet, sollte dringend umsteigen. Die Konvertierung ist mit ALTER TABLE t ENGINE=InnoDB; einfach möglich, aber wegen der Größe der Tabellen sollte man das in einer Wartungsphase durchführen.
Für InnoDB gibt es einige Parameter, die speziell auf Nextcloud zugeschnitten werden sollten. Der innodb_buffer_pool_size sollte auf 70–80 % des verfügbaren Arbeitsspeichers gesetzt werden, wenn die Datenbank auf demselben Server läuft wie der Webserver und die Applikation. Läuft die Datenbank auf einem dedizierten Server, kann man bis zu 90 % gehen. Der Wert muss nicht exakt sein – eine grobe Schätzung reicht. Wichtiger ist, dass er nicht zu klein gewählt wird. Ein weiterer Parameter ist innodb_log_file_size. Standard sind oft 48 MB, was bei vielen Schreiboperationen zu einem häufigen Log-Swapping führt. Empfehlung: auf mindestens 256 MB erhöhen. Das reduziert die Anzahl der Checkpoints und verbessert die Schreibleistung deutlich.
Und dann ist da noch innodb_flush_log_at_trx_commit. Bei Wert 1 wird bei jeder Transaktion das Log auf die Festplatte geschrieben – absolut sicher, aber langsam. Wert 0 schreibt nur nach internen Regeln, was risiko-behaftet ist. Wert 2 ist der Kompromiss: Das Log wird einmal pro Sekunde auf die Platte geschrieben. Für 99 % der Nextcloud-Installationen ist Wert 2 vollkommen ausreichend, denn der potenzielle Datenverlust einer Sekunde ist bei den meisten Anwendungen irrelevant. Wer wirklich sicher gehen muss (z. B. bei Finanztransaktionen – aber die sind in Nextcloud eher selten), kann bei Wert 1 bleiben. Aber dann sollte man die I/O-Subsystem des Servers optimieren, z. B. mit einer separaten Log-Partition auf schnellem NVMe.
PostgreSQL-spezifische Optimierungen
Wer PostgreSQL nutzt, hat andere Stellschrauben. Der wichtigste Parameter ist shared_buffers. Auch hier gilt: etwa 25–40 % des Arbeitsspeichers, aber nicht mehr. PostgreSQL verwendet den Kernel-Buffer-Cache zusätzlich, sodass ein zu großer shared_buffers kontraproduktiv sein kann. Der zweite wichtige Wert ist effective_cache_size. Er sollte auf etwa 50–75 % des gesamten RAMs gesetzt werden. Der Query-Optimizer nutzt ihn, um die Kosten von Index-Scans einzuschätzen. Ein zu niedriger Wert führt dazu, dass PostgreSQL viele Full Table Scans plant, obwohl ein Index besser wäre.
Ein interessanter Aspekt bei PostgreSQL ist das autovacuum. Nextcloud generiert viele Transaktionen, sodass die Tabellen schnell fragmentieren. Das Autovacuum läuft standardmäßig, aber die Parameter sollten für Nextcloud angepasst werden. autovacuum_vacuum_scale_factor und autovacuum_analyze_scale_factor sollten auf kleinere Werte gesetzt werden, z. B. 0.01, damit die Vakuum-Prozesse häufiger laufen, aber dafür mit geringerer Last. Andernfalls kann es passieren, dass eine Tabelle wie oc_filecache zu einem bestimmten Zeitpunkt massiv wächst und dann das Autovacuum mit voller Wucht zuschlägt – was die CPU und die I/O belastet. Besser ist ein gleichmäßiges, kontinuierliches Vakuumieren.
PostgreSQL bietet zudem die Möglichkeit, Indizes als CONCURRENTLY zu erstellen, ohne die Tabelle zu sperren. Das ist für die Wartung großer Nextcloud-Instanzen ein Segen. Man kann also einen neuen Index hinzufügen, während der Betrieb läuft – das dauert zwar länger, aber die Ausfallzeiten entfallen. Nextcloud selbst nutzt diese Funktion nur in den Skripten für den Datenbank-Update, aber Admins können sie manuell einsetzen, um eigene Indizes nachzurüsten, etwa auf den Spalten storage und path in oc_filecache.
Der Mythos der regelmäßigen Datenbankoptimierung
Man hört immer wieder, dass man die Datenbank regelmäßig „optimieren“ sollte, etwa durch OPTIMIZE TABLE (MariaDB) oder CLUSTER (PostgreSQL). Ich halte das für übertrieben. Die Datenbank-Engines sind heute selbstoptimierend, solange die Statistiken aktuell sind und die Indizes nicht fragmentieren. Bei InnoDB ist die Fragmentierung meist vernachlässigbar, da die Engine die Daten intern verwaltet. Ein OPTIMIZE TABLE ist nur dann sinnvoll, wenn sehr viele Löschungen stattgefunden haben, etwa nach einem großen Cleanup von alten Dateien. Ansonsten reicht ein regelmäßiges ANALYZE TABLE (MariaDB) oder ANALYZE (PostgreSQL), um die Statistiken zu aktualisieren. Der Aufwand einer Komplett-Optimierung steht in keinem Verhältnis zum Nutzen.
Eine Ausnahme ist die Tabelle oc_activity. Hier sammeln sich schnell sehr viele Einträge, die später kaum noch abgefragt werden. Nextcloud bietet eine Einstellung, um die Anzahl der Aktivitäten zu begrenzen (Standard: 50 pro Benutzer). Trotzdem wächst die Tabelle, weil ältere Einträge nicht automatisch gelöscht werden. Ein manuelles Löschen über occ activity:clean oder ein eigener Cron-Job kann Wunder wirken. Das vermindert die Tabellengröße und reduziert die Scan-Zeiten bei Aktivitätsabfragen.
Query-Optimierung und Log-Analyse – der Blick des Profis
Ein erfahrener Administrator hört nicht auf das Bauchgefühl, sondern auf die Metriken. Der erste Schritt zur Optimierung ist die Aktivierung des Slow-Query-Logs in der Datenbank. Bei MariaDB schaltet man slow_query_log und long_query_time auf z. B. 2 Sekunden. Nach einigen Tagen erhält man eine Liste der Queries, die am meisten Zeit fressen. Dann kann man gezielt nachbessern: Fehlt ein Index? Ist der Join ineffizient? Oder wird eine Spalte abgefragt, die kein Teil des Indexes ist? Oft zeigt sich, dass Nextcloud selbst bei Standardabfragen suboptimale Pläne produziert. Ein klassisches Beispiel: Die Suche über mehrere Tabellen auf oc_filecache und oc_share. Hier kann ein zusammengesetzter Index auf (storage, path) die Leistung verbessern. Nextcloud verwendet standardmäßig einen Index auf (storage, fileid), aber die Suche geht meist über den Pfad. Mit EXPLAIN (MariaDB) oder EXPLAIN ANALYZE (PostgreSQL) kann man das nachvollziehen.
Ein interessanter Aspekt ist die Verwendung von Query-Caching. MariaDB bietet den query_cache_type, der aber in den neueren Versionen deaktiviert oder entfernt wurde (da er bei Schreiblast mehr schadet als nützt). PostgreSQL hat kein vergleichbares Query-Cache, sondern verlässt sich auf den Shared Buffer. Eigentlich ist das besser, denn der Buffer Pool flusht die Daten nicht bei jeder Änderung. In der Praxis ist die Wiederverwendbarkeit von Query-Ergebnissen in Nextcloud ohnehin begrenzt, da sich die Daten ständig ändern. Ein Redis-Cache mit TTL ist hier die bessere Lösung.
Datenbank-Monitoring und Tools
Nextcloud selbst liefert einige Werkzeuge: occ db:… Befehle, das Admin-Dashboard mit Hinweisen zu fehlenden Indizes, und die Möglichkeit, die Datenbankgröße anzuzeigen. Für detaillierte Analysen greift man aber zu externen Tools. Für MariaDB ist mytop oder innotop ein Klassiker – Kommandozeilen-Tools, die Live-Queries anzeigen. Für PostgreSQL gibt es pg_stat_statements und pg_top. Damit lassen sich die häufigsten Queries nach Laufzeit und Aufrufhäufigkeit sortieren. In einer Nextcloud-Instanz mit vielen Benutzern sind das oft die Suche, die Sync-Checks und die Abfrage der Dateiliste.
Ein weiteres Tool ist Percona Toolkit für MySQL/MariaDB, insbesondere pt-query-digest, das die Slow-Query-Logs zusammenfasst. Das ist hilfreich, um Muster zu erkennen: Sind es immer wieder die gleichen Queries? Handelt es sich um einen einzelnen Benutzer, der tausende von Dateien abfragt? Oder um einen Cron-Job, der die Aktivitäten leert? Die Analyse gibt Hinweise auf das Verhalten der Anwendung.
Nicht zuletzt sollte man die Datenbank-Größe im Auge behalten. Eine Nextcloud-Instanz mit 100 Benutzern und 500 GB Nutzdaten hat oft eine Datenbank von 1–2 GB. Wenn die Datenbank plötzlich auf 10 GB anwächst, liegt das meist an zu vielen Einträgen in den Aktivitätstabellen oder an einer vollgelaufenen oc_jobs-Tabelle (Cron-Jobs). Letztere kann man über occ background-queue:status überprüfen. Ein Reinigungs-Skript in der Stunde vor der Hauptlast ist empfehlenswert.
Kritische Anmerkungen zur Nextcloud-Architektur
Ich möchte nicht den Eindruck erwecken, dass alle Probleme durch Admin-Konfiguration lösbar sind. Nextcloud hat in puncto Datenbankdesign durchaus Schwächen. Manche Queries sind unnötig komplex, weil die Entwickler auf eine generalisierte Abstraktion setzen, die für alle Datenbanken funktioniert. Das führt manchmal zu SQL-Statements, die 15 Joins oder mehrere Subqueries enthalten. Beispiel: Die Berechnung der noch verfügbaren Speicherplatz für einen Benutzer – das ist eine Query, die den gesamten Ordnerbaum durchlaufen muss. In großen Instanzen kann das mehrere Sekunden dauern. Nextcloud hat hier in Version 27 einen Caching-Mechanismus eingeführt, der die Werte zwischenspeichert. Aber das ist ein Tropfen auf den heißen Stein.
Ein weiterer Kritikpunkt ist die fehlende Partitionierung der Tabellen, wie bereits erwähnt. In der Cloud-Welt ist das eigentlich Standard – aber Nextcloud setzt auf Flexibilität statt auf Optimierung für bestimmte Größen. Das macht die Installation einfach, aber die Skalierung schwer. Man kann Nextcloud durchaus mit tausenden Benutzern und Millionen Dateien betreiben, aber der Aufwand für die Datenbank-Administration steigt überproportional. Viele Admins wundern sich dann, warum die Cloud nach einem Jahr „lahm und träge“ wirkt. Die Antwort ist meist die Datenbank.
Es gibt auch eine Bewegung hin zu NoSQL-Lösungen für bestimmte Metadaten, etwa Apache Cassandra, aber Nextcloud setzt weiterhin auf relationale Datenbanken. Das ist aus Gründen der Konsistenz und des Datenschutzes auch sinnvoll. Dennoch: Wer wirklich mehrere hunderttausend Objekte verwalten will, sollte die Investition in eine leistungsfähige Datenbank-Hardware und eine sorgfältige Konfiguration nicht scheuen.
Der ideale Nextcloud-Stack
Gestatten Sie mir einen kleinen Exkurs: Was wäre denn eigentlich die ideale Konfiguration für eine mittelgroße Nextcloud-Instanz (100-200 Benutzer, 50.000 Dateien)? Ich skizziere es kurz: Ein Server mit 16 GB RAM, davon 4 GB für Redis (maximal 2 GB effektiv genutzt, aber Reservierung), 4 GB für den Webserver und PHP, 4 GB für die Datenbank (davon 3 GB für den Buffer Pool). Die Festplatte sollte ein RAID 1 aus NVMe-SSDs sein, mit separater Partition für das Datenbank-Log. Der Datenbank-Parameter innodb_flush_log_at_trx_commit auf 2, innodb_log_file_size auf 512 MB. Redis läuft ohne Persistenz, als Lock-Provider und Cache. Der Cron-Job sollte alle 5 Minuten ausgeführt werden, und occ db:… wird nach jedem Update analysiert. Das ist keine Hexerei, aber in der Praxis sieht es oft anders aus: Ein vServer mit 4 GB RAM, die Datenbank frisst mit den Standards 128 MB, und Redis fehlt ganz. Kein Wunder, dass die Performance leidet.
Für Instanzen mit mehr als 500 Benutzern wird es komplexer. Dann sollte man über eine separate Datenbank-Instanz nachdenken, vielleicht mit Master-Slave-Replikation für Lesezugriffe. Nextcloud unterstützt das zwar nicht offiziell, aber man kann den Query-Proxy so konfigurieren, dass lesende Queries an die Replica gehen. Das ist aber ein fortgeschrittenes Thema und erfordert tiefe Eingriffe in die Nextcloud-Konfiguration. Die meisten Anwender werden nie in diese Dimension vorstoßen. Für den Normalbetrieb gilt: Eine gut eingestellte Einzeldatenbank reicht völlig aus.
Zusammenfassung und Fazit
Nextcloud-Datenbankoptimierung ist kein Hexenwerk, aber sie braucht Sorgfalt und ein grundlegendes Verständnis der Zusammenhänge. Die ersten Schritte sind einfach: Redis einrichten, Cron-Job konfigurieren, fehlende Indizes ergänzen, die Datenbank-Parameter anpassen. Danach folgt die regelmäßige Überwachung mit Slow-Query-Logs und Statistiken. Wer das beherzigt, wird mit einer flüssigen Cloud belohnt. Wer es ignoriert, wird sich früher oder später mit Performance-Problemen herumschlagen.
Dabei zeigt sich immer wieder: Die meisten Adminstrationen machen sich das Leben unnötig schwer, weil sie die Datenbank als Blackbox betrachten. Dabei ist es gerade die Datenbank, die den größten Einfluss auf die Benutzererfahrung hat. Ein schönes Beispiel aus der Praxis: Eine Nextcloud-Instanz mit 80 Benutzern lief nach der Optimierung von MariaDB-Parametern plötzlich doppelt so schnell – ohne eine einzige Hardware-Änderung. Der Admin hatte vorher einfach die Standardwerte akzeptiert. Das zeigt: Es lohnt sich, die Ärmel hochzukrempeln und selbst Hand anzulegen. Die Werkzeuge sind alle vorhanden. Sie müssen nur genutzt werden.
Nicht zuletzt: Nextcloud entwickelt sich weiter. Die Version 28 bringt einige Änderungen im Datenbank-Layer mit sich, die LOB- und CLOB-Daten effizienter verwalten. Trotzdem: Die Grundlagen bleiben gleich. Wer heute seine Datenbank optimiert, investiert in die Zukunft seiner Cloud-Infrastruktur. Und das ist nicht nur eine technische, sondern auch eine strategische Entscheidung. Denn eine langsame Cloud frustriert die Benutzer und untergräbt das Vertrauen in die Technologie. Also: Nehmen Sie sich die Zeit, die Datenbank zu pflegen. Ihr zukünftiges Ich – und Ihre Benutzer – werden es Ihnen danken.