-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[Profiling] Don't group by address if executable is known but function is unknown #129498
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
Conversation
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For an expert, this can also be seen as misleading as it hides the separation of different callers (even if the caller information is unknown, the fact that separate callers are shown can be useful in itself). But given our target audience and that it doesn't affect the relative order of CPU usage across executables and thread names, I think it's OK to introduce a simplification such as this and iterate.
...ck/plugin/profiling/src/main/java/org/elasticsearch/xpack/profiling/action/FrameGroupID.java
Show resolved
Hide resolved
…xecutable This reduces the complexity of the flamegraph in unsymbolized areas. Symbolized areas of the flamegraph are not affected.
0db2c1b to
596d993
Compare
As you say, our target audience isn't the expert who takes the addresses and puts them in Ghidra or IDA to make use of it. But also, if enough customers ask for more details, we can add a setting to turn the details on again. |
…n is unknown (elastic#129498) * [Profiling] Omit address in grouping for unknown function but known executable This reduces the complexity of the flamegraph in unsymbolized areas. Symbolized areas of the flamegraph are not affected. * Fix tests * Fix IT tests
This PR ignores the address or line number when grouping frames with unknown function name but known executable name.
Fully symbolized frames are not affected at all.
This change only affects how unsymbolized frames are grouped / aggregated.
For example, an unsymbolized
lib.so.6sill appear as a single entry in the TopN functions view, and no longer as hundreds of different entries.In the flamegraph, this changed aggregation of frames leads to less complexity.
Here are screenshots that show the change as it is otherwise hard to phrase and understand.
Before

After
