Nix slowdown handling large files/derivations

There seems to be a problem with how nix handles large files. The two instances I’ve noticed are when doing a “nix copy” to a remote S3 store or when a build produces a large derivation and transfers it from the build environment to the store.

If it was just a matter of large memory usage that would be one thing, but Nix spins 100cpu on a thread for longer than it would take to copy/hash/upload the path. It’s noticeable with few hundred MB, but really bad with several GB. With enough time and memory, eventually the transfer succeeds. I’ve been on relatively recent nixUnstable or nixFlakes.

There is one confirmation here. 1 Can anyone else reproduce this or benchmark a few transfers? My suspicion is that the time needed is super linear. Confirmation and examples will help track down the issue and a fix.

1 Like

Looks like this was a result of compression of the NAR taking longer than expected. This can be alleviated with:

store-uri?parallel-compression=true

or

or store-uri?compression=none

or

store-uri?compression-level=1
(Using the this PR: add support for specifying 'compression-level' for NAR's by dtzWill · Pull Request #2276 · NixOS/nix · GitHub)

or some combination. Can/should parallel compression be default? Or use the -j parameter value by default?

1 Like