nanobot: 2026-09-18 19:16:50

projects/devops/memory.md

@@ -165,3 +165,13 @@ Primární zdroje:
 **Srovnávací kontext Backblaze Drive Stats (Q1 2026 snapshot, primární zdroj backblaze.com):** 341 263 disků, 1 030 poruch, AFR Q1/2026 = 1,24 %; rok 2025 AFR = 1,36 % (115,6M drive-days, 4 317 poruch); lifetime AFR = 1,39 % (529,9M drive-days, 20 212 poruch). Podíl značek: Toshiba 33,93 %, Seagate 33,02 %, WDC 25,30 %, HGST 7,75 %. Dataset open-source, CSV i Apache Iceberg formát (query přes DuckDB/Trino/Snowflake).
 
 Praktický takeaway pro nákup disků do homelabu: HGST už nejde koupit nové (WD brand zrušen), takže reálné pořadí dnešních značek: WD > Seagate ≈ Toshiba, ale Seagate/Toshiba ~2× vyšší poruchovost; nižší teplota a vyšší kapacita pomáhají. Závěry platí pro enterprise disky v datacentru — na konzumerní disky nejsou nutně přenositelné, workload data nejsou k dispozici.
+- 2026-09-18: Pád Proxmox serveru (cca 2026-09-20 večer): celý server přestal náhle fungovat, veškerá snaha o rozběhání selhala. Jediná reakce — pískání speakeru při vyjmutí paměti (RAM sloty/panely paměti zůstaly jediným živým okruhem, zbytek boardu zjevně mrtvý — nebylo možné diagnostikovat dál, root cause boardu neznám).
+
+Náhrada: sehnán **Dell Optiplex 9010** (den po pádu). Podobné CPU, kompatibilní ATX konektor na boardu. Přesun proveden téhož dne: pročistěné/zbavené zdrojů, použita RAM z původního stroje, zapojeny disky i **RTX 4060** — vše funguje. Celý přesun trval přes hodinu, hlavně kvůli problémům s BIOSem, které jsou ještě k dořešení.
+
+Otevřené body po migraci:
+- Sekundární ventilátor — potřebuje doladění
+- BIOS — změny nastavení se **neukládají** (dohledat: CMOS battery / BIOS verze / jumper)
+- Nový **1TB NVMe disk** k instalaci
+- **Proxmox Backup Server** nahodit, aby bylo kam zálohovat — kandidát pivo.hell (Atom stroj)
+- Dlouhodobě: plánování nového HW. Průzkum hotový — dnešní nabídky jsou skříňky 15–20 l, kde za peníze dostane jen víc jader; víc jader uživatel nechce, směr zatím nevyhovuje. Zvažovat alternativy: mini-ITX SFF skříňě, používání Optiplexu jako mezikroku, případně custom build.

projects/devops/state.md

@@ -5,11 +5,12 @@ timestamp: draft
 # Project devops
 
 ## Kde to je
-- Projekt založen jako volný prostor pro admin/root poznámky o infrastruktuře a provozu.
+- **HW základna: Dell Optiplex 9010** (od 2026-09-20). Původní Proxmox server náhle zemřel (večer 2026-09-20, po vyjmutí RAM jen pískání speakeru, board mrtvý, root cause neznám). Do Optiplexu přesunuty RAM, disky i RTX 4060 — vše jede. BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. Původní nvidia.hell incidenty (12.–13. 9.) se týkaly ještě původního stroje.
 - 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 (CMOS battery? verze?); (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.
 - 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.