GNOME Bugzilla – Bug 499725
should include graphical interface to iotop
Last modified: 2018-05-22 12:03:21 UTC
System Monitor should include a GUI for iotop: http://guichaz.free.fr/misc/#iotop I've often wished to have this information; it would be great to put in system-monitor.
I know about iotop for a long time, but as long as it's not enabled more widely / not experimental, we have to wait.
By not enabled more widely, you mean the relevant kernel interfaces? Or something else?
Yes, it's a linux kernel option.
*** Bug 506407 has been marked as a duplicate of this bug. ***
Is there any project to develop such an interface like this for the kernel?
It already exists but it's not a very popular option for now
And do you know a command line tool that does this, but not written in python?
No. The programing language is irrelevant. What is needed is stable kernel API and have its relative configuration option enabled by default.
Thanks for your explanations! Which kernel option should I enable to run iotop?
CONFIG_TASK_IO_ACCOUNTING
mmm I cannot find this option neither in 2.6.22 nor in 2.6.24 (both from ubuntu) is this option so new?
No, IIRC, it was added in 2.6.21.
*** Bug 320358 has been marked as a duplicate of this bug. ***
*** Bug 530523 has been marked as a duplicate of this bug. ***
Maybe there could be a check to see if IO accounting is enabled in the kernel? In any case the code could be added but disabled until the appropriate time comes.
Even Debian ;) enables this by default now, the lack of disk throughput monitoring is really quite sad.
*** Bug 587871 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Even Debian ;) enables this by default now, the lack of disk throughput > monitoring is really quite sad. I concur. If you have multiple drives and want to understand where your bottlenecks are, this is a handy tool. It's also useful for figuring out how much thrashing your VM is doing when you don't have enough RAM.
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
Created attachment 223603 [details] gnome-system-monitor file system tab I have had an attempt at implementing I/O by extending the existing file systems tab. The implementation can pull a lot of stats but I have limited the display to whatever gnome-system-monitor currently does (it mainly focuses on partitions, but you can get overall device I/O however we'd need to change the way the data is presented. Probably best to do it by device with sub-tree for each partition or similar. Anyway, it works so let me know your thoughts about the attached screen shot.
Pretty nice, however I would like to have the option to show/hide columns, as most users will not want to see all the columns, only some of them. I have been thinking of adding the preferences for the disks table just as we have for the processes table ( to be able to save the visible columns + their widths in preferences), and wanted to do it to fix bug 431660, but to avoid code duplication (as we already have a similar for the processes table) system monitor could use a bit of refactoring. It would be nice if you could update your code to add the preferences for showing/hiding columns, but even if not, please attach your code here for a review, as I would be interested in having this in the File Systems tab. Are all the fields shown in columns retrieved from glibtop?
*** Bug 712705 has been marked as a duplicate of this bug. ***
Any news on the disk io monitoring in system monitoring ? What Greg did is a nice start, but what about a graph like for the CPU, MEM and NET ?
Right now this is not on the roadmap, at least not before implementing Usage (https://wiki.gnome.org/Design/Apps/Usage). However, feel free to provide patches, they will surely get reviewed in a timely manner and eventually merged.
I will put some information here, just in case someone want to make "quick" patches to GNOME System Monitor, instead of developing GNOME Usage: # What Add two more columns to GNOME System Monitor's "processes" tab: 1 - An IO equivalent to "% CPU", showing the percentage (or just the amount of MB/s) of IO that each process is currently doing. 2 - An IO equivalent to "CPU Time", showing how much each process wrote to the local disks since boot. # Use case A user who wants to know how much (and how) each process is using the disks, to: 1 - Overcome a bad behavior who is causing trouble (slowness on HDDs, or wear on SSDs) or make personal optimizations. 2 - Report results to the downstream, who, then, can take some actions to fix or improve something to all other users.
In addition to iotop, it would be good to have a frontend to lsof integrated into GNOME System Monitor. (lsof can consist of hundreds of thousands of entries, so there would need to be a good filtering system in place.)
(In reply to Luke Hutchison from comment #26) > In addition to iotop, it would be good to have a frontend to lsof integrated > into GNOME System Monitor. (lsof can consist of hundreds of thousands of > entries, so there would need to be a good filtering system in place.) Lsof is already integrated, see the "Search for Open files" from the appmenu for global lsof, "Open files" from the process context menu for a per-process open files list.
Nice, how did I miss that? Sorry for the spam.
I would also like to see a graphical representation of disk usage too. I see this has been opened since 2007, I hope this is something that is being looked at.
*** Bug 768476 has been marked as a duplicate of this bug. ***
For anyone interested in testing, I have a working version up and running on the wip/diskio branch of system-monitor, comments, feedback, and testing would be welcome. I'd like to have some testing before merging into master. Be aware that running it requires the latest version of libgtop, 2.37.2.
-- 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/gnome-system-monitor/issues/17.