search

end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

CPU Stats per CPU #125

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is a feature. 

It would be nice to see the cpu stats broken down on a per cpu basis (and 
important to know sometimes - as one process may be maxing out a single cpu and 
you only see 25% on a 4cpu system).

Original issue reported on code.google.com by kenneths...@gmail.com on 28 Oct 2010 at 7:06

GoogleCodeExporter commented 9 years ago

Original comment by jlo...@gmail.com on 28 Oct 2010 at 7:12

GoogleCodeExporter commented 9 years ago

Original comment by jlo...@gmail.com on 28 Oct 2010 at 7:13

GoogleCodeExporter commented 9 years ago 
I checked out the sigar library since Kenny mentioned it has per-CPU stats and 
it's open source. It looks like on OS X we can pull stats per CPU using 
host_processor_info() 

The same code file also has BSD per-processor information, using sysctl() with 
kern.cp_times - according to the comments in the file, this is available on 
FreeBSD sometime after version 7.0 

Looking at the Windows code seems to indicate this is available on Windows as 
well, using perfmon counters in C code (not at all looking forward to 
implementing that one). As a side note, there are some pretty funny comments in 
the Windows code from frustrated developers ;)  Not sure what versions of 
Windows will work with this method.

Lastly, for Linux they're using /proc/stat to read per-CPU statistics, so that 
shouldn't be a problem. 

It looks like we can implement this on all our platforms, so next question is 
how to (re)design the API for it. We can either re-arrange the existing calls, 
or it might make sense to create new methods that specifically return per-CPU 
statistics. In my experience with systems administration and monitoring 
software, some folks really prefer individual CPU stats and others only care 
about total overall numbers. I would recommend we provide both, regardless of 
how we work out the design. 

FWIW, sigar is using almost the exact methods we are for providing total CPU 
util on all platforms... it might be worth having separate code paths, since it 
gives us fallback capabilities if on some systems the per-CPU stats fail for 
any reason (or vice versa).

Original comment by jlo...@gmail.com on 29 Oct 2010 at 2:19

GoogleCodeExporter commented 9 years ago 
In Windows, NtQuerySystemInformation with SystemProcessorPerformanceInformation 
will give you the stats you need.

Original comment by wj32...@gmail.com on 30 Oct 2010 at 11:10

GoogleCodeExporter commented 9 years ago 
Attached is a patch which implements system per-CPU times/percent on Linux.
As for the original OP request:

> It would be nice to see the cpu stats broken down on a per 
> cpu basis (and important to know sometimes - as one process
> may be maxing out a single cpu and you only see 25% on a 
> 4cpu system).  

This is incorrect as we are currently returning the utilization of a *single* 
CPU.
Hence, on a 4 core system if one process is consuming all the resources of one 
CPU, 100 is returned (and not 25).
In summary, what we need is system's per-cpu percent stats only.

Original comment by g.rodola on 4 Jun 2011 at 5:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Linux implementation added as r988 (tests as r989).

Original comment by g.rodola on 4 Jun 2011 at 5:43

GoogleCodeExporter commented 9 years ago 
Implemented on Windows in r992.

Original comment by g.rodola on 4 Jun 2011 at 7:04

GoogleCodeExporter commented 9 years ago 
Implemented for FreeBSD in r993.

Original comment by g.rodola on 4 Jun 2011 at 7:52

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 9 Jun 2011 at 10:33

GoogleCodeExporter commented 9 years ago 
Attached is a patch to implement this on OS X.  My patch also includes the 
resurrection of get_system_cpu_times for OS X since it was either removed 
accidentally or not refactored properly as the test suite, on trunk, would 
complain about the OS X module not having the get_system_cpu_times attribute.  
If my addressing that was unnecessary, or wrong, feel free to remove it from 
the patch but the work for get_system_per_cpu_times should not have an impact 
on this.  I have prepended my commit log message to the beginning of the patch 
so you know what I did, and why.

Take care,

Jeremy

Original comment by jcscoob...@gmail.com on 22 Jun 2011 at 10:48

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks.
Committed in r1042.

Original comment by g.rodola on 27 Jun 2011 at 8:05

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 27 Jun 2011 at 5:52

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 8 Jul 2011 at 7:07

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Updated csets after the SVN -> Mercurial migration:
r988 == revision 31dbaea0a938
r992 == revision 07454606f43f
r993 == revision 8fc87c05dc2f
r1042 == revision eecd5b15fe00

Original comment by g.rodola on 2 Mar 2013 at 11:55