Originally Posted by syg00
This sounds horribly rubbery.
- is this multi-threaded ???.
- same number of threads for the entire period ...
- all of them always runnable (during your period) ...
Think about it this way - if you have 8 (or 12, or ...) threads, but only 3 are runnable (and hence accumulating CPU time), how does that affect the numbers ???.
Your maths sounds potentially dodgy to me.
I managed to speak with one of my colleagues at work about this as well. I think 'threads' is the key to explaining the figures.
Yes, the process I'm monitoring is massively multi-threaded. It actually maintains about 1,115 threads throughout the sample period.
I now see that the ideal solution would be to capture data for all the threads of each process, but it's not practical to do so in the environments in which I work. I run benchmarks on applications that are always massively multi-threaded, where sessions are created and destroyed regularly throughout the sample periods. Sessions generally multiplex across threads.
I think I can make sense of the data if I make some broad assumptions. I'll start by assuming that my system is balanced and that all the process threads are evenly distributed across all the CPU Cores. This way, in my example, the 'CPU TIME' can be regarded as the total thread processing time spread evenly across all CPU Cores. I have 8 Cores, so dividing by 8 gives me the average 'CPU TIME' of the process over the sample period.
It's not ideal, but I'm open to better suggestions. My data collection sample period is 2 hours, so there's a decent chance that the system settled into a balanced run over that period. Unfortunately, I can't go back and re-run my benchmark to capture new data. I have to work with the data I've already captured.