docu/pve1/06_ubuntu-vm-nextcloud.md

VM 101 (ubuntu) — Nextcloud Status & Optimierung

Stand: 2026-06-28
Host: pve1 · VMID: 101 · IP: 192.168.10.10
URL: https://cloud.jeanavril.com

Diese Seite dokumentiert den Ist-Zustand nach dem CPU-Incident am 28.06.2026 und sammelt Optimierungsoptionen zur eigenen Recherche. Client-Updates sind hilfreich, aber nicht Voraussetzung für eine stabile Server-Seite.

---

Architektur (Kurz)

pve1 (192.168.10.5)
  └── VM 101 ubuntu (4 vCPU, 8 GB RAM, 192.168.10.10)
        ├── Docker: nextcloud          → 10.2.2.253 (docbr0)
        ├── Docker: nextcloud-db-1     (MariaDB)
        ├── Docker: nextcloud-redis-1  (Redis Alpine)
        ├── Docker: collabora
        ├── Docker: npm-app-1          → Reverse Proxy 10.2.2.254
        └── … weitere Stacks (Gitea, Airsonic, Vaultwarden, …)

Daten:
  /mnt/nextcloud-data  ←  NFS von pve1/CT files
  192.168.10.5:/mnt/storage/service_data/cloud/data  (mergerfs-Pool, ~99 TB, ~95 % belegt)
  im Container:         /data

Stack-Pfad auf der VM:  /opt/stacks/nextcloud/
Compose:                /opt/stacks/nextcloud/compose.yml
Nextcloud-Config:       /opt/stacks/nextcloud/config/www/nextcloud/config/config.php
Image:                  lscr.io/linuxserver/nextcloud:latest (NC 34.0.0.12)

---

Incident 2026-06-28 (CPU 100 %)

Symptome

Ebene	Beobachtung
Proxmox-Host	KVM VM 101 ~400 % CPU, Load ~4
In der VM	Load ~17 bei 4 Kernen
Container nextcloud	~398 % CPU
PHP-FPM	5/5 Worker (pm.max_children = 5) seit 2–5 Stunden bei 100 % CPU
Nginx	massenhaft 504 Gateway Timeout an Clients
Clients	Desktop (mirall) + Android pollten index.php/204, status.php, WebDAV-PROPFIND

Sofortmaßnahme (erledigt)

# auf pve1 oder per Guest Agent:
qm guest exec 101 -- docker restart nextcloud

→ CPU sofort normal (~0 %), frische PHP-FPM-Prozesse.

Wahrscheinliche Ursache (Server-seitig)

Die Worker hingen im OCS/WebDAV-Pfad (cwd: /app/www/public/ocs), nicht in MariaDB oder Redis. Kombination aus:

1. Zu wenig PHP-FPM-Slots (5) — bei parallelen Sync-/WebDAV-Requests sofort erschöpft
2. Kein Push-Backend — Clients müssen aktiv pollen statt Updates zu empfangen
3. Sehr großer NFS-Datenbestand (~93 TB) — Metadaten-/Scan-Operationen können PHP-Worker lange binden
4. Kein Request-Timeout auf PHP-FPM-Ebene sichtbar — Worker können theoretisch unbegrenzt laufen

Client-Versionen (z. B. altes mirall 3.0.3) verstärken die Last durch häufigeres Polling, sind aber nicht die alleinige Ursache.

---

Ist-Zustand Konfiguration

Bereits korrekt / aktiv

Bereich	Status	Details
Redis (Distributed Cache)	✅	memcache.distributed + memcache.locking → Redis
APCu (Local Cache)	✅	memcache.local → APCu
Transactional File Locking	✅	filelocking.enabled = true, Locking via Redis
PHP-Module	✅	redis, apcu, Zend OPcache geladen
OPcache	✅	enabled, 128 MB
Datenbank	✅	MariaDB im Compose-Stack (db Host)
Reverse Proxy	✅	NPM (10.2.2.254), trusted_proxies gesetzt

→ Der Linuxserver-Container-Hinweis beim Start („Redis konfigurieren …“) ist veraltet/irreführend — Redis ist in config.php eingetragen.

Engpässe / fehlend

Bereich	Status	Auswirkung
notify_push (Rust HPB)	❌ nicht installiert	Clients pollen weiterhin aggressiv
PHP-FPM pm.max_children	⚠️ 5 (Default)	Bei wenigen gleichzeitigen Requests sofort ausgelastet
APCu apc.shm_size	⚠️ 32 MB	Nextcloud empfiehlt ≥ 128 MB
request_terminate_timeout	❌ nicht gesetzt	Hängende Worker blockieren Slots dauerhaft
Separates Redis für notify_push	❌	Optional, erst relevant mit HPB
Preview-/Scan-Jobs	❓ ungeprüft	Bei 93 TB NFS potenziell sehr teuer

PHP-FPM (Container-Default)

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Anpassbar über Linuxserver-Pfad (persistent):

/opt/stacks/nextcloud/config/php/www2.conf   → gemountet nach /etc/php84/php-fpm.d/www.conf

(Die genaue php-Version im Container bei Image-Update prüfen.)

---

Rust „Engine“ — was ist das?

Es gibt zwei verschiedene Rust-Themen; oft verwechselt:

1. notify_push — High Performance Backend für Files (jetzt umsetzbar)

Was	Rust-Daemon + Nextcloud-App, hält WebSocket-Verbindungen zu Desktop-/Web-Clients offen
Problem das es löst	Clients fragen sonst alle paar Sekunden index.php/204 / status.php ab → PHP-FPM-Last
Repo	https://github.com/nextcloud/notify_push
Lizenz	AGPL, kostenlos (nicht Enterprise-only)
Aktuell	App nicht in der App-Liste installiert
Voraussetzungen	Redis (✅ vorhanden), Reverse-Proxy-Weiterleitung für Push-Port, passende Binary-Version zur App

Relevanz für uns: Sehr hoch — adressiert direkt das Polling-Problem (index.php/204, status.php), unabhängig von Client-Version.

Konfiguration laut Doku:

• App installieren + Rust-Binary (notify_push-x86_64-unknown-linux-musl) als Sidecar oder im Container
• Proxy-Pfad z. B. /push → Push-Daemon
• Optional: separates Redis (notify_push_redis in config.php) für Pub/Sub-Traffic

Aktuelle Releases: v1.3.x (2026), u. a. Fixes gegen DB-Query-Spitzen bei Cache-Invalidierung.

2. ADA Engine — Accelerated Direct Access (Zukunft / Hub 26+)

Was	Architektur-Rewrite in PHP, Go und Rust für Skalierung großer Instanzen
Ankündigung	Nextcloud Blog, Feb 2026 — „Hub 26 Winter“
Kernideen	File-Cache-Sharding, vorberechnete Berechtigungen, direkte Downloads (S3), Push von Änderungslisten an Clients
HPB Files v2.0	Rust-Komponente: verteilt Benachrichtigungen über ein Zeitintervall, sendet betroffene Dateilisten
Aktuell bei uns	NC 34.0.0 — ADA/Hub-26-Features noch nicht verfügbar
Aktion	Beobachten beim Upgrade auf Hub 26; kein separates „Install ADA“-Paket heute

Fazit: Für die aktuelle Instanz ist notify_push der relevante Rust-Schritt. ADA kommt mit einem größeren Major-Upgrade.

---

Optimierungs-Roadmap (Recherche & Priorität)

Priorität 1 — schnell, hoher Effekt

1. PHP-FPM Limits anheben

   • pm.max_children z. B. 10–15 (abhängig von RAM: ~100 MB/Worker)
   • request_terminate_timeout = 300 (oder 600) — verhindert ewig hängende Worker
   • ggf. pm.max_requests = 500 — Worker regelmäßig recyclen

2. notify_push evaluieren & deployen

   • App installieren, Binary + Proxy-Route
   • Test: occ notify_push:setup / Self-Test-Tools aus dem Repo
   • Erwartung: deutlich weniger index.php/204-Traffic in Nginx-Logs

3. APCu vergrößern

   • apc.shm_size von 32 MB → 128 MB (Custom-PHP-Ini im Linuxserver-Config-Volume)

Priorität 2 — mittelfristig

4. Background-Jobs auf System-Cron

   • Modus cron + crontab auf VM (alle 5 min):
     docker exec -u abc nextcloud php /app/www/public/occ background:cron
   • Entlastet Web-Requests von AJAX-Cron

5. NFS / Datenbestand

   • 95 % Pool-Auslastung im Blick behalten
   • occ files:scan nur gezielt, nicht pauschal auf 93 TB
   • Prüfen ob laufende Scans/Previews Worker blockieren (occ files:scan --status)

6. Nginx FastCGI-Timeouts

   • fastcgi_read_timeout im Linuxserver site-conf falls 504 bei langen, legitimen Requests

Priorität 3 — beim nächsten Major-Upgrade

7. Upgrade auf Hub 26 (NC 26) — ADA Engine, File-Cache-Splitting, HPB v2
8. Preview-Strategie — Hub 26 trennt Preview-Metadaten aus File-Cache (bis ~56 % kleiner)

Optional / Client-seitig (nicht zwingend)

• Desktop-Client aktualisieren (weniger fehlerhaftes Verhalten, bessere Push-Unterstützung mit HPB)
• Altes mirall 3.0.3 (User jutta) besonders aggressiv — Update reduziert Last, ist aber kein Muss wenn HPB + FPM stimmen

---

Nützliche Befehle

# Von pve1 — Status in der VM
qm guest exec 101 -- docker stats nextcloud --no-stream
qm guest exec 101 -- docker exec -u abc nextcloud php /app/www/public/occ status
qm guest exec 101 -- docker exec -u abc nextcloud php /app/www/public/occ app:list | grep notify

# PHP-FPM / Logs
qm guest exec 101 -- docker exec nextcloud ps aux | grep php-fpm
qm guest exec 101 -- docker exec nextcloud tail -30 /config/log/php/error.log
qm guest exec 101 -- docker exec nextcloud tail -30 /config/log/nginx/access.log

# Container neu starten (Notfall)
qm guest exec 101 -- docker restart nextcloud

# Stack bearbeiten (auf der VM)
ssh root@192.168.10.10
cd /opt/stacks/nextcloud && docker compose ps

---

Referenzen

Thema	URL
Memory caching (Redis/APCu)	https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html
notify_push GitHub	https://github.com/nextcloud/notify_push
ADA Engine Blog	https://nextcloud.com/blog/a-new-data-access-architecture-for-nextcloud-introducing-the-ada-engine/
Linuxserver Nextcloud	https://docs.linuxserver.io/images/docker-nextcloud

---

Offene Punkte / TODO (Betreiber)

• PHP-FPM www2.conf anpassen und Container restart
• notify_push PoC (App + Binary + NPM-Route)
• apc.shm_size auf 128 MB
• System-Cron für occ background:cron einrichten
• Nach Änderungen: Nginx-Access-Log auf Polling-Frequenz prüfen
• Hub-26-Upgrade planen (ADA)