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

Feature request: Output test maximum memory usage #1202

Open
JonathanWoollett-Light opened this issue Jan 2, 2024 · 1 comment
Open

Feature request: Output test maximum memory usage #1202

JonathanWoollett-Light opened this issue Jan 2, 2024 · 1 comment

Comments

@JonathanWoollett-Light
Copy link

When running tests the time they take to execute is output to the console, it would also be valuable to see their maximum memory usage.

With large test sets you can start to hit OOM errors.

@JonathanWoollett-Light JonathanWoollett-Light changed the title Feature request: Output test memory usage statistics Feature request: Output test maximum memory usage Jan 2, 2024
@sunshowers
Copy link
Member

Thanks for the request!

It looks like the way to do this would be to use wait4 (available on most Unixes, e.g. Linux) to obtain, in particular, the maxrss. I'm not sure if something similar would work on Windows.

I did look briefly at the wait4 crate: https://github.com/lu-zero/wait4-rs. But it has limitations:

  • It doesn't support anything other than a few Unixes. This should be easy to fix.

  • Per Windows support is problematic lu-zero/wait4-rs#1 it looks like Windows support still needs a little shoring up. But the good news is that we do already create a JobObject within nextest, so fixing it is hopefully not very difficult.

  • We'll need to figure out a way to integrate the crate with async/Tokio. This would mean either working with upstream Tokio to add support for custom wait methods, or bypassing and either copy/pasting or rewriting most of Tokio's process code (e.g. the Unix code). We may be able to punt on this by using blocking calls, but that seems janky and I'm worried there are subtle cases (particularly around signal handling) where it breaks. The interaction between signal handling and process spawning is very fraught.

    I think it'd be worth working with the Tokio folks to see what ideas they have here.

It's a somewhat involved project with a fair bit of coordination. I don't plan to work on this unless my employer happens to need it, but contributions welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants