-
Notifications
You must be signed in to change notification settings - Fork 4
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
overhead of perf? #421
Comments
👋
There are a few different sources of overhead, but generally speaking it works out like this.
Of these sources of overhead,
These are rough estimates from internal studies we've done with
If you're trying to estimate the overhead of this type of instrumentation (indeed, any kind of profiling or observability), here are my own, personal recommendations. You may have your own discipline here already and my ideas might be too stupid for your purposes, but I'll share them anyway in case there is value.
I apologize that this summary isn't very precise, but an in-depth study should probably be related to a given workload. In general though, we find that with DWARF unwinding enabled, we rarely see services hit more than ~2% overhead (and usually much less). |
You said "Other forms of overhead (categories 3-5) consume CPU in a manner that doesn't directly block the instrumented application". Wouldn't unwinding the stack cause the sampled application to enter kernel mode from user mode and be blocked at the same time? |
If I only collect the stack through perf record -e cpu -a -g, without symbolization (which will be done asynchronously on another machine). Then its overhead is basically the overhead of switching the user program from user mode to kernel mode (frame pointer stack expansion takes ns level) |
i use perf -e cpu -a -g to run profiling in machine continously.
what is the overhead for process?
as i know, the perf_event_open will cause user program context switch when counter trigged?
The text was updated successfully, but these errors were encountered: