performancecopilot
pcp-top: inital imlemenation of pcp-top utility
@orasagar We already have pcp-atop and pcp-htop. What is the reason to add pcp-top ? Is there any use case which either pcp-atop or pcp-htop does not cover ?
Yeah, agreeing with @kurik here - not sure there's a need for a third top-like tool in PCP. It'd be best to improve the existing ones if features are missing - pcp-htop in particular is under active development and even supports arbitrary metrics (i.e. beyond top processes). Is there something novel in this new approach I'm missing here @orasagar ? Thanks!
Hi @kurik and @natoscott , I agree with you that pcp-atop and pcp-htop are useful tools to work with. They perform well on live systems; however, when replaying archived data, processing time becomes a concern. In our testing, it has taken more than 30 minutes just to open half a day’s archive, and stakeholders have reported frustration with the slow performance.
Additionally, both tools output data in a slightly different format compared to other PCP tools currently in use. This inconsistency makes parsing more difficult. with this tool we are trying to achieve is give user flexibility to sort top %cpu or %mem consumer.
@orasagar this new pcp-top uses the same PMAPI interfaces so has exactly the same performance issues, no? Do you have some perf profiles you can share showing the problem and how pcp-top resolves it? FWIW, pcp-htop does not yet support archive mode (this would be wonderful to add though).
pcp-atop can be slow on some archives, but there have been numerous improvements recently, particularly when using zstd compression - have you tried this? IMO the answer to improved performance is not to add a new tool, but to analyse and improve the existing tools.
Re sorting output, it makes little sense to me to post-process top tool output - why not use something like pmrep or the top-most options to pcp-atopsar? However, if you must do sorting, then implement a new output mode for an existing tool, no need to add an entire new one. The upstream atop code has a JSON output option, perhaps we should back-port that to pcp-atop?
Finally, there was a pcp-xsos tool added last year to provide another, single-sample rapid overview from an archive - might help those users with performance concerns as well.
@natoscott I don’t have performance profiles to share at the moment, but I’d like to clarify the motivation behind this tool.
The main goal is to bring consistency with other PCP tools output and align more closely with the standard top batch mode output. While similar functionality can be achieved with pmrep, it requires user to know specific metrics, which isn’t always straightforward. Looking ahead, I plan to evolve this tool to use hotproc metrics, making it more dynamic and flexible as those metrics are captured.
I agree that backporting the JSON output option is a good idea, but it will take some time. Also, atop already has a very large set of options, which can be overwhelming for users. The intent here is to provide a simpler, more consistent interface that addresses common use cases without adding to that complexity.
Hi @orasagar,
While similar functionality can be achieved with pmrep, it requires user to know specific metrics, which isn’t always straightforward.
Have a look below /etc/pcp/pmrep - these files configure sets of metrics that can be requested on the pmrep command line, as a group, to address this kind of problem.
Looking ahead, I plan to evolve this tool to use hotproc metrics, making it more dynamic and flexible as those metrics are captured.
pcp-atop(1) already has a mode where it can use hotproc metrics FWIW - see the --hotproc option.
Hi @natoscott ,
If you agree, I can implement sorting of processes (--sort option) based on %MEM and %CPU in pcp ps, similar to what ps already supports.
@natoscott @kurik I have created this PR :- https://github.com/performancecopilot/pcp/pull/2436