-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nix 2.0: nix copy stalls #1988
Comments
It would probably be nice if you could test with the latest master branch as Eelco did some tweaks to reduce memory consumption afaik (48662d1). |
Hi @AmineChikhaoui, I'm trying to do that. I think the manual is out of date - it says the first build step is to run |
I generally override the nix package in my configuration.nix e.g of an old setup (you need to pull the latest revision/checksum):
|
Added this to my package overrides:
This is the build result:
|
It does seem like memory may be relevant. This is what I get when I try to build
Do I read this correctly, is Nix somehow running of memory while merely trying to download a file? |
I may have a similar problem: with nix 2.0 simply adding |
Although it does so happen that |
Since upgrading to Nix 2.0, I am also having this problem trying to copy GHC to a BeagleBone Black, which has only 512MiB of RAM. I bumped swap on the host to 1GiB, and even that wasn't sufficient. |
Workaround: I have gone back to using |
@chris-martin FYI, |
I created a swap just for this and even with 4,5 Go available (returnd by
`free`), I couldn't deploy qemu on 2 nixops VM, maybe I should try one VM
at a time.
2018-03-22 10:02 GMT+09:00 Drew Hess <[email protected]>:
… @chris-martin <https://github.com/chris-martin> FYI, nix-copy-closure
from Nix 2.0 is what I was using when I had my issues. I had to bump swap
to 2GiB just to copy the ghc-8.0.2 closure alone.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1988 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA2FOq3czU6LW8nw8_-tlKcoO8fTFwWzks5tgvg3gaJpZM4SvgPP>
.
|
Strongly recommend using latest Nix (git), which has huge improvements regarding memory usage. (if you're still unstable to make your override work, LMK) |
@dtzWill Yes, the nixUnstable build is still broken. This is the latest
|
Okay, well that's a bummer. Looks like there's no convenient If you don't set Not quite as clean as an override but works for me and hopefully helps. EDIT: grafting bits into an override works, but eep: https://gist.github.com/dtzWill/d3fb86978f8fb8dcb3a8f726d7db0522 |
Where'd this come from? 😁 |
Oh, right, |
I've tried the overcommit memory, GC_INITIAL_HEAP_SIZE=128k, installed master nix and even with 5GB of free memory I still have:
I am really looking forward for a fix. |
I have the same issue, nixops fails to copy closures to 2G RAM VPS:
Overcommit flag suppresses out of memory error but it still fails. |
Previously, CI used `nixos/nix` without a tag. 7 hours ago, a `2.0` release was pushed to Docker Hub: https://hub.docker.com/r/nixos/nix/tags/ Unfortunately, that seems to trigger a bug when copying the "ghc" package; see discussion in tweag#239. Resolved for now by fixing the Linux build to a specific docker tag. Not sure about the corresponding macOS failures. We should separately investigate the issues with nix-2; they may be related to: NixOS/nix#1988
Looks like this is totally breaking I can no longer deploy to AWS machines which even have 4 GB ram. Once (Specifically this happens for How would we even go about fixing this for nixops? When an AWS machine boots up, we have little control over what nix version is running on the other side (it's defined by the image, which even with 18.03 doesn't have a nix that takes less memory). |
I'd also like to know why it crashes at 50%, maybe I could at least make that 90% of the 4 GB for a higher chance of success? |
I have a workaround: Deploy my EC2 instance with a 17.09 base image. For that purpose, I added an option to https://github.com/NixOS/nixops/compare/v1.6...nh2:nixosAmiVersion-v1.6?expand=1 |
Fixes `error: out of memory` of `nix-store --serve --write` when receiving packages via SSH (and perhaps other sources). See NixOS#1681 NixOS#1969 NixOS#1988 NixOS/nixpkgs#38808. Performance improvement on `nix-store --import` of a 2.2 GB cudatoolkit closure: When the store path already exists: Before: 10.82user 2.66system 0:20.14elapsed 66%CPU (0avgtext+0avgdata 12556maxresident)k After: 11.43user 2.94system 0:16.71elapsed 86%CPU (0avgtext+0avgdata 4204664maxresident)k When the store path doesn't yet exist (after `nix-store --delete`): Before: 11.15user 2.09system 0:13.26elapsed 99%CPU (0avgtext+0avgdata 4204732maxresident)k After: 5.27user 1.48system 0:06.80elapsed 99%CPU (0avgtext+0avgdata 12032maxresident)k The reduction is 4200 MB -> 12 MB RAM usage, and it also takes less time.
I think we might potentially have two different problems here.
I have the (1), but not the (2), and in my case this was due to SSH itself stalling, so I don't think Nix is at fault in my case. So, for the record:
UPDATE: so this was traced down to MTU issues -- AWS DHCP sometimes advertises MTU of 9001, and it needs to be configured to 1500 in some cases -- and sometimes even for VPC-internal traffic. Go figure.. |
It adds a new operation, cmdAddToStoreNar, that does the same thing as the corresponding nix-daemon operation, i.e. call addToStore(). This replaces cmdImportPaths, which has the major issue that it sends the NAR first and the store path second, thus requiring us to store the incoming NAR either in memory or on disk until we decide what to do with it. For example, this reduces the memory usage of $ nix copy --to 'ssh://localhost?remote-store=/tmp/nix' /nix/store/95cwv4q54dc6giaqv6q6p4r02ia2km35-blender-2.79 from 267 MiB to 12 MiB. Probably fixes NixOS#1988. (cherry picked from commit 2825e05)
just wanted to mention that I had a similar problem with nixops libvirtd, one of my bridge had an mtu of 9000 and not sure where the fault lies but nix-copy-closure was stuck until it eventually timed out. Setting a more common mtu of 1400 fixed it. |
I encountered the similar issue as @teto mentioned when using OVS bridge with nixops libvirtd. But I think mtu issue is out of nixops control. |
I've been deploying a server with
nix copy
for a while now, but suddenly I find it's no longer working.The command pauses (apparently indefinitely) with no clue as to why. If I interrupt it and run it again, I get exactly the same behavior.
Watching
top
on the server, I see that anix-store --serve --write
process is running.I've tried restarting sshd and nix-daemon on the server, and I've rebooted my laptop.
Update: After about an hour, the
nix copy
command printed this and halted:The text was updated successfully, but these errors were encountered: