Analyzing store size growth

Help
1

Over the past years of using nixos the nix store has grown larger and larger despite not really installing much new software and regular garbage collects. The fact that currently, hardlinking saves about 100GiB and that with only having the two newest generations in the store it still occupies 135 GiB has me suspecting that some installed packages carry along different versions of a lot of dependencies.

So how does one go about analyzing this? Is there a tool generating something like a dependency tree explaining why certain things are in the store and can’t be garbage collected? Or is there tooling telling me how “expensive” certain packages are in terms of storage?

2 Likes
2

you are looking probably for nix path-info -rS /run/current-system | sort -nk2

1 Like
3

in my experience GHC hits my store massively with multiple GHC installed at the same time. Ic that i have currently 8.4.4, 8.2.3, 8.2.2, 8.2.1 pulled in.

4

Ok so I see a lot of haskell packages in there with large sizes and three huge packages for idris-1.3.0. Is there a way to tell why they are there (especially why there are three packages for the same idris version)?

5

We should maybe have something like Filelight but for working with Nix store paths and closure sizes.

3 Likes
6

Is it really the same version? I don’t think so. They have different hashes thus implying a different derivation. You can select for each the .drv file and check the differences in nix show-derivation /nix/store/...-idris-1.3.0.drv. A nice tool to see difference is nix-diff

7

The new nix why-depends is the perfect tool !

$ nix why-depends /run/current-system /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27  
/nix/store/nzah6vrpmwr9wxh49pmd544bma6faai7-nixos-system-klatch-19.03.git.53fb6baa88
╚═══bin/switch-to-configuration: …wSystemd = abs_path("/nix/store/091szk41b1hilhw208f4mk6h65r45mnr-systemd-239/lib/systemd/systemd…
    => /nix/store/091szk41b1hilhw208f4mk6h65r45mnr-systemd-239
    ╚═══bin/bootctl: …...................../nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/ld-linux-x86-64.…
        => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27
2 Likes
8

Sometime there are also unused nix-build references in /nix/var/nix/gcroots/auto:

$ ls -la /nix/var/nix/gcroots/auto
lrwxrwxrwx 36 root 19 May 14:55 08ndpqjyrplgzp78273vih4hcbfyjv15 -> /home/joerg/git/ofborg/ofborg/result
lrwxrwxrwx 29 root 27 Nov 11:04 1mabxcaarq9y30nim3hsi3fb8qp7dz3h -> /tmp/nixos-rebuild.6NClfa/nix
lrwxrwxrwx 29 root 27 Nov 12:42 4gl6zbm43imyi0q2aaz54ws1n4919fxz -> /tmp/nixops-tmpL0cdBS/configs
lrwxrwxrwx 29 root 27 Nov 12:43 5vv06wclpmjl3bzzhsrwbjk2fjb7i8cc -> /tmp/nixops-tmpcE2Pm2/configs
lrwxrwxrwx 29 root 27 Nov 11:13 6nk5gx8kln8zqlqim8p2kdj9pxcx322p -> /tmp/nixos-rebuild.Pr59MZ/nix
9

For global full-store analysis, nix-du [1] may be a good helper :slight_smile:

[1] GitHub - symphorien/nix-du: Visualise which gc-roots to delete to free some space in your nix store

1 Like
10

The wiki is pretty clear about all this: Storage optimization - NixOS Wiki

1 Like
11

Thank you all for your help!
I should have searched through the wiki first.
In the end the issue was that I didn’t run the garbage collect as sudo…

3 Likes