Nextcloud-Limits auf dem VPS: Was wirklich schlecht läuft

Worin Nextcloud schlecht ist, in der Reihenfolge, in der Sie darauf stoßen

Die meisten Einschränkungen von Nextcloud auf einem VPS hängen eher von der Anzahl der Dateien und Anfragen als von der Speichergröße ab. Eine 200 GB große Sammlung von Videodateien läuft auf einem kleinen Server problemlos. Dieselben 200 GB, verteilt auf 400,000 kleine Dateien, machen jede Ordnerauflistung langsam und verwandeln die Datenbank in den ausgelastetsten Prozess auf dem System. Die folgende Reihenfolge entspricht der Reihenfolge, in der ein Self-Hoster auf diese Grenzen stößt: zuerst das PHP-Anforderungsmodell, dann der Sync-Client, anschließend die Datenbankstandards, danach Hintergrundaufgaben und zuletzt der Arbeitsspeicher.

Manches, was als „Nextcloud ist langsam“ bezeichnet wird, ist eine Standardeinstellung, die niemand geändert hat. Der Rest ist durch das Design bedingt und lässt sich durch Tuning nicht beseitigen. In jedem Abschnitt wird erläutert, welcher Fall vorliegt.

Warum PHP Ihre Parallelitätsgrenze festlegt

Nextcloud ist in PHP geschrieben, und eine PHP-Anwendung ist kein dauerhaft laufender Server. Jede Anfrage wird von einem Worker-Prozess aus einem PHP-FPM-Pool (FastCGI process manager) verarbeitet. Dieser Worker ist von Anfang bis Ende für die Anfrage zuständig. Die Anzahl der Anfragen, die der Server gleichzeitig verarbeiten kann, beträgt daher pm.max_children. Jeder dieser Worker belegt eigenen Arbeitsspeicher.

Daraus folgen zwei Dinge. Eine langsame Anfrage belegt den Worker während ihrer gesamten Laufzeit. Ein Benutzer, der einen 4-GB-Upload zusammenstellt, belegt dadurch einen Slot, den kein anderer Benutzer verwenden kann. Wenn alle Worker ausgelastet sind, warten neue Anfragen in der Socket-Warteschlange. Der Pool meldet das in seinem Log:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Zuerst zeigt sich das Problem normalerweise als 504-Fehler des vorgeschalteten Webservers:

upstream timed out (110: Connection timed out) while reading response header from upstream

Ein Pool der Standarddistribution wird häufig mit pm.max_children = 5 ausgeliefert. Das ist eine sinnvolle Annahme für einen gemeinsam genutzten Server, aber für eine Nextcloud-Instanz mit einem Dutzend verbundenen Sync-Clients viel zu niedrig. Legen Sie die Größe anhand des tatsächlich verfügbaren Arbeitsspeichers fest: Messen Sie die Resident-Größe eines ausgelasteten Workers, lassen Sie Platz für die Datenbank und den Cache und teilen Sie den verbleibenden Speicher durch diesen Wert.

pm = dynamic
pm.max_children = 12
pm.max_requests = 500
php_value[memory_limit] = 512M

memory_limit ist eine Obergrenze pro Anfrage und keine feste Speicherzuweisung. Die meisten Anfragen verwenden nur einen kleinen Teil davon. Bei der Vorschaugenerierung und beim Zusammenstellen großer Uploads wird der übrige Speicher benötigt. Deshalb müssen das Limit und die Anzahl der Child-Prozesse gemeinsam festgelegt werden.

Zwischen den Anfragen gibt es außerdem keinen gemeinsam genutzten Anwendungsspeicher. Jede Anfrage startet das Framework erneut: Konfiguration, aktivierte Apps, Routen und Event-Listener. OPcache hält den kompilierten Bytecode vor. Dadurch muss der Code ausgeführt und nicht erneut geparst werden. APCu (alternative PHP cache) stellt einen kleinen lokalen Schlüssel-Wert-Speicher im gemeinsam genutzten Speicher bereit. Deshalb ist die Zeile „No memory cache has been configured“ in der Admin-Übersicht relevant. Ohne diesen Cache werden Abfragen, die aus dem Speicher beantwortet werden könnten, bei jeder einzelnen Anfrage an die Datenbank gestellt. Dieser Teil ist eine Konfigurationsfrage. Das zugrunde liegende Modell mit einem Prozess pro Anfrage ist architekturell bedingt.

Warum viele kleine Dateien den Server lange vor der Festplatte ausbremsen

Nextcloud speichert Metadaten für jede Datei und jeden Ordner in einer Datenbanktabelle, oc_filecache: Pfad, Pfad-Hash, Größe, Änderungszeit, ETag und Storage-ID. Eine Ordnerauflistung ist eine Abfrage gegen diese Tabelle und kein readdir auf der Festplatte. Beim Schreiben wird die Zeile der Datei aktualisiert. Anschließend werden die neue Größe und das neue ETag durch jeden übergeordneten Ordner bis zum Wurzelverzeichnis weitergereicht. Ein Upload ist eine HTTP-Anfrage, mehrere SQL-Anweisungen und eine weitere Aktualisierung pro Verzeichnisebene.

Die Übertragung erfolgt ebenfalls pro Datei. Das Synchronisierungsprotokoll ist WebDAV (web distributed authoring and versioning), und WebDAV überträgt eine Datei pro Anfrage. 400,000 Dateien bedeuten 400,000 Anfragen. Jede Anfrage umfasst Authentifizierung, das Initialisieren des Frameworks, Berechtigungsprüfungen und Datenbankschreibvorgänge. Bei jeweils 25 ms Serverzeit summiert sich allein dieser Overhead auf fast drei Stunden, bevor auch nur ein Byte Nutzdaten übertragen wurde. Betrachten Sie das als Rechenbeispiel, nicht als Benchmark. Die entscheidende Aussage lautet: Der Aufwand richtet sich nach der Anzahl der Dateien, nicht nach ihrer Größe.

Schneller Speicher hilft bei einem Teil dieses Aufwands. Gerade bei zufälligen kleinen Lese- und Schreibvorgängen unterscheiden sich NVMe- und SATA-SSD-Speicher bei VPS am stärksten. NVMe ist daher für eine große Instanz sinnvoll. Die Kosten pro Anfrage bleiben jedoch unverändert, weil sie durch PHP und SQL entstehen und nicht durch die Festplatte.

Eine Folge überrascht jeden irgendwann. Dateien, die außerhalb von Nextcloud auf den Server kopiert werden, existieren aus Sicht von Nextcloud nicht, weil die entsprechende Zeile nie geschrieben wurde. Sie erscheinen erst, nachdem occ files:scan den Verzeichnisbaum durchläuft und die fehlenden Zeilen schreibt. Bei einem großen Verzeichnisbaum dauert dieser Scan lange. Wenn Sie nicht wissen, wo diese Dateien bei einer containerbasierten Installation liegen, finden Sie unter dem Datenverzeichnisaufbau von Nextcloud in Docker eine separate Anleitung. Dieser Punkt ist architektonisch: Die Datenbank ist die Dateiauflistung.

Warum der Desktop-Client bei einem großen Verzeichnisbaum langsamer wird

Der Sync-Client ist leistungsfähiger als sein Ruf. Weil ein Schreibvorgang ein neues ETag bis zum Stammverzeichnis weitergibt, kann der Client mit einer kostengünstigen Abfrage feststellen, ob sich überhaupt etwas geändert hat. Anschließend steigt er nur in Verzeichnisse hinab, deren ETag abweicht. Das Abfragen im Leerlauf ist daher an sich nicht aufwendig.

Die verbleibenden Kosten sind real. Beim ersten Sync wird jedes Verzeichnis durchsucht, mit einer PROPFIND-Anfrage pro Verzeichnis, und jede Datei wird heruntergeladen. Eine Umbenennung nahe der Spitze des Verzeichnisbaums ändert das ETag aller darunterliegenden Elemente. Daher prüft der Client diesen gesamten Teilbaum erneut. Der Client verwaltet außerdem eine eigene lokale Datenbank und ermittelt Dateiinformationen für die lokalen Dateien. Eine langsame Laptop-Festplatte oder ein aggressiver Virenscanner verursacht daher zusätzliche Verzögerungen, die überhaupt nichts mit Ihrem Server zu tun haben.

Ohne die Client-Push-App fragt jeder verbundene Client nach einem Zeitplan ab: notify_push. Dreißig Clients erzeugen eine konstante Rate von Hintergrundanfragen an denselben Worker-Pool, der auch die Weboberfläche bedient. notify_push ist ein kleiner separater Dienst, der pro Client eine WebSocket-Verbindung hält und die Clients über Änderungen informiert. Dadurch entfällt der größte Teil dieses Datenverkehrs im Leerlauf. Bei einer stark ausgelasteten Instanz gehört dies zu den wirkungsvollsten Erweiterungen.

Es gibt keinen Merge. Wenn zwei Personen dieselbe Datei bearbeiten, während sie offline sind, wird eine Konfliktkopie mit einem Namen wie budget (conflicted copy 2026-08-22 141530).ods erzeugt. Ein Mensch muss den Konflikt anschließend manuell auflösen. Die Bearbeitung über einen Office-Dienst vermeidet dieses Problem, weil dann auf dem Server immer nur eine Kopie maßgeblich ist. Virtuelle Dateien, bei denen eine Datei zunächst als Platzhalter angezeigt und erst beim Öffnen geladen wird, funktionieren unter Windows und macOS stabil. Unter Linux hat sich diese Funktion langsamer etabliert. Prüfen Sie daher Ihre Client-Version, bevor Sie einen Workflow darauf aufbauen. Das Abfragen ist Konfiguration. Eine Anfrage pro Datei ist Architektur.

Was eine Standardinstallation offenlässt

Eine frisch installierte Nextcloud funktioniert. Bei einer typischen manuellen Installation fehlen jedoch noch vier Dinge. Alle vier sind unter Settings, Administration, Overview sichtbar.

• Kein Memory-Cache. In der Übersicht steht „No memory cache has been configured“. APCu verursacht kaum Aufwand und verhindert zahlreiche wiederholte Datenbankabfragen.
• File-Locking in der Datenbank. Nextcloud sperrt eine Datei, während sie geschrieben wird. Ohne Redis liegt diese Sperre in einer Datenbanktabelle. Das erhöht die Schreiblast und hinterlässt nach einem abgebrochenen Request veraltete Sperren. Benutzer sehen dann Fehlermeldungen, dass die Datei gesperrt ist. Erst eine manuelle Bereinigung entfernt diese Sperren.
• Fehlende Datenbankindizes. In der Übersicht steht „The database is missing some indexes“. Dort wird occ db:add-missing-indices genannt. Bei einem filecache mit Millionen von Zeilen entscheiden diese Indizes darüber, ob eine Auflistung schnell oder langsam ist.
• SQLite. Bei einer manuellen Installation kann SQLite verwendet werden. Die Dokumentation empfiehlt SQLite nur für Tests und minimale Instanzen. Schreibvorgänge werden serialisiert. Bereits ein zweiter aktiver Benutzer ist dann zu viel.

'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
  'host' => 'localhost',
  'port' => 6379,
],

Nichts davon ist exotisch. Alles gehört zur Konfiguration. Wenn Sie lieber mit einer Installation beginnen möchten, bei der diese Entscheidungen bereits getroffen wurden, richtet die Docker-Installation mit TLS und Backups den Cache und den cron-Container als Teil des Stacks ein.

Warum Hintergrundaufträge ohne konfigurierte cron-Aufgabe ins Stocken geraten

Nextcloud verlagert rechenintensive Aufgaben in Hintergrundaufträge: Vorschauen erzeugen, alte Dateiversionen nach Ablauf löschen, den Papierkorb planmäßig leeren, Benachrichtigungs-E-Mails senden und Freigaben bereinigen. Dafür gibt es drei unterstützte Ausführungsarten. Die Standardeinstellung ist die schwächste.

Im AJAX-Modus wird ein Auftrag ausgeführt, wenn ein Browser eine Seite lädt. Wird eine persönliche Instanz eine Woche lang nicht besucht, läuft eine Woche lang nichts. Versionen und Papierkorb laufen nicht ab. Dadurch füllt sich der Datenträger weiter mit Daten, die der Benutzer gelöscht zu haben glaubt. Vorschauen werden nicht vorab erzeugt. Die erste Person, die einen Fotoordner öffnet, muss daher warten, während die eigene Anfrage die Vorschauen erzeugt. Schließlich meldet die Übersicht, dass der letzte Hintergrundauftrag vor Stunden ausgeführt wurde und dass „Something seems wrong“. Das ist die einzige Warnung, die Sie erhalten.

Webcron und system cron beheben dieses Problem. system cron führt cron.php alle fünf Minuten als Webserver-Benutzer aus. Bei einer Installation in einem Container wird derselbe Auftrag aus einem dedizierten cron-Container ausgeführt. Fünf Minuten ist das in der Dokumentation angegebene Intervall. Die Intervalle der Aufträge sind darauf abgestimmt.

Die verbleibende Einschränkung besteht darin, dass die Aufträge nacheinander ausgeführt werden. Ein langer Auftrag, eine Vorschau-Batchverarbeitung oder ein Dateiscan verzögert alle dahinter eingereihten Aufträge. Auf einem VPS mit einem CPU-Kern konkurriert dieser Lauf außerdem mit aktiven Anfragen. Auf einem ausgelasteten Host verlängert CPU-Steal-Time durch überlastete Nachbarn diese Läufe über das hinaus, was Ihre eigenen Zahlen erwarten lassen. Konfiguration ist daher bei den meisten vernachlässigten Instanzen die Maßnahme mit dem größten Nutzen.

Die Speicheruntergrenze mit Office, Talk oder Vorschauen

Eine einfache Nextcloud-Installation ist genügsam: ein PHP-Pool, eine Datenbank, Redis und ein Webserver. Eine kleine Instanz läuft mit 2 GB komfortabel. Jede Funktion, die Benutzer tatsächlich benötigen, ist ein eigener Dienst mit eigener Speicheruntergrenze.

Vorschauen. Standardmäßig wird eine Vorschau erzeugt, wenn sie erstmals angefordert wird. Der Benutzer wartet dann innerhalb der Anfrage, die die Vorschau benötigt. Die App Preview Generator verlagert diese Arbeit in einen Cronjob. Dadurch entfällt die Wartezeit, während der CPU-Aufwand bei den Cronjob-Läufen anfällt. In beiden Fällen erzeugt jedes Quellbild mehrere Vorschau-Dateien in unterschiedlichen Größen. Eine Fotosammlung vervielfacht dadurch die Anzahl Ihrer Dateien und verschärft das oben beschriebene Problem mit kleinen Dateien. Bei großen Quellbildern wird außerdem das Speicherlimit erreicht, wie Allowed memory size of 536870912 bytes exhausted im PHP-Fehlerprotokoll zeigt. preview_max_x und preview_max_y verhindern das nicht. Sie legen nur die Größe der größten gespeicherten Vorschau fest. Das Quellbild wird vor der Skalierung auf diese Größe vollständig dekodiert. Die Einstellung, die die Größe der Quelle begrenzt, ist preview_max_memory und hat standardmäßig den Wert 256 MB. Nextcloud liest die Bildabmessungen aus dem Dateikopf, geht von 4 Byte pro Pixel aus und überspringt jedes Bild, das mehr Speicher als das Limit benötigen würde. Statt einer Vorschau wird dann das Standardsymbol für Dateien angezeigt. Nach dieser Berechnung benötigt ein Bild mit 20,000 × 20,000 Pixeln etwa 1.6 GB, unabhängig davon, wie klein Sie die Vorschaugröße festlegen. preview_max_filesize_image hat standardmäßig den Wert 50 MB und ist die entsprechende Begrenzung der Dateigröße. Halten Sie preview_max_memory deutlich unter dem PHP-Limit, anstatt beide Werte dauerhaft zu erhöhen.

Office. Collabora Online und OnlyOffice Docs laufen jeweils als eigener Dienst, üblicherweise in einem separaten Container, mit eigener Laufzeitumgebung und eigenem Speicherbedarf. Dokumentensitzungen benötigen dort CPU und RAM, nicht in PHP. Planen Sie zunächst ein bis zwei Gigabyte ein, damit die Oberfläche reagiert, und prüfen Sie vor der Dimensionierung des Servers die aktuellen Anforderungen des Herstellers mit Stand August 2026. Die beiden Lösungen unterscheiden sich nicht nur beim Ressourcenbedarf. OnlyOffice und Collabora für Self-Hosting beschreibt diese Unterschiede.

Talk. Anrufe werden standardmäßig per WebRTC direkt zwischen den Teilnehmern übertragen. Der Server leitet nur Signalisierungsnachrichten weiter. Die eigenen Administratoreinstellungen von Talk weisen darauf hin, dass Teilnehmer bei Anrufen mit mehr als zwei Personen ohne das High Performance Backend, also ohne einen separaten Signalisierungsserver, sehr wahrscheinlich Verbindungsprobleme und eine hohe Last auf ihren Geräten feststellen. Viele Netzwerke benötigen außerdem einen TURN-Server (Traversal mithilfe von Relays zur Umgehung von NAT), beispielsweise coturn. Bei einer Weiterleitung durch das Relay läuft der Medienverkehr über Ihren VPS. Dadurch wird die Bandbreite zu einem echten Kostenpunkt.

Volltextsuche. Eine Elasticsearch-Instanz benötigt für sich selbst mindestens ein Gigabyte Heap, bevor sie überhaupt Daten indiziert.

Wie viel VPS benötigt Nextcloud?

Eine Dimensionierung allein anhand der Benutzerzahl ist irreführend, weil das Nutzungsverhalten entscheidend ist. Fünf Entwickler, die einen Quellbaum mit 300,000 Dateien synchronisieren, erzeugen mehr Last als dreißig Personen, die Dokumente im Browser öffnen. Verwenden Sie diese Werte als Ausgangspunkt und prüfen Sie sie anhand Ihrer eigenen Dateimengen. Es handelt sich nicht um Messwerte.

• 1 vCPU und 1 bis 2 GB: ein oder zwei Benutzer, nur Dateien und Kalender, Vorschauerzeugung strikt begrenzt, kein Office-Dienst. Upgrades und ein vollständiger Dateiscan sind dann die langsamsten Vorgänge, die auf dem System auftreten.
• 2 vCPU und 4 GB: ungefähr 5 bis 15 regelmäßige Benutzer mit APCu, Redis-Sperren, system cron und durch cron erzeugter Vorschau.
• 4 vCPU und 8 GB: derselbe Benutzerbereich plus ein Office-Dienst oder 15 bis 40 Benutzer mit geringer Last ohne Office-Dienst. Die Office-Sitzungen bestimmen hier den Speicherbedarf.
• 4 oder mehr vCPU und 16 GB: Talk mit dem High Performance Backend, Volltextsuche oder die stapelweise Erzeugung von Vorschauen für eine Fotosammlung.

Der Speicherbedarf muss separat berechnet werden. Vorschauen, Dateiversionen und der Papierkorb kommen zu Ihren eigentlichen Daten hinzu. Sie werden erst kleiner, wenn Hintergrundaufgaben tatsächlich ausgeführt werden. Ob die Gesamtlösung weniger kostet als ein Abonnement, hängt von diesen Werten ab. Ein Vergleich von selbst gehostetem Speicher mit den Dropbox-Preisen führt diese Berechnung durch.

Welche Nextcloud-Einschränkungen sind konfigurationsbedingt, und welche sind architektonisch bedingt

An einem Nachmittag behebbar sind der Memory-Cache und das Redis-Locking, die fehlenden Datenbankindizes, der Modus für Hintergrundaufgaben, die Größe des FPM-Pools und das PHP-Speicherlimit, die OPcache-Größe, notify_push und die Grenzen für Vorschaubilder. Eine Instanz, bei der all das eingerichtet ist, ist auf derselben Hardware eine andere Software als eine Standardinstallation.

Unabhängig von den Einstellungen bleiben:

• Ein Prozess pro Anfrage. Die Parallelität ist durch den RAM begrenzt, und eine langsame Anfrage belegt einen Worker für ihre gesamte Laufzeit.
• Eine Datenbankzeile pro Datei, wobei Größe und Etag an jedes übergeordnete Verzeichnis weitergegeben werden. Der Aufwand steigt mit der Anzahl der Dateien.
• Eine Anfrage pro Datei über das Netzwerk. Die Synchronisierung vieler kleiner Dateien wird durch den Anfrage-Overhead begrenzt, nicht durch die Bandbreite.
• Eine Groupware-Plattform mit einer Dateianwendung darin. Die Grundausstattung enthält Komponenten, die ein reines Synchronisierungstool nie lädt.
• Sequenzielle Upgrades. Hauptversionen werden einzeln im Wartungsmodus eingespielt. Dabei muss die App-Kompatibilität bei jedem Schritt gewährleistet sein.

Nichts davon sind Fehler. Das sind die Kosten für Freigabelinks, externe Mitbearbeiter, mobile Clients und ein gemeinsames Kontensystem für all diese Funktionen. Mit der Enterprise-Edition erhalten Sie Support und einige zusätzliche Apps. Das ändert jedoch nicht das oben beschriebene Anfragemodell. Eines der Themen von dem tatsächlichen Funktionsumfang der kostenlosen Nextcloud-Edition ist genau dieses Modell.

Wer Nextcloud nicht auf einem VPS betreiben sollte

• Sie möchten einen großen Verzeichnisbaum schnell zwischen wenigen Geräten synchronisieren und benötigen nichts weiter. Ein Peer-to-Peer-Tool führt keine Zeile pro Datei in der Datenbank einer Webanwendung. Dadurch unterscheiden sich die Kosten für viele kleine Dateien grundlegend: Syncthing im Vergleich zu Nextcloud für reine Synchronisierung.
• Sie möchten Freigaben und eine Weboberfläche, aber Ihre Daten bestehen aus Millionen kleiner Dateien. Seafile speichert Inhalte in einem Blockspeicher statt in einer Datei pro Datei. Das verändert diese Berechnung. Der Nachteil ist, dass Ihre Daten auf dem Datenträger nicht mehr als gewöhnliche Dateien vorliegen: Seafile im Vergleich zu Nextcloud.
• Sie möchten nur eine Browseransicht der Dateien, die bereits auf dem Server liegen, ohne Synchronisierungs-Client und ohne Datenbankzeilen pro Datei davor. Dafür sind die schlankeren selbst gehosteten Dateimanager gedacht.
• Ihre eigentliche Anforderung ist ein gemeinsam genutztes Laufwerk für vier Personen. Beginnen Sie mit einer schlankeren Lösung und erweitern Sie später: die selbst gehosteten Alternativen zu Nextcloud.
• Sie haben 1 vCPU und 1 GB und möchten browserbasierte Office-Bearbeitung. Diese Kombination passt nicht zusammen. Auch durch noch so viel Tuning lässt sie sich nicht passend machen.

Betreiben Sie Nextcloud, wenn Sie die Groupware-Funktionen benötigen: Freigaben für Personen außerhalb Ihrer Organisation, Kalender und Kontakte auf jedem Telefon, Bearbeitung im Browser und eine gemeinsame Anmeldung für alle Funktionen. Der Fehlerverlauf ist eher ein langsames Nachlassen als ein plötzlicher Ausfall. Die Anzahl der Dateien wächst, die Installation hat weiterhin keinen Cache und keinen Cronjob, und eines Tages benötigt das Öffnen eines Ordners acht Sekunden. All das lässt sich messen. Das meiste davon können Sie beheben, bevor es zum Problem wird.

FAQ

Wie viele Benutzer kann ein Nextcloud-VPS verarbeiten?

Das Verhalten der Installation ist dafür wichtiger als die Benutzerzahl. Ein optimierter Server mit 2 vCPU und 4 GB reicht für etwa 5 bis 15 regelmäßige Benutzer, die Dateien, Kalender und Kontakte verwenden. Wenn Sie einen Office-Dienst hinzufügen, sind normalerweise 8 GB erforderlich. In der Regel erreichen Sie zuerst entweder die Grenze der PHP-Worker im Verhältnis zum verfügbaren RAM oder die Datenbank, sobald oc_filecache umfangreich ist. Testen Sie daher mit Ihren eigenen Dateimengen, bevor Sie sich auf eine Servergröße festlegen.

Warum ist Nextcloud bei vielen kleinen Dateien langsam?

Weil jede Datei einer Datenbankzeile und einer eigenen WebDAV-Anfrage entspricht. Eine Ordnerauflistung ist eine SQL-Abfrage. Beim Schreiben wird die Zeile der Datei aktualisiert, danach die Größe und der Etag jedes übergeordneten Ordners. Bei der Übertragung wird pro HTTP-Anfrage eine Datei verarbeitet, einschließlich Authentifizierung und Initialisierung des Frameworks. Die Kosten hängen daher stärker von der Dateianzahl als von der Gesamtgröße ab. Schneller Speicher reduziert den Festplattenanteil, nicht jedoch den Aufwand pro Anfrage.

Benötige ich Redis für Nextcloud?

Für einen einzelnen Benutzer nicht. Für jede Installation mit mehreren Benutzern ja. Ohne Redis wird die transaktionale Dateisperre über eine Datenbanktabelle umgesetzt. Das erhöht die Schreiblast. Außerdem bleiben nach dem Abbruch einer Anfrage veraltete Sperren zurück, und Benutzer erhalten Meldungen, dass die Datei gesperrt ist. Üblicherweise wird APCu für den lokalen Cache und Redis für die Sperren verwendet. Beide werden in config.php konfiguriert.

Was passiert, wenn ich die Hintergrundaufgaben von Nextcloud nie konfiguriere?

Im standardmäßigen AJAX-Modus wird pro Seitenaufruf eine Aufgabe ausgeführt. Wenn niemand angemeldet ist, läuft daher nichts. Vorschaubilder werden nie vorab erzeugt. Dateiversionen und der Papierkorb laufen nie ab, sodass der Speicherbedarf weiter steigt. Außerdem werden Benachrichtigungs-E-Mails nicht mehr versendet. In der Administratorübersicht wird schließlich angezeigt, dass die letzte Hintergrundaufgabe vor mehreren Stunden ausgeführt wurde und ein Problem vorzuliegen scheint. Wechseln Sie zu system cron mit einem Intervall von fünf Minuten. Bei einer Installation in einem Container wird dies über einen dedizierten cron-Container erledigt.