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
ca-specific-schema.sql: add index on RealisationsRefs(referrer) #5366
Conversation
CC @regnat |
Noticed similar performance problem on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot. That’s awfully sensible indeed.
Can you just bundle the two schemas upgrades into one to avoid cluttering the migrateCASchema
function to quickly?
Sounds good! Lumped two indices together into one schema update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
I’ll just wait for the CI to finish, and merge it this evening or tomorrow.
(/me really wishes Github had a “Merge when CI is green” button like GitLab has)
The CI timeout is strange… I’ve restarted it this morning, but it seems to be sticky 🤔 |
I didn’t try to understand what was going on, but it looks like $ nix develop .#checks.x86_64-linux.installTests.againstCurrentUnstable --run './bootstrap.sh'
[...]
$ nix develop .#checks.x86_64-linux.installTests.againstCurrentUnstable --configure
[...]
$ nix develop .#checks.x86_64-linux.installTests.againstCurrentUnstable --run "make tests/ca/post-hook.sh.test"
*hangs* |
Rebased past 19148f1 |
I think it hangs for me as well in
|
|
Created separate bug: #5450 |
Having poked a bit in gdb I think it's caused by this patch. Schema migration wants and exclusive write. It seems to be triggered by a first unfinished copy that holds reader lock. |
Rebased past merged PR#5506. That should fix the CI. |
…outputPath) For a typical desktop system (~2K packages) we can easily get 100K entries in RealisationsRefs. Without indices query for RealisationsRefs requires linear scan. RealisationsRefs(referrer) -------------------------- Inefficiency is seen as a 100% CPU load of nix-daemon for the following scenario: $ nix edit -f . bash # add unused environment variable, like FOO="1" # populate RealisationsRefs, build fresh system $ nix build -f nixos system --arg config '{ contentAddressedByDefault = true; }' $ nix edit -f . bash # add unused environment variable, like FOO="2" $ time nix build -f nixos system --arg config '{ contentAddressedByDefault = true; }' In this case `bash `will be rebuilt a few times and then rest of CPU time is spent on scanning RealisationsRefs table (about 5 CPU-minutes on my machine). Before the change: $ time nix build -f nixos system ... # step 4 above real 34m3,613s user 0m5,232s sys 0m0,758s Of all this time about 29.5 minutes are taken by nix-daemon's CPU time. After the change: $ time nix build -f nixos system ... # step 4 above real 4m50,061s user 0m5,038s sys 0m0,677s Of all this time about 1 minute is taken by nix-daemon's CPU time. Most of the time is spent polling for non-existent realisations on cache-nixos.org. Realisations(outputPath) ------------------------ After running CA system for two weeks I got ~1M entries in Realisations table. `nix-collect-garbage` became very slow (seemingly 100 path deletions per second). It happens due to a slow cascading delete from Realisations triggered by deletion from ValidPaths. The fix is to add an index on primary key from ValidPaths(id) that triggers cascading deletions. Before the change: $ time nix-collect-garbage -d --max-freed 100G <interrupted before finish, took too long> real 23m32.411s user 17m49.679s sys 4m50.609s Most of time was spent in re-scanning Realisations table on each path deletion. After the change: $ time nix-collect-garbage -d --max-freed 100G real 8m43.226s user 6m16.317s sys 1m40.188s Time is spent scanning sqlite indices and in kernel when unlinking directories.
Rebase helped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/content-addressed-nix-call-for-testers/12881/162 |
For a typical desktop system (~2K packages) we can easily get 100K
entries in RealisationsRefs. Without indices query for RealisationsRefs
requires linear scan.
Inefficiency is seen as a 100% CPU load of nix-daemon for the following
scenario:
In this case
bash
will be rebuilt a few times and then rest of CPUtime is spent on scanning RealisationsRefs table (about 5 CPU-minutes
on my machine).
Before the change:
Of all this time about 29.5 minutes are taken by nix-daemon's CPU time.
After the change:
Of all this time about 1 minute is taken by nix-daemon's CPU time.
Most of the time is spent polling for non-existent realisations on
cache-nixos.org.