Blog posts for tags/python

1. Sensors: temperatures, battery, CPU frequency

   psutil 5.1.0 is out. This release introduces new APIs to retrieve hardware temperatures, battery status, and CPU frequency information.

   Temperatures¶

   You can now retrieve hardware temperatures (PR-962). This is currently available on Linux only.

   • On Windows it's hard to do in a hardware-agnostic way. I ran into 3 WMI-based approaches, none of which worked with my hardware, so I gave up.
   • On macOS it seems relatively easy, but my virtualized macOS box doesn't support sensors, so I gave up for lack of hardware. If someone wants to give it a try, be my guest.

   >>> import psutil
   >>> psutil.sensors_temperatures()
   {'acpitz': [shwtemp(label='', current=47.0, high=103.0, critical=103.0)],
    'asus': [shwtemp(label='', current=47.0, high=None, critical=None)],
    'coretemp': [shwtemp(label='Physical id 0', current=52.0, high=100.0, critical=100.0),
                 shwtemp(label='Core 0', current=45.0, high=100.0, critical=100.0),
                 shwtemp(label='Core 1', current=52.0, high=100.0, critical=100.0),
                 shwtemp(label='Core 2', current=45.0, high=100.0, critical=100.0),
                 shwtemp(label='Core 3', current=47.0, high=100.0, critical=100.0)]}
   

   Battery status¶

   Battery status information is now available on Linux, Windows and FreeBSD (PR-963).

   >>> import psutil
   >>>
   >>> def secs2hours(secs):
   ...     mm, ss = divmod(secs, 60)
   ...     hh, mm = divmod(mm, 60)
   ...     return "%d:%02d:%02d" % (hh, mm, ss)
   ...
   >>> battery = psutil.sensors_battery()
   >>> battery
   sbattery(percent=93, secsleft=16628, power_plugged=False)
   >>> print("charge = %s%%, time left = %s" % (battery.percent, secs2hours(battery.secsleft)))
   charge = 93%, time left = 4:37:08
   

   CPU frequency¶

   Available on Linux, Windows and macOS (PR-952). Only Linux reports the real-time value (always changing); other platforms return the nominal "fixed" value.

   >>> import psutil
   >>> psutil.cpu_freq()
   scpufreq(current=931.42925, min=800.0, max=3500.0)
   >>> psutil.cpu_freq(percpu=True)
   [scpufreq(current=2394.945, min=800.0, max=3500.0),
    scpufreq(current=2236.812, min=800.0, max=3500.0),
    scpufreq(current=1703.609, min=800.0, max=3500.0),
    scpufreq(current=1754.289, min=800.0, max=3500.0)]
   

   What CPU a process is on¶

   Tells you which CPU a process is currently running on, somewhat related to Process.cpu_affinity() (PR-954). It's interesting for visualizing how the OS scheduler keeps evenly reassigning processes across CPUs (see the cpu_distribution.py script).

   CPU affinity¶

   A new shorthand is available to set affinity against all eligible CPUs:

   Process().cpu_affinity([])
   

   This was added because on Linux (#956) it is not always possible to set affinity against all CPUs directly. It is equivalent to:

   psutil.Process().cpu_affinity(list(range(psutil.cpu_count())))
   

   Other bug fixes¶

   See the full list in the changelog.

2. Making psutil twice as fast

   Starting from psutil 5.0.0 you can query multiple Process fields around twice as fast as before (see #799 and Process.oneshot() doc). It took 7 months, 108 commits, and a massive refactoring of psutil internals (PR-937), and I think it's one of the best improvements ever shipped in a psutil release.

   The problem¶

   How process information is retrieved varies by OS. Sometimes it means reading a file in /proc (Linux), other times calling C (Windows, BSD, macOS, SunOS), but it's always done differently. Psutil abstracts this away: you call Process.name() without worrying about what happens under the hood or which OS you're on.

   Internally, multiple pieces of process info (e.g. Process.name(), Process.ppid(), Process.uids(), Process.create_time()) are fetched by the same syscall. On Linux we read /proc/PID/stat to get the process name, terminal, CPU times, creation time, status and parent PID, but only one value is returned: the others are discarded. On Linux this code reads /proc/PID/stat 6 times:

   >>> import psutil
   >>> p = psutil.Process()
   >>> p.name()
   >>> p.cpu_times()
   >>> p.create_time()
   >>> p.ppid()
   >>> p.status()
   >>> p.terminal()
   

   On BSD most process metrics can be fetched with a single sysctl(), yet psutil was invoking it for each process method (e.g. see here and here).

   Do it in one shot¶

   It's clear that this approach is inefficient, especially in tools like top or htop, where process info is continuously fetched in a loop. psutil 5.0.0 introduces a new Process.oneshot() context manager. Inside it, the internal routine runs once (in the example, on the first Process.name() call) and the other values are cached. Subsequent calls sharing the same internal routine (read /proc/PID/stat, call sysctl() or whatever) return the cached value. The code above can now be rewritten like this, and on Linux it runs 2.4 times faster:

   >>> import psutil
   >>> p = psutil.Process()
   >>> with p.oneshot():
   ...     p.name()
   ...     p.cpu_times()
   ...     p.create_time()
   ...     p.ppid()
   ...     p.status()
   ...     p.terminal()
   

   Implementation¶

   One great thing about psutil's design is its abstraction. It is divided into 3 "layers". Layer 1 is represented by the main Process class (Python), which exposes the high-level API. Layer 2 is the OS-specific Python module, which is a thin wrapper on top of the OS-specific C extension module (layer 3).

   Because the code was organized this way (modular), the refactoring was reasonably smooth. I first refactored those C functions that collect multiple pieces of info and grouped them into a single function (e.g. see BSD implementation). Then I wrote a decorator that enables the cache only when requested (when entering the context manager), and decorated the "grouped functions" with it. The caching mechanism is controlled by the Process.oneshot() context manager, which is the only thing exposed to the end user. Here's the decorator:

   def memoize_when_activated(fun):
       """A memoize decorator which is disabled by default. It can be
       activated and deactivated on request.
       """
       @functools.wraps(fun)
       def wrapper(self):
           if not wrapper.cache_activated:
               return fun(self)
           else:
               try:
                   ret = cache[fun]
               except KeyError:
                   ret = cache[fun] = fun(self)
               return ret
   
       def cache_activate():
           """Activate cache."""
           wrapper.cache_activated = True
   
       def cache_deactivate():
           """Deactivate and clear cache."""
           wrapper.cache_activated = False
           cache.clear()
   
       cache = {}
       wrapper.cache_activated = False
       wrapper.cache_activate = cache_activate
       wrapper.cache_deactivate = cache_deactivate
       return wrapper
   

   To measure the speedup I wrote a benchmark script (well, two actually), and kept tuning until I was sure the change actually made psutil faster. The scripts report the speedup for calling all the "grouped" methods together (best-case scenario).

   Linux: +2.56x speedup¶

   The Linux implementation is mostly Python, reading files in /proc. These files typically expose multiple pieces of info per process; /proc/PID/stat and /proc/PID/status are the perfect example. We aggregate them into three groups. See the relevant code here.

   Windows: from +1.9x to +6.5x speedup¶

   Windows is an interesting one. For a process owned by our user, we group only Process.num_threads(), Process.num_ctx_switches() and Process.num_handles(), for a +1.9x speedup if we access those methods in one shot.

   Windows is special though, because certain methods have a dual implementation (#304): a "fast method" is tried first, but if the process is owned by another user it fails with AccessDenied. psutil then falls back to a second, "slower" method (see here for example).

   It's slower because it iterates over all PIDs, but unlike the "plain" Windows APIs it can still retrieve multiple pieces of information in one shot: number of threads, context switches, handles, CPU times, create time, and I/O counters.

   That's why querying processes owned by other users results in an impressive +6.5x speedup.

   macOS: +1.92x speedup¶

   On macOS we can get 2 groups of information. With sysctl() we get process parent PID, uids, gids, terminal, create time, name. With proc_info() we get CPU times (for PIDs owned by another user), memory metrics and ctx switches. Not bad.

   BSD: +2.18x speedup¶

   On BSD we gather tons of process info just by calling sysctl() (see implementation): process name, ppid, status, uids, gids, IO counters, CPU and create times, terminal and ctx switches.

   SunOS: +1.37x speedup¶

   SunOS is like Linux (it reads files in /proc), but the code is in C. Here too, we group different metrics together (see here and here).

   Discussion¶

   • Reddit

3. Improved Linux memory metrics

   OK, another psutil release. The headline of 4.4.0 is more accurate memory metrics on Linux, plus a pile of macOS fixes I'd been sitting on for years.

   Linux virtual memory¶

   People had been complaining for a while that virtual_memory() didn't match what free reported on Linux (#862, #685, #538). I finally dug into it (#887, PR-890) and, funny enough, it turns out free itself was doing it wrong until about two years ago, when somebody got tired of everyone guessing and moved the calculation into the kernel.

   Starting with Linux 3.14, /proc/meminfo has a MemAvailable column. That's what psutil now uses, and the available / used fields match free exactly. On older kernels (< 3.14) psutil falls back to the same formula that kernel commit introduced.

   free's source code also inspired a fix that prevents available memory from overflowing total memory on LXC containers.

   macOS fixes¶

   For years I did psutil's macOS development on an old 10.5 install emulated via VirtualBox, running iDeneb (a hacked macOS). I finally got access to a more recent version (El Capitan) via VirtualBox + Vagrant, and could address a pile of long-standing bugs:

   • #514: Process.memory_maps() segfault (critical).
   • #783: Process.status() could return "running" for zombie processes.
   • #908: several methods could mask the real error for high-privileged PIDs, raising NoSuchProcess / AccessDenied instead of OSError / RuntimeError.
   • #909: Process.open_files() and Process.connections() could raise OSError with no exception set when the process was gone.
   • #916: fixed many compilation warnings.

   NIC netmask on Windows¶

   Small but nice: net_if_addrs() on Windows now returns the netmask too.

   Improved procinfo.py¶

   scripts/procinfo.py is my kitchen-sink demo script. I taught it a bunch of new tricks, so it now dumps pretty much everything psutil knows about a process:

   $ python scripts/procinfo.py
   pid           4600
   name          chrome
   parent        4554 (bash)
   exe           /opt/google/chrome/chrome
   cwd           /home/giampaolo
   cmdline       /opt/google/chrome/chrome
   started       2016-09-19 11:12
   cpu-tspent    27:27.68
   cpu-times     user=8914.32, system=3530.59,
                 children_user=1.46, children_system=1.31
   cpu-affinity  [0, 1, 2, 3, 4, 5, 6, 7]
   memory        rss=520.5M, vms=1.9G, shared=132.6M, text=95.0M, lib=0B,
                 data=816.5M, dirty=0B
   memory %      3.26
   user          giampaolo
   uids          real=1000, effective=1000, saved=1000
   terminal      /dev/pts/2
   status        sleeping
   nice          0
   ionice        class=IOPriority.IOPRIO_CLASS_NONE, value=0
   num-threads   47
   num-fds       379
   I/O           read_count=96.6M, write_count=80.7M,
                 read_bytes=293.2M, write_bytes=24.5G
   ctx-switches  voluntary=30426463, involuntary=460108
   children      PID    NAME
                 4605   cat
                 4606   cat
                 4609   chrome
                 4669   chrome
   open-files    PATH
                 /opt/google/chrome/icudtl.dat
                 /opt/google/chrome/snapshot_blob.bin
                 /opt/google/chrome/natives_blob.bin
                 /opt/google/chrome/chrome_100_percent.pak
                 [...]
   connections   PROTO LOCAL ADDR            REMOTE ADDR               STATUS
                 UDP   10.0.0.3:3693         *:*                       NONE
                 TCP   10.0.0.3:55102        172.217.22.14:443         ESTABLISHED
                 UDP   10.0.0.3:35172        *:*                       NONE
                 TCP   10.0.0.3:32922        172.217.16.163:443        ESTABLISHED
                 UDP   :::5353               *:*                       NONE
                 UDP   10.0.0.3:59925        *:*                       NONE
   threads       TID              USER          SYSTEM
                 11795             0.7            1.35
                 11796            0.68            1.37
                 15887            0.74            0.03
                 19055            0.77            0.01
                 [...]
                 total=47
   res-limits    RLIMIT                     SOFT       HARD
                 virtualmem             infinity   infinity
                 coredumpsize                  0   infinity
                 cputime                infinity   infinity
                 datasize               infinity   infinity
                 filesize               infinity   infinity
                 locks                  infinity   infinity
                 memlock                   65536      65536
                 msgqueue                 819200     819200
                 nice                          0          0
                 openfiles                  8192      65536
                 maxprocesses              63304      63304
                 rss                    infinity   infinity
                 realtimeprio                  0          0
                 rtimesched             infinity   infinity
                 sigspending               63304      63304
                 stack                   8388608   infinity
   mem-maps      RSS      PATH
                 381.4M   [anon]
                 62.8M    /opt/google/chrome/chrome
                 15.8M    /home/giampaolo/.config/google-chrome/Default/History
                 6.6M     /home/giampaolo/.config/google-chrome/Default/Favicons
                 [...]
   

   Other changes¶

   The full list is in the changelog.

4. Windows services support

   New psutil 4.2.0 is out. The highlight of this release is the support for Windows services (executables that run at system startup, similar to UNIX init scripts):

   >>> import psutil
   >>> list(psutil.win_service_iter())
   [<WindowsService(name='AeLookupSvc', display_name='Application Experience') at 38850096>,
    <WindowsService(name='ALG', display_name='Application Layer Gateway Service') at 38850128>,
    <WindowsService(name='APNMCP', display_name='Ask Update Service') at 38850160>,
    <WindowsService(name='AppIDSvc', display_name='Application Identity') at 38850192>,
    ...]
   >>> s = psutil.win_service_get('alg')
   >>> s.as_dict()
   {'binpath': 'C:\\Windows\\System32\\alg.exe',
    'description': 'Provides support for 3rd party protocol plug-ins for Internet Connection Sharing',
    'display_name': 'Application Layer Gateway Service',
    'name': 'alg',
    'pid': None,
    'start_type': 'manual',
    'status': 'stopped',
    'username': 'NT AUTHORITY\\LocalService'}
   

   I decided to do this mainly because I find pywin32 APIs too low levelish. Having something like this in psutil can be useful to discover and monitor services more easily. The code was implemented in PR-803. The API for querying a service is similar to psutil.Process. You can get a reference to a service object by using its name (which is unique for every service) and then use methods like WindowsService.name() and WindowsService.status():

   >>> s = psutil.win_service_get('alg')
   >>> s.name()
   'alg'
   >>> s.status()
   'stopped'
   

   Initially I thought about providing a full set of APIs to handle all aspects of service management, including start(), stop(), restart(), install(), uninstall() and modify(). However, I soon realized I would have ended up reimplementing what pywin32 already provides, at the cost of overcrowding the psutil API (see my reasoning here). I think psutil really focuses on monitoring, not on installing and modifying system components, especially something as critical as a Windows service.

   Considerations about Windows services¶

   Typically, a Windows service is an executable (.exe) that runs at system startup and continues running in the background. It is roughly the equivalent of a UNIX init script. All services are controlled by a "manager", which keeps track of their status and metadata (e.g. description, startup type). It is interesting to note that since (most) services are bound to an executable (and hence a process) you can reference them via their process PID:

   >>> s = psutil.win_service_get('sshd')
   >>> s
   <WindowsService(name='sshd', display_name='Open SSH server') at 38853046>
   >>> s.pid()
   1865
   >>> p = psutil.Process(1865)
   >>> p
   <psutil.Process(pid=19547, name='sshd.exe') at 140461487781328>
   >>> p.exe()
   'C:\CygWin\bin\sshd'
   

   Other improvements¶

   psutil 4.2.0 comes with 2 other enhancements for Linux:

   • psutil.virtual_memory() returns a new shared memory field. This is the same value reported by free cmdline utility.
   • I changed how /proc was parsed. Instead of reading /proc/{pid}/status line by line I used a regular expression. Here's the speedups:
     • Process.ppid() ~20% faster.
     • Process.status() ~28% faster.
     • Process.name() ~25% faster.
     • Process.num_threads() ~20% faster (on Python 3 only; on Python 2 it's a bit slower; I suppose the re module received some improvements).

   Discussion¶

   • Reddit
   • Hacker News

5. NetBSD support

   Roughly two months have passed since I last announced that psutil added support for OpenBSD. Today I'm happy to announce that it's the turn of NetBSD! This was contributed by Thomas Klausner, Ryo Onodera and myself in PR-557.

   Differences with FreeBSD (and OpenBSD)¶

   The NetBSD implementation has limitations similar to the ones I encountered with OpenBSD. Again, FreeBSD remains the BSD variant with the best support in terms of kernel functionality.

   • Process.memory_maps() is not implemented. The kernel provides the necessary pieces, but I haven't done this yet (hopefully later).
   • Process.num_ctx_switches()'s involuntary field is always 0. The kinfo_proc() syscall provides this info, but it's always set to 0.
   • Process.cpu_affinity() (get and set) is not supported.
   • psutil.cpu_count(logical=False) always returns None.

   As for the rest: it is all there. All memory, disk, network and process APIs are fully supported and functioning.

   Other enhancements available in this psutil release¶

   Besides NetBSD support, this release has a couple of interesting enhancements:

   • #708: [Linux] psutil.net_connections() and Process.connections() can be up to 3x faster when there are many connections.
   • #718: psutil.process_iter() is now thread safe.

   You can read the rest in the changelog, as usual.

   Move to Prague¶

   As a personal note I'd like to add that I'm currently in Prague (Czech Republic) and I'm thinking about moving down here for a while.

   Discussion¶

   • Reddit
   • Hacker News