Welcher Server für Nextcloud? RAM, CPU und Storage dimensionieren

Nextcloud läuft auf fast jeder Hardware, aber die Grenze zwischen „läuft“ und „läuft unter Last“ verschiebt sich schnell. Die beiden häufigsten Fehldimensionierungen sind zu wenig RAM für die gleichzeitig aktiven PHP-FPM-Worker und ein Datenverzeichnis auf derselben Partition wie das Betriebssystem. Diese Anleitung zeigt dir, wie du RAM, CPU und Storage anhand messbarer Größen planst und die Werte im Betrieb nachprüfst.

Welcher Server eignet sich für Nextcloud?

Ein Server für Nextcloud benötigt pro 10 aktive Nutzer etwa 2 vCPU und 4 GB RAM, mindestens 40 GB SSD für System und Datenbank sowie ein getrennt gemountetes Datenverzeichnis auf SSD- oder NVMe-Backend.

Entscheidend ist dabei nicht die Zahl der angelegten Konten, sondern die Zahl der gleichzeitig synchronisierenden Clients. Ein Desktop-Client erzeugt bei einem größeren Sync-Lauf dutzende parallele Requests, ein Nutzer, der zweimal täglich das Webinterface öffnet, praktisch keine. Rechne mit rund 10 bis 15 Prozent der Konten als gleichzeitig aktiv, bei Teams mit durchgehend laufenden Desktop-Clients eher mit 25 Prozent.

Die Tabelle ist ein Startpunkt, kein Endzustand. Sobald Volltextsuche, Vorschaubilder für Office-Dokumente oder Collabora/OnlyOffice dazukommen, verschiebt sich der Bedarf um eine ganze Zeile nach unten.

Voraussetzungen

• Ein Linux-Host mit Nextcloud 30 oder neuer, sinnvollerweise auf einer skalierbaren Cloud-VM, bei der du vCPU und RAM später ohne Neuinstallation anpassen kannst
• PHP 8.2 bis 8.4 mit PHP-FPM (Nextcloud 30/31 unterstützen diese Versionen; PHP 8.0 und älter werden nicht mehr unterstützt)
• MariaDB 10.6 oder neuer beziehungsweise PostgreSQL 13 oder neuer
• Redis für File-Locking und verteilten Cache, APCu für den lokalen Cache
• Ein Benutzerkonto mit sudo-Rechten

Was bestimmt den RAM-Bedarf bei Nextcloud?

Den RAM-Bedarf bestimmen fast ausschließlich die gleichzeitig laufenden PHP-FPM-Worker, die je nach Aktion 60 bis 120 MB belegen, dazu der InnoDB-Buffer-Pool der Datenbank und die Redis-Instanz.

Nextcloud verlangt ein memory_limit von mindestens 512 MB. Das ist eine Obergrenze pro Request, kein Dauerverbrauch: Ein Worker, der eine Dateiliste ausliefert, bleibt bei 60 bis 80 MB, ein Worker, der ein 40-Megapixel-Bild für die Vorschau skaliert, reizt die 512 MB kurzzeitig aus. Genau deshalb darfst du pm.max_children nicht aus dem memory_limit ableiten, sondern aus dem tatsächlich gemessenen Durchschnitt.

Miss den Durchschnittsverbrauch auf einem laufenden System:

$ ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; n++} END {printf "%d Worker, Durchschnitt %.0f MB\n", n, sum/n/1024}'
12 Worker, Durchschnitt 87 MB

Daraus ergibt sich die Formel für die Worker-Zahl:

# pm.max_children = (RAM_gesamt - OS - Datenbank - Redis) / Durchschnitt pro Worker
# Beispiel 8 GB: (8192 - 1024 - 2048 - 512) / 87 = 52

Plane die Datenbank getrennt ein. Für MariaDB gilt als Richtwert ein innodb_buffer_pool_size in der Größenordnung der Datenbank selbst, gedeckelt auf etwa 25 Prozent des Gesamt-RAM. Die Datenbank wächst mit der Zahl der Dateien, nicht mit deren Volumen: Die Tabelle oc_filecache enthält je Datei eine Zeile, rund eine Million Dateien entsprechen etwa 1 bis 2 GB Datenbankgröße.

CPU dimensionieren

Nextcloud ist selten dauerhaft CPU-gebunden, erzeugt aber deutliche Lastspitzen. Die Verursacher sind gut eingrenzbar:

• Vorschaubilder: Die Generierung ist der mit Abstand teuerste Vorgang. Ohne die App previewgenerator entsteht sie synchron beim ersten Öffnen eines Ordners und blockiert einen Worker.
• Serverseitige Verschlüsselung: Sie kostet je nach Dateigröße 20 bis 40 Prozent zusätzliche CPU-Zeit bei Up- und Download. Aktiviere sie nur, wenn das Storage-Backend nicht vertrauenswürdig ist.
• Cron-Läufe: cron.php alle fünf Minuten führt Aufräumjobs, Ablaufkontrollen und Federation-Sync aus.
• TLS-Terminierung: Bei vielen kleinen Sync-Requests ist der Handshake-Anteil messbar, moderne CPUs mit AES-NI relativieren das aber.

Zwei vCPU sind die untere sinnvolle Grenze, weil sonst ein einzelner Vorschau-Job die Weboberfläche für alle anderen ausbremst. Ab etwa 50 aktiven Nutzern sind vier vCPU der praktikable Standard. Dedizierte statt geteilter Kerne lohnen erst, wenn du Office-Integration oder Volltextsuche mit Elasticsearch auf demselben Host betreibst.

Wie viel Speicherplatz braucht Nextcloud pro Nutzer?

Nextcloud belegt pro Nutzer etwa das 1,5- bis 2-fache der reinen Nutzdaten, weil Dateiversionen, der Papierkorb mit 30 Tagen Standardaufbewahrung und die Vorschaubilder zusätzlichen Platz im Datenverzeichnis beanspruchen.

Eine Nutzerquota von 50 GB bedeutet also real 75 bis 100 GB Plattenbedarf. Die Vorschaubilder liegen unter <datadir>/appdata_*/preview/ und erreichen bei bildlastigen Beständen 10 bis 20 Prozent des Nutzdatenvolumens. Prüfe die Verteilung direkt:

$ sudo du -sh /var/nextcloud/data/*
$ sudo du -sh /var/nextcloud/data/appdata_ocxyz/preview

Wichtiger als die Kapazität ist das Layout. Lege das Datenverzeichnis auf ein eigenes Volume, nicht auf die Systempartition. Läuft / voll, stoppt nicht nur Nextcloud, sondern auch die Datenbank, und MariaDB kann dabei ein unsauberes Recovery erzwingen. Ein getrenntes Volume lässt sich zudem unabhängig vergrößern und separat sichern.

$ lsblk -o NAME,SIZE,MOUNTPOINT,ROTA
$ df -h /var/nextcloud/data

Beim Backend zählen IOPS mehr als Durchsatz. Ein Sync-Lauf mit 5.000 kleinen Dateien erzeugt zehntausende Metadaten-Operationen. HDD-Backends sind für das Datenverzeichnis nur bei reinen Archivbeständen sinnvoll, Datenbank und Systemplatte gehören in jedem Fall auf SSD oder NVMe. Für kalte Bestände bindest du besser externen Speicher als eigenen Mount ein, statt das primäre Volume immer weiter zu vergrößern.

graph TD
    A["Aktive Nutzer und Datenvolumen erfassen"] --> B{"Mehr als 50 aktive Nutzer?"}
    B -- Nein --> C["4 GB RAM, 2 vCPU, APCu als lokaler Cache"]
    B -- Ja --> D{"Vorschaubilder und Volltextsuche aktiv?"}
    D -- Nein --> E["8 GB RAM, 4 vCPU, Redis für File-Locking"]
    D -- Ja --> F["16 GB RAM, 8 vCPU, Redis plus getrennte Datenbank"]
    C --> G["Datenverzeichnis separat mounten"]
    E --> G
    F --> G
    G --> H{"Belegung über 70 Prozent?"}
    H -- Ja --> I["Volume vergrößern oder externen Speicher anbinden"]
    H -- Nein --> J["Monatlich prüfen"]

Konfiguration an die Größe anpassen

Trage die berechneten Werte ein, statt die Distributions-Standards zu übernehmen. Die Vorgabe von pm.max_children = 5 aus dem Debian-Paket reicht für keine ernsthafte Installation.

; /etc/php/8.3/fpm/pool.d/nextcloud.conf
[nextcloud]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm-nextcloud.sock
pm = dynamic
pm.max_children = 52
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 20
pm.max_requests = 500
php_admin_value[memory_limit] = 512M

Der OPcache ist bei Nextcloud kein optionaler Feinschliff, weil die Codebasis mehrere zehntausend PHP-Dateien umfasst:

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable = 1
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 10000
opcache.memory_consumption = 256
opcache.save_comments = 1
opcache.revalidate_freq = 60

In der config.php gehören der lokale Cache und das verteilte File-Locking gesetzt. Ohne Redis serialisiert Nextcloud die Sperren über die Datenbank, was ab etwa 20 parallelen Clients zur Bremse wird:

<?php
// /var/www/nextcloud/config/config.php (Auszug)
'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => ['host' => '/run/redis/redis-server.sock', 'port' => 0],
'preview_max_x' => 2048,
'preview_max_y' => 2048,

Für MariaDB setzt du den Buffer-Pool passend zur Datenbankgröße:

; /etc/mysql/mariadb.conf.d/60-nextcloud.cnf
[mysqld]
innodb_buffer_pool_size = 2G
innodb_io_capacity = 2000
transaction_isolation = READ-COMMITTED
max_connections = 100

Halte max_connections in der Nähe von pm.max_children plus Reserve für Cron und Wartungsjobs. Deutlich höhere Werte reservieren nur Speicher, den die Worker nie abrufen.

Verifikation

Prüfe nach dem Neustart der Dienste, ob die Installation sauber läuft und die Grenzwerte greifen:

$ sudo systemctl restart php8.3-fpm mariadb
$ sudo -u www-data php /var/www/nextcloud/occ status
  - installed: true
  - version: 30.0.4.1
  - maintenance: false
$ sudo -u www-data php /var/www/nextcloud/occ config:system:get memcache.locking
\OC\Memcache\Redis

Beobachte anschließend das Verhalten unter realer Last. Interessant sind drei Werte: die Zahl der belegten Worker, die Swap-Nutzung und die Wartezeit auf I/O.

$ vmstat 5 6
$ free -h
$ sudo grep 'max_children' /var/log/php8.3-fpm.log

Erscheint in vmstat dauerhaft eine wa-Spalte über 10, limitiert das Storage. Wächst si/so über Null, ist der RAM zu knapp bemessen oder der Buffer-Pool zu groß. Bleibt die Zeile server reached pm.max_children setting im FPM-Log aus, passt die Worker-Zahl.

Troubleshooting

504 Gateway Timeout beim Sync: Im FPM-Log steht server reached pm.max_children setting. Alle Worker sind belegt, neue Requests warten in der Queue. Erhöhe pm.max_children, sofern der RAM es nach obiger Formel hergibt, sonst zuerst den RAM.

„Allowed memory size exhausted“ bei Vorschaubildern: Das memory_limit liegt unter 512 MB oder ein Bild ist zu groß. Setze das Limit auf 512M und begrenze preview_max_x/preview_max_y auf 2048. Generiere Vorschauen vorab per Cron statt beim ersten Zugriff.

System swappt trotz freiem RAM in top: innodb_buffer_pool_size plus pm.max_children mal Worker-Größe überschreiten den physischen Speicher. Beide Werte konkurrieren, rechne sie gemeinsam.

Weboberfläche langsam bei niedriger CPU-Last: Meist fehlen Datenbankindizes nach einem Upgrade. Prüfe und ergänze sie mit sudo -u www-data php occ db:add-missing-indices.

Fazit

Die Dimensionierung eines Nextcloud-Servers steht und fällt mit drei Zahlen: dem gemessenen RAM-Verbrauch pro PHP-FPM-Worker, der Zahl gleichzeitig aktiver Clients und dem Faktor 1,5 bis 2 zwischen Nutzdaten und tatsächlichem Plattenbedarf. Beginne mit 4 vCPU und 8 GB RAM für Teams bis 50 Nutzer, lege das Datenverzeichnis von Anfang an auf ein eigenes Volume und kontrolliere vmstat sowie das FPM-Log nach den ersten Wochen produktiver Nutzung. Passt dort alles, skalierst du erst, wenn die Messwerte es verlangen.

Weiterlesen

• Nextcloud aktualisieren: Updater, occ und Rollback-Plan
• Nextcloud All-in-One mit Docker installieren
• Nextcloud auf Ubuntu 24.04 mit nginx installieren
• Nextcloud sichern und wiederherstellen: Daten, Datenbank, Config
• Nextcloud mit Docker Compose betreiben
• Nextcloud Office einrichten: Collabora oder OnlyOffice
• Nextcloud, ownCloud oder Seafile: Welche Lösung wofür?
• Nextcloud per WebDAV einbinden: Linux, Windows, macOS
• Was ist Nextcloud? Funktionsweise, Komponenten und Einsatz