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

5x increase cpu usage of uv__async_io.part.1 in v14.19.0 vs v14.18.3 #42027

Closed
murillo128 opened this issue Feb 17, 2022 · 2 comments
Closed
Labels
libuv Issues and PRs related to the libuv dependency or the uv binding. performance Issues and PRs related to the performance of Node.js.

Comments

@murillo128
Copy link

Version

v14.19.0

Platform

Linux 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

libuv

What steps will reproduce the bug?

I have taken a flamegraph (https://www.brendangregg.com/flamegraphs.html) of my server code running under full load. Not sure if i could provide an example that triggers the same behaviour.

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

node v12.18.3

image

What do you see instead?

node v14.19.0
image

which is almost a 5x cpu usage increase vs the previous v14 version

Additional information

The only commit between those 2 versions that could impact libuv is this one #40631
which adds -fno-strict-aliasing flag to libuv

@Mesteery Mesteery added the libuv Issues and PRs related to the libuv dependency or the uv binding. label Feb 17, 2022
@mmarchini mmarchini added the performance Issues and PRs related to the performance of Node.js. label Feb 18, 2022
@mmarchini
Copy link
Contributor

Theoretically it does make sense to see a performance hit from adding -fno-strict-aliasing, but I'm not sure how much it actually happens in practice. Also, based on my reading of PRs and issues associated with it, we can't safely remove the flag, unfortunately. This could still be something else though, so it would be good to find a way to reproduce it. Whatever extra info you can share would be helpful:

  1. Dependencies (or a subset of, like what http framework is being used, instrumentation libraries, etc.)
  2. Any native modules being used? If so, which ones?
  3. What kind of load is this service serving? (small vs large requests, I/O heavy vs computational heavy requests, low vs high RPS)
  4. Are you using async hooks or domains (directly or indirectly)?

I know you might not be able to share some of those, but whatever you can will help us narrow down the issue. Also, might be helpful to compare performance between v12.18.3 and v12.20.10 (latest 12.x) to see if it was introduced on 14 or 12.

@murillo128
Copy link
Author

I am closing this for now. Not sure exactly why the behaviour has changed with previous versions, but the issue seems to happen only when running it inside pm2 and not when run standalone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libuv Issues and PRs related to the libuv dependency or the uv binding. performance Issues and PRs related to the performance of Node.js.
Projects
None yet
Development

No branches or pull requests

3 participants