`nixos-rebuild switch` padá na nedostatku paměti

Mám VM s NixOS, narážím na problem s vyčerpání paměti, když spustím

sudo nixos-rebuild --flake “.#jupiter” switch

Zatím dělám deploy z jiného stroje, kde je paměti dost, ale chtěl bych, aby byla VM soběstačná. Pokud příkaz pustím brzo po deploy odjinud, proběhne, později sežere i gigabajty RAM.

539944 root 20 0 2048.9m 1.9g 14.0m R 100.3 47.1 0:28.25 nix --extra-experimental-features nix-command flakes eval --raw .#nixosConfigurations.“jupiter”.config.system.build.toplevel.drvPath

než ho sestřelí OOM killer. Zkoušel jsem --max-jobs nebo nastavit --build-host, ale nepomohlo. Google říká, že nejsem jediný, viz třeba Memory usage in eval · Issue #8621 · NixOS/nix · GitHub. Máte-li NixOS, narážíte na to taky? A máte jiné řešení než deploy odjinud?

aktualne deployujeme vpsadminos z masiny se 64G RAM, protoze min to proste nejde (to je overlay nad nixpkgs vicemene, akorat trochu vetsi)…

ja bych na tohle chtel jit z druhe strany - nejaky trvalejsi playground (pro nas NixOSaky :smiley: ale asi to bude mit i dalsi dobry vyuziti), kde by se dalo mit ulozeny data dlouhodobe a naskalovat prostredky, kdyz zrovna potrebuju buildit/kompilovat (kdyz na ty masine jsou, jinak si treba vystat frontu, ze to pak pusti definovany prikaz, napr.)

mne se taky ty deploy joby/kompilace/vubec celkove dirigovani masin, ze maji neco delat, vcelku “prodrazuje”, jak toho ten stack umi cim dal vic… ted jeste LLMka do mixu, takze budem asi muset zacit uz konecne resit nejak GPUcka v datacentru…

chce to nejaky reseni, mno

(a co teprv dalsi architektury, jako ARM64, casem RV64…)

Nix si vezme určitě vždy stejné množství paměti, rozdíl bude spíš v tom, že po čase ti paměť zaberou běžící služby a Nix už nemá tolik prostoru. Jiné řešení než navýšení paměti nebo deploy odjinud aktuálně asi nebude, pokud nehodláš optimalizovat Nix x) Já mám třeba VPS na deploy na stagingu se 4GB paměti a zatím jsem na problém nenarazil, tj. dá se to řešit i za současných podmínek. Zejména když máš těch systémů více, tak je deploy z jednoho místa pohodlnější.

Tolik potřebujeme jen na deploy PXE serveru, jehož konfigurace obsahuje všechny nody a každý má i svou instanci nixpkgs. Tam nix zabere třeba 20GB, zbytek jsou pak mksquashfs :slight_smile:

Já tedy osobně nasazuji odjinud, ale obecně nějaký čas zkoumám možnost osekat si většinu NixOS, tak aby evaluace prostě proběhla rychleji. Na Githubu před časem sdílel Infinisil hodně hacky způsob jak osekat moduly. Obecně je asi cesta nepoužívat všechny moduly, speciálně když dost z nich řeší různé desktopy. Bohužel NixOS je navržený tak, že všechny moduly se zahrnout i když naprostou většinu člověk nepotřebuje.

Může být, vidím, že nixos-rebuild chce skoro přesně tolik, kolik tam bývá volného místa. Stačí málo, aby už neprošel. Zmátlo mě, že okamžitý rebuild vždy projde, ale platí to jen pokud není žádná změna.

Deploy ze stagingu zní jako dobrý nápad. Měření říká, že potřebuju cca 2 GB paměti, to se tam vejde.


||Command being timed: nixos-rebuild switch --flake .|
|---|---|
||User time (seconds): 30.58|
||System time (seconds): 11.78|
||Percent of CPU this job got: 84%|
||Elapsed (wall clock) time (h:mm:ss or m:ss): 0:49.86|
||Average shared text size (kbytes): 0|
||Average unshared data size (kbytes): 0|
||Average stack size (kbytes): 0|
||Average total size (kbytes): 0|
||Maximum resident set size (kbytes): 2248784|
||Average resident set size (kbytes): 0|
||Major (requiring I/O) page faults: 18|
||Minor (reclaiming a frame) page faults: 1547992|
||Voluntary context switches: 5951|
||Involuntary context switches: 581|
||Swaps: 0|
||File system inputs: 487992|
||File system outputs: 13306|
||Socket messages sent: 0|
||Socket messages received: 0|
||Signals delivered: 0|
||Page size (bytes): 4096|
||Exit status: 0|