nanobot: 2026-09-20 20:02:41

2026-09-20 20:02:42 +02:00
parent facc7814f6
commit 977a894cc8
7 changed files with 86 additions and 232 deletions
--- a/projects/devops/state.md
+++ b/projects/devops/state.md
@@ -5,12 +5,12 @@ timestamp: draft
 # Project devops

 ## Kde to je
- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní server — **Dell Optiplex 9020** workstation z raných dob RSJ, dlouholetý server (měněny zdroj/kabely/větrák, přidána RTX 4060 (deník: 4060 Ti — neověřeno) + hromada disků) — náhle zemřel (večer 2026-09-17, po vyjmutí RAM pípání chybových kódů; podezření CPU/DDR/deska). Proměřitelná hypotéza: AliExpress kabel zdroj→deska (odcházející měnič). Do 9010 přesunuty RAM, disky i GPU — vše jede; BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. **Ergonomie 9010 je špatná**: stísněný case, grafika na krev, druhý NVme jen přes placatou PCIe redukci (slot pod grafikou); 550 W noční zdroj dává rezervu, ale práce s mašinou je nepříjemná. **Kapacita vyčerpaná: nic dalšího se do 9010 už nenacpe, max tocivý disk.** Hlavní riziko: 15+ let starý HW nedělany na 24/7 provoz → motivace pro novější HW je spolehlivost (RTO/RPO), ne výkon. Nová sestava (B550-PLUS + Ryzen 7 5700X + 32 GB DDR4 + chladic + case ≈ 16 k) zvažována vícekrát — vždy odložena; marginální upgrade na dead-end AM4/DDR4. Dlouhodobý kandidát na lepší host: ~~HP Z440 z práce~~ — padlo, z práce dostal právě ten 9010 (místo Z440); hot-spare zatím bez konkrétního kandidáta, levná opce zůstává Aukro deska 9020 (~3 k, po proměření kabelu). Zvažováno i vlastní PC z chlívku jako Proxmox host + Windows VM přes RDP. Vyřčená lekce: zálohovat kontejnery z Proxmoxu (nemá se kam — PBS chybí).
+- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní server — **Dell Optiplex 9020** workstation z raných dob RSJ, dlouholetý server (měněny zdroj/kabely/větrák, přidána RTX 4060 (deník: 4060 Ti — neověřeno) + hromada disků) — náhle zemřel (večer 2026-09-17, po vyjmutí RAM pípání chybových kódů; podezření CPU/DDR/deska). Proměřitelná hypotéza: AliExpress kabel zdroj→deska (odcházející měnič). Do 9010 přesunuty RAM, disky i GPU — vše jede; BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. **Ergonomie 9010 je špatná**: stísněný case, grafika na krev, druhý NVme jen přes placatou PCIe redukci (slot pod grafikou); 550 W noční zdroj dává rezervu, ale práce s mašinou je nepříjemná. **Kapacita vyčerpaná: nic dalšího se do 9010 už nenacpe, max tocivý disk.** Hlavní riziko: 15+ let starý HW nedělany na 24/7 provoz → motivace pro novější HW je spolehlivost (RTO/RPO), ne výkon. Nová sestava (B550-PLUS + Ryzen 7 5700X + 32 GB DDR4 + chladic + case ≈ 16 k) zvažována vícekrát — vždy odložena; marginální upgrade na dead-end AM4/DDR4. Dlouhodobý kandidát na lepší host: ~~HP Z440 z práce~~ — padlo, z práce dostal právě ten 9010 (místo Z440); hot-spare zatím bez konkrétního kandidáta, levná opce zůstává Aukro deska 9020 (~3 k, po proměření kabelu). Zvažováno i vlastní PC z chlívku jako Proxmox host + Windows VM přes RDP — **zavrženo 2026-09-20** (přestěhování Windows není pohoda jako u Linuxu; chybí rozumný HW, který by unesl uživatelovu práci i hry; pro server se sežene jiná mašina). Vyřčená lekce: zálohovat kontejnery z Proxmoxu (nemá se kam — PBS chybí).
 - LibreChat: běží jako podman kontejnery; jako Code Interpreter sandbox vybrán LibreCodeInterpreter (nsjail, 3 kontejnery). Research hotový (2026-09-13), rozhodnutí o nasazení (sdílená Docker VM vs dedikovaná Proxmox VM) ještě nepadlo.
 - Ollama na nvidia.hell: po incidentech 12.–13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen `nr_foll_pin` delta v /proc/vmstat), uvolní **jen reboot** (rmmod driveru ověřeně NE). Cgroup pojistka (`MemoryMax=6G`, `MemorySwapMax=0`, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v `artifacts/2026-09-13_ollama-nvidia-full-report.md` (ucelený, s kuchařkou pro triáž) a `artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (`balloon: 0` + pevná paměť), rmmod jako remedy.

 ## Co dál
- **HW po migraci na Optiplex 9010 (aktuální fronta):** (1) ~~BIOS — neukládající se změny~~ — root cause nalezen 2026-09-19: vyndaný PSWD jumper drží desku v ochranném režimu; fix: nasadit jumper zpět na oba piny PSWD, nastavit hodnoty v BIOSu, uložit, ověřit persistenci (postup v memory.md 2026-09-19); (2) doladit sekundární vetrak; (3) instalovat nový 1TB NVme; (4) nahodit Proxmox Backup Server — kandidát pivo.hell (Atom), aby bylo kam zálohovat; (5) dlouhodobě plán nového HW — průzkum ukázal 15–20 l skříňky s převahou jader, což nevyhovuje (uživatel nechce víc jader); zvažovat mini-ITX SFF, Optiplex jako mezikrok, custom build.
+- **HW po migraci na Optiplex 9010 (aktuální fronta):** (1) ~~BIOS — neukládající se změny~~ — root cause nalezen 2026-09-19: vyndaný PSWD jumper drží desku v ochranném režimu; fix: nasadit jumper zpět na oba piny PSWD, nastavit hodnoty v BIOSu, uložit, ověřit persistenci (postup v memory.md 2026-09-19); (2) doladit sekundární vetrak — zjištěno 2026-09-20: žádná Linux podpora, BIOS to taky neresí (jede naplno nebo vůbec), jediné řešení je USB radič (uživatel: „aspoň za litr"); (3) instalovat nový 1TB NVme; (4) nahodit Proxmox Backup Server — kandidát pivo.hell (Atom), aby bylo kam zálohovat; (5) dlouhodobě plán nového HW — průzkum ukázal 15–20 l skříňky s převahou jader, což nevyhovuje (uživatel nechce víc jader); zvažovat mini-ITX SFF, Optiplex jako mezikrok, custom build.
 - Rozhodnout umístění LibreCodeInterpreter (AI stack VM vs dedikovaná VM) a nasadit — viz memory.md 2026-09-13 pro capability požadavky (SYS_ADMIN, NET_ADMIN, apparmor:unconfined).
 - Ollama open body dle priority (report §11): (1) ~~zastavit dávky z nanobot.hell~~ — **neplatí jako provozní riziko** (dávky byly testovací tool-calling requesty, běžný provoz nanobot nesahá na lokální modely); (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem; kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, dmesg constraint=MEMCG); (3) doladit MemoryMax podle memory.peak; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) `OLLAMA_KV_CACHE_TYPE=q4_0` zrušit nebo nepoužívat granite-code; (6) drobnosti: `apt purge` earlyoom (rc), llama-server `--log-verbosity 4`, zabbix `Hostname=Zabbix server` → nvidia, LibreChat titleConvo duplicitní requesty, otázka real-time monitoringu (hlídač co killuje = zavržená cesta).
 - Návrh k rozhodnutí: izolovat embedding pipeline (wiki skill) ze ollamy na statický llama.cpp server (`llama-server --embeddings --pooling last`, stejný GGUF, /v1/embeddings) — obejde load path, kde vzniká leak; po ní nanobot nezůstane na lokální ollamě žádný provoz krom cloud proxy. Vyžaduje: úprava wiki_embed.py klienta, config.yaml endpoint, reindex --full.