nanobot: 2026-09-18 20:22:38
This commit is contained in:
@@ -198,3 +198,10 @@ Otevřené body po migraci:
|
|||||||
- Uživatel si poskládal cenovou sestavu: ASUS TUF GAMING B550-PLUS, AMD Ryzen 7 5700X, Kingston FURY 32GB DDR4 3200 CL16, + chladic + case = **~16 k CZK**
|
- Uživatel si poskládal cenovou sestavu: ASUS TUF GAMING B550-PLUS, AMD Ryzen 7 5700X, Kingston FURY 32GB DDR4 3200 CL16, + chladic + case = **~16 k CZK**
|
||||||
- Verdikt uživatele: výkonově o trochu lepší, jinak vlastně podobné; 16 k se mu utrácet nechce. Novou sestavu zvažoval vícekrát a vždy skončil u toho, že zůstal u současného serveru.
|
- Verdikt uživatele: výkonově o trochu lepší, jinak vlastně podobné; 16 k se mu utrácet nechce. Novou sestavu zvažoval vícekrát a vždy skončil u toho, že zůstal u současného serveru.
|
||||||
- Otevřené téma projektu: kdy (a jestli) přejít na lepší HW — 16 k za marginální upgrade (AM4/DDR4 dead-end platforma) vs. ponechat funkční 9010 a řešit jen ergonomiku otevírání case (vzácná operace) vs. spořit na AM5/výraznější skok. Souvisí s kandidátem HP Z440 z práce (zdarma, ATX workstation, příjemnější práce).
|
- Otevřené téma projektu: kdy (a jestli) přejít na lepší HW — 16 k za marginální upgrade (AM4/DDR4 dead-end platforma) vs. ponechat funkční 9010 a řešit jen ergonomiku otevírání case (vzácná operace) vs. spořit na AM5/výraznější skok. Souvisí s kandidátem HP Z440 z práce (zdarma, ATX workstation, příjemnější práce).
|
||||||
|
- 2026-09-18: Hlavní důvod k obnově HW není výkon ani ergonomie, ale **spolehlivost**: 9010/9020 jsou 15+ let staré stroje, nejsou stavěné na 24/7 provoz, jakým je uživatel provozuje. 9010 je pro současnost dostačující (doladí, poběží, funguje), ale **nic dalšího se do něj už nenacpe** — max ještě tocivý disk. Hlavní strach: až to znovu umře, bude uživatel hodně v prdeli.
|
||||||
|
|
||||||
|
Z toho plyne, že motivace pro novější HW (nebo rychlou záložní cestu) je riziko výpadku hostitele — tedy RTO/RPO, ne výkon:
|
||||||
|
- zkrácení času obnovy (kam zálohy, jak rychle rozběhnout znovu)
|
||||||
|
- nebo prevence: HW stavěný na 24/7
|
||||||
|
|
||||||
|
Otevřené rozhodnutí: novější mašina (AM5?) vs. hot standby (Aukro 9020 deska za 3 k) vs. jen pořádné zálohy + runbook pro rychlou obnovu.
|
||||||
|
|||||||
@@ -5,7 +5,7 @@ timestamp: draft
|
|||||||
# Project devops
|
# Project devops
|
||||||
|
|
||||||
## Kde to je
|
## 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á. Nová sestava (B550-PLUS + Ryzen 7 5700X + 32 GB DDR4 + chladic + case ≈ 16 k) zvažována vícekrát — vždy odložena; je to jen marginální upgrade na dead-end AM4/DDR4. Dlouhodobý kandidát na lepší host: HP Z440 z práce (Xeon E5-1650, 6c/12t, 32 GB, 4 volné sloty), pokud ho dostane z vyřazování; 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 (Xeon E5-1650, 6c/12t, 32 GB, 4 volné sloty), pokud ho dostane z vyřazování; 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í).
|
||||||
- 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.
|
- 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.
|
- 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.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user