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

Fix CPU profiler latency #1673

Merged
merged 1 commit into from Nov 2, 2021
Merged

Fix CPU profiler latency #1673

merged 1 commit into from Nov 2, 2021

Conversation

Qard
Copy link
Collaborator

@Qard Qard commented Nov 2, 2021

Depends on DataDog/pprof-nodejs#13

The current profile must be stopped AFTER the next begins. This is because V8 will tear down the symbolizer thread when the active profile count reaches zero. This means the next profile started will spin up a new symbolizer thread. When this thread starts it streams in all the JIT location information which could block the JavaScript thread for a significant length of time.

However, pre-v16 versions of Node.js have a memory leak in V8 that requires disposing the profiler between each profile. This has been fixed in the pprof module by changing to reusing the stop function with an argument to specify if it should start a new profile when called. This allows the ordering to be rearranged depending on the Node.js version.

@Qard Qard added the profiling label Nov 2, 2021
@Qard Qard requested a review from a team as a code owner November 2, 2021 00:29
The current profile must be stopped AFTER the next begins. This is because V8 will
tear down the symbolizer thread when the active profile count reaches zero. This
means the next profile started will spin up a new symbolizer thread. When this
thread starts it streams in all the JIT location information which could block the
JavaScript thread for a significant length of time.
@Qard Qard merged commit b192ccb into master Nov 2, 2021
@Qard Qard deleted the fix-cpu-profiler-latency branch November 2, 2021 18:24
rochdev pushed a commit that referenced this pull request Nov 2, 2021
The current profile must be stopped AFTER the next begins. This is because V8 will
tear down the symbolizer thread when the active profile count reaches zero. This
means the next profile started will spin up a new symbolizer thread. When this
thread starts it streams in all the JIT location information which could block the
JavaScript thread for a significant length of time.
rochdev pushed a commit that referenced this pull request Nov 2, 2021
The current profile must be stopped AFTER the next begins. This is because V8 will
tear down the symbolizer thread when the active profile count reaches zero. This
means the next profile started will spin up a new symbolizer thread. When this
thread starts it streams in all the JIT location information which could block the
JavaScript thread for a significant length of time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants