I’ve been using NixOS for about two years now, and it’s been great!
Something I’ve noticed, as I’ve added more into my configuration.nix file, especially now that my configurations installs: ollama, specialisations for AMD and Nvidia GPUs drivers, a bunch of programs I like to use for Photo/video/audio editing, file management, and DJing, I see that running sudo nixos-rebuild switch --upgrade requires a lot more system resources, notably RAM.
I used to be able to run nixos-rebuild switch with devices of 8GBs of RAM (if you can imagine laptops with soldered 8GBs of RAM, and CPUs with Intel 4th - 6th gen). But these days, I find that my rebuild uses RAM up to 12 GBs, more or less.
When I have insufficient RAM, after a few minutes of running nixos-rebuild switch, konsole will eventually crash.
What causes my systems to use more RAM when it comes to running nixos-rebuild switch? Is there a flag option I can use on the command that would prevent konsole from crashing?
Would increasing my z swapfile help? It’s currently configured to match the system’s physical RAM, but caps out at 8GBs.
Any other suggestions?
top will let you see what processes are consuming ram and swap. If you are running other GUI apps while building NixOS, they may be consuming more than you expect – especially more modern apps.
I’d definitely increase the swap to be at least 120% of ram for any machine configured to sleep or suspend (such as laptops). Typically I configure all my machines for swap at 150% of ram. Swap space is dirt cheap compared to ram, and most of my machines have the max ram possible. The downside is that actually using swap as ram slows the process speed to less than 10%.
If you find that the failure is entirely caused by nixos-rebuild, then maybe you can find what part of the build is taking the most. There could be something wrong in the build process of a single tool, or maybe nix just has too much configuration to think about for the space available. I’d be happy to dig deeper into what’s happening for you, just so that I can learn more about how it all works.
If you have a lot of NixOS specialisations or NixOS containers in your system config (specifically, the containers.* and specialisations.* NixOS options), each one of these requires a full NixOS evaluation, including a new nixpkgs evaluation. I have one system with 2 specialisations and 4 NixOS containers, so that’s 3 (base system and two specialisations) * 4 NixOS containers plus the 3 configs for the base system and specialisations themselves, totally 15 configs in this one system. Frankly it’s a miracle this system’s config can be evaluated with only 16G of RAM I could probably reduce this problem by setting nixpkgs.pkgs in all the child configs so that at least pkgs is shared and nixpkgs isn’t reevaluated, but I haven’t tried this yet.
I’m not using any containers, but I’m using 3 specializations. The specializations are essentially just to use ollama; sometimes I’m using my Linux drive on a AMD device with a AMD GPU, or an Intel with nvidia GPU.
Don’t think you’d quite get to 12G with that. Sounds like you may be evaluating additional nixpkgs instances, perhaps for no particular reason. Do you mix stable/unstable? Do you have statements like import <nixpkgs> { } littered about?
I could probably reduce this problem by setting