-
Notifications
You must be signed in to change notification settings - Fork 2
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
FR pgcollect: add -a
"all cpus" option - or similar
#23
Comments
This is not so easy. perfgrind was created to see callgraphs, and there is no calls between different unrelated processes. You can get take a look on flat profile, but this is already available with standard 'perf'. Another option is to generated distinct callgraphs for each PID separately, but for system wide profiling this will end with huge number of files, each distinct one for each process running in the system. I do not think anybody is interested in this. Usually people identify processes they are interested in and then focus on them. On side note there is "bug" in pgcollect regarding how it handles forks, see here: Lines 10 to 13 in 485b3f7
|
The issue is that multiple processes will be spawned and end within 3h. The goal is to gather 10 to 20 samples with 3-5 minutes each, but up front only username/-id and binary name (and part of the command line) is known.
For perf: record with -a and limit to use, then filter, for example with hotspot.
This scenario is the only where perfgrind currently does not fit.
|
Ok, I see the use case, however an item in TODO list should be implemented first. |
It would be nice to add that issue and the workaround in the TODO :-) I've implemented the workaround as two cases
|
The option to limit the recording (in perf only "by event" or "by user name/id") would be necessary, too (username/id would be fine, "by binary" would be extra cool, "by text match in command line" would be even better).
pgconvert could then use a single "logical" "collection" as root (if necessary) and then the PIDs as logical sub-notes - before adding the appropriate stack; pginfo would provide some details on the PIDs collected.
A feature like this is the one part that is missing most compared to "plain perf" or its rcording + conversion to callgrind format (which misses details but most important "eats CPU like an end-boss").
The text was updated successfully, but these errors were encountered: