Skip to content
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

Collect build time statistics #1710

Open
lheckemann opened this issue Dec 2, 2017 · 13 comments
Open

Collect build time statistics #1710

lheckemann opened this issue Dec 2, 2017 · 13 comments
Assignees
Labels
feature Feature request or proposal UX The way in which users interact with Nix. Higher level than UI.

Comments

@lheckemann
Copy link
Member

I've often found myself wanting to know how long a derivation took to build. The closest I've found to this has been using stat /nix/var/log/nix/drvs/xx/xx[…]-foo-bar.drv and subtracting the atime from the mtime. This is very brittle, however, and I think it would be nice for nix to record this information somewhere. Does this perhaps already exist? Any thoughts on the idea or implementation?

@danbst
Copy link
Contributor

danbst commented Mar 8, 2019

Hydra does collect build duration, but how to use it?
https://hydra.nixos.org/build/90102549

Duration: | 17s

But we don't know number of cores, parallelism and CPU frequency of builder machine. Maybe user-time collection would be great here, as building is usually CPU intensive, and other subsystems are not very loaded.

Local collector would be also great, for both successful builds and failed ones.

@vcunat
Copy link
Member

vcunat commented Mar 8, 2019

Yes, collecting stats like user+sys time is the best suggestion so far. I doubt there's something noticeably better that's easy to do, at least in the way Hydra.nixos.org looks (quite diverse).

EDIT: for good usability, we'd need to think of API exposing such meta-data via binary cache. Then nix build might even show ETA 🌈

@Gaelan
Copy link

Gaelan commented May 13, 2020

Some other statistics that might be useful:

  • max disk usage (might be able to get away with only measuring disk usage at the end, but maybe some build systems delete intermediate files before the end? in that case, we'd need to regularly measure)
    • would allow us to warn and/or offer to run GC if there's insufficient space to build something
  • max memory usage
  • lines/bytes of build output
    • assuming that builds spew out logs at a roughly constant rate, this would let us make a decent guess at an ETA even on machines faster/slower than Hydra

@timokau
Copy link
Member

timokau commented May 14, 2020

I love the last idea! To be a bit more precise, you could actually annotate every output line with a timestamp and then with the benefit of hindsight say "after 10% of the build time the builder hat produced 1000 lines". That would cover the case where for example the actual build is relatively quiet but the install phase spews a lot of information.

@zimbatm
Copy link
Member

zimbatm commented May 15, 2020

It would be very useful if that information was attached to the .narinfo file.

@stale
Copy link

stale bot commented Feb 13, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the stale label Feb 13, 2021
@anka-213
Copy link

I'm still interested in this happening

@stale
Copy link

stale bot commented Aug 17, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the stale label Aug 17, 2021
@ncfavier
Copy link
Member

Annoying bot; this is important.

@stale stale bot removed the stale label Dec 20, 2021
@lheckemann
Copy link
Member Author

This could probably be bolted on using the pre-build-hook and post-build-hook options.

@stale stale bot added the stale label Aug 1, 2022
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/measure-elapsed-time-in-phases-successful-or-not/21161/1

@fricklerhandwerk fricklerhandwerk added UX The way in which users interact with Nix. Higher level than UI. error-messages Confusing messages and better diagnostics labels Sep 13, 2022
@lheckemann
Copy link
Member Author

@fricklerhandwerk I don't see how this is related to error messages?

@stale stale bot removed the stale label Sep 26, 2022
@fricklerhandwerk fricklerhandwerk removed the error-messages Confusing messages and better diagnostics label Sep 28, 2022
@fricklerhandwerk
Copy link
Contributor

Probably a random mistake, I went through issues fairly quickly.

@fricklerhandwerk fricklerhandwerk added the feature Feature request or proposal label Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature request or proposal UX The way in which users interact with Nix. Higher level than UI.
Projects
None yet
Development

No branches or pull requests