GNOME Bugzilla – Bug 768304
Add support for querying per-process disk and network stats
Last modified: 2018-01-10 19:53:36 UTC
More and more requests come in for per-process disk IO or network IO monitoring. I'm not sure how this can be implemented in a cross-platform way, /proc/PID/net/netstat contains the network IO details (at least I see two numbers occasionally changing, one must be the upload, the other the download, but not detailed in man proc), and /proc/PID/io (since kernel 2.6.20). Having methods to query these for the processes with the processlist would be nice to have.
Hello Robert, I can definitely do it but we there are 2 prerequisites: - define the API. what stats do we need beside disk read and writes and network in and out - look into the performance. some time ago the get_proc_map calls where remove system-monitor but I'm not convinced that they were the real bottleneck: i feel that the main problem could be that the treeview is very slow to update/render (hence various hacks in system-monitor). then back to first point: is it really faster to get the stats for all processes at once or not Then, implement for linux first (and see if netlink can be faster). In the meantime, system-monitor could also have a way to `ionice` a job (if you can get your head around those 1KLOC of dbus wrappers)
Gnome shell extension "system monitor" would definitely be a user of these features (see https://github.com/elvetemedve/gnome-shell-extension-system-monitor/issues/4) - were prerequisites solved and/or did you encounter any other blocker here?
(In reply to Gautier Pelloux-Prayer from comment #2) > Gnome shell extension "system monitor" would definitely be a user of these > features (see > https://github.com/elvetemedve/gnome-shell-extension-system-monitor/issues/ > 4) - were prerequisites solved and/or did you encounter any other blocker > here? No, prerequisites have not been solved due to maintainer (my) unavailability, will do my best to respond to Benoît Dejean's request for defining the API, performance-tuning is something to do afterwards. I can't promise anything, but given that more and more people are asking for this, and more and more clients are reporting that they would need this (gnome-shell-extension-system-monitor, gnome-usage), and it would be a really nice-to have, I will try to define the API this week, let's see when can we tackle this.
(In reply to Benoît Dejean from comment #1) > - define the API. what stats do we need beside disk read and writes and > network in and out Regarding other stats: * for IO (/proc/PID/io) we will need rchar, wchar, read_bytes, write_bytes, and cancelled_write_bytes, I don't see a need for syscr and syscw * for net (/proc/PID/net/*) based on other tools (nethogs'n'friends) what we would need is read_bytes, write_bytes (read_bandwidth, write_bandwidth will be calculated by the client, I think), however I'm not sure how we can find those values, /proc/PID/net/* seems to only show interface-global values, not really per-process values :( I just saw that nethogs "provides" an experimental libnethogs, but I'm not sure if we should depend on nethogs just for this (one major issue is licensing, I think, as system-monitor and libgtop are GPLv2, nethogs is GPLv3, so I'm not sure if it is legal to mix these). I have tried understanding the nethogs source, but I did not manage by taking a short look. @Benoît Dejean * any idea on how to get per-process net information? unfortunately the kernel docs are not really verbose on /proc/PID/net/* * your thoughts on the metrics (io or net), what would make sense for you?
Created attachment 345273 [details] [review] New API to retrieve process io stats, with Linux implementation
I would appreciate if anyone could take a look at my initial attempt to provide /proc/PID/io based per-process io stats. This being my first feature implementation in a library based on copy/replace/compile/try cycles, don't be afraid to comment, feedback is very welcome, especially in the following areas: * I have only tested this on linux, the example application compiled and has read the relevant information, but I'm not sure if there's anything to do avoid compilation failure on other operating systems, e.g. BSDs * I'm not sure what version numbers do I have to change (server version, age, etc., so I did not change anything) This probably will not get released in time for GNOME 3.24 (we're close to API/ABI/feature freeze), but it would be great if it would get in early in the next cycle, as several people have reported the need for this, and several applications will benefit from this : gnome-shell-extension-system-monitor, Gnome Usage, System Monitor.
Hello Robert, that looks great, sorry I did not have time to show you. You also need to update ./features.def. This will definitely go in the next cycle (would also need to bump the libtool numbers in configure.ac) with some testing. I also need to have a look at what FreeBSD provides. And it would be wise to even inclue some reserved fields.
Hi, We [the GNOME Foundation] will have an Outreachy intern working on implementing a Network panel for GNOME Usage. It would be very convenient if the data presented in GNOME Usage would come from libgtop (since the performance/memory data is already libgtop based). Is someone already working on the network part of it? If not, our intern could be assigned for the task.
(In reply to Felipe Borges from comment #8) > Hi, > > We [the GNOME Foundation] will have an Outreachy intern working on > implementing a Network panel for GNOME Usage. > > It would be very convenient if the data presented in GNOME Usage would come > from libgtop (since the performance/memory data is already libgtop based). > > Is someone already working on the network part of it? If not, our intern > could be assigned for the task. No one is working on the network part, as far as I know, I did work out the disks IO related part, as I could find the source of information for that, but I couldn't figure out where to get per-process network traffic. It would be great to have someone implement this, I happen to need something like this more and more often.
I'm not aware of any linux software that does it. My only idea would be to use libcap (or bfp ?!) but that sounds like heavy machinery to do so.
(In reply to Benoît Dejean from comment #10) > I'm not aware of any linux software that does it. My only idea would be to > use libcap (or bfp ?!) but that sounds like heavy machinery to do so. I'm using libcap to implement this, I have mailed you with the details, you may have a look.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgtop/issues/34.