jean/docu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Doku: Nextcloud Status quo und Optimierungs-Roadmap auf VM 101.

Browse Source 
Nach dem CPU-Incident vom 28.06.2026 Ist-Zustand, notify_push vs. ADA Engine
und priorisierte Server-seitige Tuning-Optionen festhalten.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
root
2026-06-28 09:25:16 +02:00
parent 572168dbdd
commit 28983bb815
3 changed files with 244 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pve1/06_ubuntu-vm-nextcloud.md
+242
View File
@@ -0,0 +1,242 @@
# 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)
```bash
# 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
```bash
# 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)