Node-Agent CPU-Spike: blinder qemu-agent-Ping jeder VM jede Runde + toter Guest-Agent (VM ohne agent) → pvesh-Flut; Agent-Flag/Backoff/Cache + CPU-Cap #38

New issue

Closed

opened 2026-06-02 07:05:06 +00:00 by chinux · 0 comments

chinux commented

2026-06-02 07:05:06 +00:00

Owner

Root Cause (per Live-Analyse einer betroffenen Node verifiziert)

Kein Busy-Loop — eine pvesh/qm-Subprozess-Flut aus dem VM-Identity-Scan, massiv verschärft durch eine VM mit totem qemu-guest-agent.

Befund aus dem Live-Dump (kh-gera):

stime (90 s) ≫ utime (59 s) → Kernel-/Subprozess-lastig, nicht Compute.
identity_scan begin 141×/153 s (~1/s) über VMs 100–105, je mit pvesh/qm-Calls (ping, uname -r, get-osinfo, network-get-interfaces). pvesh = schwergewichtiger Perl-Subprozess → dutzende Spawns/s.
VM 100: qemu-guest-agent läuft nicht → 48× guest-ping ... got timeout; jede Runde 2 timeout-gebundene Calls (pvesh guest-ping → qm-Fallback → identity_scan abort).
Viele frisch gespawnte tokio-rt-worker (Blocking-Pool) mit stark steigenden TIDs, in R → Blocking-Threads stauen sich an timeout-blockierten Calls. Erklärt „nach Neustart paar Stunden Ruhe, dann 100%" (Pool wächst über Stunden).

Code: Node-Agent/src/data.rs:71-86 — der Kommentar gibt es zu: statt der Agent-Flag-Prüfung wird auf jeder laufenden VM blind qemu-agent-ping versucht. data_loop selbst ist sauber serialisiert (spawn_blocking(collect).await), aber collect scannt jede Runde alle (bis 12) laufenden VMs voll, und tote Agents kosten 2 QMP-Timeouts/Runde.

Sofort-Mitigation (Betrieb)

VM mit totem Agent entschärfen: qm set <vmid> --agent 0 oder guest-agent im Gast starten → nimmt die QMP-Timeouts raus.
Live-Drossel ohne Neustart: systemctl set-property --runtime theprox-agent CPUQuota=40%.
scan_interval der Node erhöhen.

Fix (Code)

1. Agent-Flag respektieren statt blind pingen (Kern)

In collect (data.rs) nur VMs scannen, deren PVE-Config agent: 1 hat. Das Flag einmal aus /qemu/<vmid>/config lesen und cachen (es ändert sich praktisch nie) — der im Kommentar „gesparte" Round-trip ist genau die Ursache. VMs ohne Agent-Flag gar nicht erst pingen.

2. Backoff für nicht antwortende Guest-Agents

VMs, deren guest-ping fehlschlägt, mit exponentiellem Cooldown versehen (z. B. nach Fehlschlag N Runden überspringen, Cap z. B. 10 min) statt jede Runde erneut in den Timeout zu laufen. Pro-VM-State im SharedState/AgentState halten.

3. pvesh-Churn senken (Cache)

OS/Kernel/IP je VM cachen und nur selten (z. B. alle paar Minuten) neu via identity_scan holen — pro scan_interval-Tick nur den günstigen ping/Statuscheck, nicht den vollen 4-Call-Scan. Reduziert Perl-Subprozess-Spawns drastisch.

4. QMP-Ping-Timeout kürzen

Den guest-ping-Timeout im Agent kurz halten (z. B. 2–3 s), damit ein toter Agent nicht lange blockiert.

5. Resource-Cap als Defense-in-Depth (ursprünglicher Scope)

CPUQuota/MemoryMax in der systemd-Unit (_make_install_script_rust) — bleibt als Sicherheitsnetz, deckelt jeden künftigen Ausreißer.

6. Backend nicht gegen unerreichbare VMs pollen

Prüfen, ob das Backend (Security/Overview/Modal) vm.scan/qm.agent.* gegen VMs mit totem Agent wiederholt triggert — falls ja, ebenfalls Backoff/Skip.

Akzeptanz

VMs ohne/with totem qemu-guest-agent werden nicht jede Runde voll gescannt; keine QMP-Timeout-Stürme.
pvesh/qm-Spawn-Rate deutlich gesenkt (Cache); CPU bleibt niedrig auch über Tage.
systemd-Cap aktiv.

Branch

fix/agent-scan-backoff-and-cap

## Root Cause (per Live-Analyse einer betroffenen Node verifiziert) Kein Busy-Loop — eine **`pvesh`/`qm`-Subprozess-Flut** aus dem VM-Identity-Scan, massiv verschärft durch eine VM mit totem qemu-guest-agent. **Befund aus dem Live-Dump (kh-gera):** - `stime` (90 s) ≫ `utime` (59 s) → Kernel-/Subprozess-lastig, nicht Compute. - `identity_scan begin` **141×/153 s (~1/s)** über VMs 100–105, je mit `pvesh`/`qm`-Calls (ping, `uname -r`, get-osinfo, network-get-interfaces). `pvesh` = schwergewichtiger Perl-Subprozess → dutzende Spawns/s. - **VM 100: qemu-guest-agent läuft nicht** → 48× `guest-ping ... got timeout`; jede Runde 2 timeout-gebundene Calls (`pvesh guest-ping` → `qm`-Fallback → `identity_scan abort`). - Viele frisch gespawnte `tokio-rt-worker` (Blocking-Pool) mit stark steigenden TIDs, in R → Blocking-Threads stauen sich an timeout-blockierten Calls. Erklärt „nach Neustart paar Stunden Ruhe, dann 100%" (Pool wächst über Stunden). **Code:** `Node-Agent/src/data.rs:71-86` — der Kommentar gibt es zu: *statt der Agent-Flag-Prüfung wird auf **jeder laufenden VM** blind qemu-agent-ping versucht*. `data_loop` selbst ist sauber serialisiert (`spawn_blocking(collect).await`), aber `collect` scannt jede Runde alle (bis 12) laufenden VMs voll, und tote Agents kosten 2 QMP-Timeouts/Runde. ## Sofort-Mitigation (Betrieb) - VM mit totem Agent entschärfen: `qm set <vmid> --agent 0` **oder** guest-agent im Gast starten → nimmt die QMP-Timeouts raus. - Live-Drossel ohne Neustart: `systemctl set-property --runtime theprox-agent CPUQuota=40%`. - `scan_interval` der Node erhöhen. ## Fix (Code) ### 1. Agent-Flag respektieren statt blind pingen (Kern) In `collect` (`data.rs`) nur VMs scannen, deren PVE-Config `agent: 1` hat. Das Flag einmal aus `/qemu/<vmid>/config` lesen und **cachen** (es ändert sich praktisch nie) — der im Kommentar „gesparte" Round-trip ist genau die Ursache. VMs ohne Agent-Flag gar nicht erst pingen. ### 2. Backoff für nicht antwortende Guest-Agents VMs, deren `guest-ping` fehlschlägt, mit **exponentiellem Cooldown** versehen (z. B. nach Fehlschlag N Runden überspringen, Cap z. B. 10 min) statt jede Runde erneut in den Timeout zu laufen. Pro-VM-State im `SharedState`/AgentState halten. ### 3. pvesh-Churn senken (Cache) OS/Kernel/IP je VM cachen und nur selten (z. B. alle paar Minuten) neu via `identity_scan` holen — pro `scan_interval`-Tick nur den günstigen ping/Statuscheck, nicht den vollen 4-Call-Scan. Reduziert Perl-Subprozess-Spawns drastisch. ### 4. QMP-Ping-Timeout kürzen Den guest-ping-Timeout im Agent kurz halten (z. B. 2–3 s), damit ein toter Agent nicht lange blockiert. ### 5. Resource-Cap als Defense-in-Depth (ursprünglicher Scope) `CPUQuota`/`MemoryMax` in der systemd-Unit (`_make_install_script_rust`) — bleibt als Sicherheitsnetz, deckelt jeden künftigen Ausreißer. ### 6. Backend nicht gegen unerreichbare VMs pollen Prüfen, ob das Backend (Security/Overview/Modal) `vm.scan`/`qm.agent.*` gegen VMs mit totem Agent wiederholt triggert — falls ja, ebenfalls Backoff/Skip. ## Akzeptanz - VMs ohne/with totem qemu-guest-agent werden nicht jede Runde voll gescannt; keine QMP-Timeout-Stürme. - `pvesh`/`qm`-Spawn-Rate deutlich gesenkt (Cache); CPU bleibt niedrig auch über Tage. - systemd-Cap aktiv. ## Branch `fix/agent-scan-backoff-and-cap`

chinux changed title from ~~theProx-Node Agent CPU Overhead~~ to Node-Agent CPU-Overhead absichern — systemd CPUQuota/MemoryMax-Limits in der Unit

2026-06-02 07:10:25 +00:00

chinux closed this issue

2026-06-02 08:14:02 +00:00

chinux referenced this issue from a commit

2026-06-02 08:14:03 +00:00

feat(agent): #38 systemd CPU/Memory limits in node-agent unit

chinux changed title from ~~Node-Agent CPU-Overhead absichern — systemd CPUQuota/MemoryMax-Limits in der Unit~~ to Node-Agent CPU-Spike: blinder qemu-agent-Ping jeder VM jede Runde + toter Guest-Agent (VM ohne agent) → pvesh-Flut; Agent-Flag/Backoff/Cache + CPU-Cap

2026-06-02 10:31:40 +00:00

chinux referenced this issue

2026-06-02 10:41:53 +00:00

Agent ignoriert auth_ok.scan_interval beim Connect — Backend-Wert nicht persistent + 30s/300s-Default-Mismatch #44

chinux referenced this issue from a commit

2026-06-02 10:46:51 +00:00

fix(agent): #44 apply auth_ok.scan_interval on connect (persistent) + default 300s

chinux referenced this issue

2026-06-02 13:33:08 +00:00

CI-Pipeline (Gitea Actions) + Tests auf kritischen Agent-/Backend-Pfaden #55

chinux referenced this issue

2026-06-02 13:33:09 +00:00