As from title dstat --thermal fails to run with message "Module dstat_thermal failed to load. (Needs kernel ACPI or IBM-ACPI support)." but as i say in title acpi support is present and working because I run dstat --battery (wich I read requires acpi too) and it worked just fine. My machine is an asus n35sv with 2nd gen sandy bridge running ubuntu 11.10 with all latest updates and kernel. Let me know if you need other info (please provide commands to run as I'm newbie on and I know only a few of them).

Edit:
I found out that cat /proc/acpi/thermal_zone/THM0/temperature is deprecated, /sys/bus/acpi/devices/LNXTHERM:00/thermal_zone/temp should be used instead. I might be mistaken but I tried cat with the second path on my system and it worked. I'm not a python programmer nor a linux expert so I wouldn't dare if not asked to try to patch the file but at least I found a workaround so that a willing expert or a mantainer could.
The discussion where I found the right path is : http://www.linuxquestions.org/questions/programming-9/how-to-get-cpu-temperature-in-linux-598658/

Edit2

I worked out a solution by myself. I forked the project and committed a new version of the file to my fork. I'll wait for someone to review it and merge it with the original branch if ok.

Hello,

I have been searching around for a while on this and havent found anyone else reporting it which is strange.

With certain NIC's and most definitely Intel 82580 it reports stats every other second and then it seems these are a total of the last 2 seconds.

I have attached a screenshot of the issue.

If there is a simple fix please let me know.

Thanks

When displaying total disk R/W data, the data for virtual lvm devices (dm-\d+) is included into the sum.

This leads to the display of doubled R/W performance.

Here is the output of the iostat 1:

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
cciss/c0d0        5.00         0.00         0.02          0          0
cciss/c0d1      712.00         0.00       132.64          0        132
cciss/c0d2      810.00         0.00       142.34          0        142
cciss/c0d3        0.00         0.00         0.00          0          0
dm-1              0.00         0.00         0.00          0          0
dm-0          34221.00         0.00       267.35          0        267

and the outpu of dstat -d --disk-util:

-dsk/total- c0d0-c0d1-c0d2-c0d3
 read  writ|util:util:util:util
   0   567M|2.40: 100: 100:   0
   0   566M|2.80: 100: 100:   0
   0   552M|2.40: 100: 100:   0

Howdy,

The 'discover' method of dstat_net looks as follows:

    def discover(self, *objlist):
        ret = []
        for l in self.splitlines(replace=':'):
            if len(l) < 17: continue
            if l[2] == '0' and l[10] == '0': continue
            name = l[0]
            if name not in ('lo', 'face'):
                ret.append(name)
        ret.sort()
        for item in objlist: ret.append(item)
        return ret

The l[2] corresponds to the number of received packets, and l[10] to the number of transmitted packets.

I wonder what the reason might be for filtering out interfaces that have not received or transmitted a packet yet?

We use dstat to dump to a log file at system start up at which point the counters for the interfaces, that we want to monitor, are still 0. With the current code, dstat_net would just skip these interfaces at its initialization time, and it would not actually monitor them.

Thanks in advance, and many thanks indeed for dstat :)

Tobias

I really like dstat and you seem to be neglecting it quite a bit. If you don't want to handle the maintenance, give someone else rights to merge stuff. There are quite a few bug reports and pull requests. If you don't take care of them, people might fork it to dstat-ng at some point.

I'm reading disk-util codes and get confuse about the disk utilization:

( (self.set2[name]['tot_ticks'] - self.set1[name]['tot_ticks']) * 1.0 * hz / elapsed / 1000, )

according to /proc/diskstat document, (https://www.kernel.org/doc/Documentation/iostats.txt), the io_ms = (self.set2[name]['tot_ticks'] - self.set1[name]['tot_ticks']) should be the milliseconds CPU time spend on IO on last period. and the elapsed is the elapsed CPU second time on last period. So I think the IO util should be io_ms / (elapsed * 1000). we can convert to percentage by multiply 100. why we need the hz in the formula. I think the hz is the jiffy number which exactly equal 100 in my linux. I think we will get wrong result in system which's jiffy is not 100.

Thanks for the great tool! Thought I should report this since dstat has been so handy the last year or so...

I get the following error when trying to output to .csv:
[root@dar_server]# dstat -tv --output dar.out
Traceback (most recent call last):
File "/usr/bin/dstat", line 2665, in ?
main()
File "/usr/bin/dstat", line 2526, in main
scheduler.run()
File "/usr/lib/python2.4/sched.py", line 105, in run
void = action(*argument)
File "/usr/bin/dstat", line 2624, in perform
oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
File "/usr/bin/dstat", line 553, in showcsv
line = line + printcsv(self.val[name])
File "/usr/bin/dstat", line 541, in printcsv
return '%d' % round(var)
TypeError: int argument required

Outputting to console with the same args works fine. Also, an older version of dstat works OK. By older, I mean one copied from about a year ago that I had laying around.

Both scripts say the same version, but they have a different number of lines...
VERSION = '0.7.2svn'

This error ONLY occurs on one server (out of 4 running this version) when outputting to .csv and using the most recent version of the dstat script that is up on the github repository (0.7.2.svn ???) .

*This used to work before. But suddenly, it started throwing the IndexError as shown below. This happened on a Xen VM running Ubuntu *

Traceback (most recent call last):
File "/usr/bin/dstat", line 2554, in
main()
File "/usr/bin/dstat", line 2416, in main
scheduler.run()
File "/usr/lib/python2.7/sched.py", line 117, in run
action(*argument)
File "/usr/bin/dstat", line 2514, in perform
oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
File "/usr/bin/dstat", line 542, in showcsvend
if self is not vislist[-1]:
IndexError: list index out of range

When 'chrome' (Google Chrome or Google Chromium) is the top-oom process, the output looks like this:

moria ~ # dstat --top-oom
--out-of-memory---
    kill score    
 --enable-expe328 
 --enable-expe328 
 --enable-expe328

This happens very likely due to the parsing of the process list in the top-oom plugin, which probably uses a regex or split matching on a /.

The process list entry of a running Chrome/Chromium looks like this:

29447 ?        Sl     0:28 /usr/lib64/chromium-browser/chrome --type=renderer --lang=en-US --force-fieldtest=CacheListSize/CacheListSize_14/ConnCountImpact/conn_count_6/ConnnectBackupJobs/ConnectBackupJobsEnabled/DnsImpact/default_enabled_prefetch/DnsParallelism/parallel_default/GlobalSdch/global_enable_sdch/IdleSktToImpact/idle_timeout_10/Instant/InstantControlB/Prefetch/ContentPrefetchPrerender1/PrerenderFromOmniboxHeuristic/OriginalAlgorithm/ProxyConnectionImpact/proxy_connections_32/SpdyCwnd/cwnd16/SpdyImpact/npn_with_spdy/WarmSocketImpact/last_accessed_socket/ --enable-experimental-extension-apis --enable-print-preview --channel=98765.0xbeefec0de.123456789

JFI, by default gpfs plugin doesn't work:

# dstat --gpfs
/usr/bin/dstat:1674: DeprecationWarning: os.popen3 is deprecated.  Use the subprocess module.
  pipes[cmd] = os.popen3(cmd, 't', 0)
Module dstat_gpfs failed to load. (global name 'select' is not defined)
None of the stats you selected are available.

To fix I modify main dstat source:

 try:
     import sys, os, time, sched, re
     import types, resource, getpass, glob
+    import warnings, select
+    warnings.filterwarnings('ignore', category=DeprecationWarning, message=r'os\.popen3')
     addpath(os.path.expanduser('~/.dstat/'))                                # home + /.dstat/
     addpath(os.path.abspath(os.path.dirname(sys.argv[0])) + '/plugins/')    # binary path + /plugins/
     addpath('/usr/share/dstat/')

Warnings thing is optional just to hide warning, but include select is actually to make gpfs plugin(s) work. Otherwise readpipe() doesn't work.

I'm using Dstat 0.7.2 included in Linux Mint 16 (~ Ubuntu 13.10)
Kernel 3.11.0-12-generic
Python 2.7.5+ (default, Sep 19 2013, 13:48:49)
[GCC 4.8.1]

The "----swap---" heading is only printed once, even though I have two swap partitions mounted, which both do get stats printed. This causes the headings to be misaligned.

----system---- ----total-cpu-usage---- --dsk/sda-----dsk/sdb-- -net/wlan0- ---paging-- ---system-- ------memory-usage----- ----swap--- ---load-avg---
     time     |usr sys idl wai hiq siq| read  writ: read  writ| recv  send|  in   out | int   csw | used  buff  cach  free| used  free| 1m   5m  15m 
11-12 23:34:52| 25   0  75   0   0   0|   0     0 :   0     0 | 270B 1560B|   0     0 | 494   446 |5451M 1444k 4309M  126M|  15G   15G:   0    40G|1.11 1.39 1.24
11-12 23:34:53| 25   0  74   1   0   0|   0     0 :   0     0 | 539B 1874B|   0     0 | 497   476 |5452M 1444k 4309M  125M|  15G   15G:   0    40G|1.10 1.38 1.24
11-12 23:34:54| 25   0  75   0   0   0|   0     0 :   0     0 | 192B  780B|   0     0 | 482   438 |5452M 1444k 4309M  125M|  15G   15G:   0    40G|1.10 1.38 1.24

Hi,

I just learnt about and installed dstat, and it promises to be a permanent addition to my toolset. Thanks.

While experimenting, I noticed that the option --nocolor also enables --noheaders. However, while I prefer not having any colors, I still want to run it in a terminal, and so, not having a line of headers on the screen after dstat has been running for some time is quite inconvenient.

Could you consider separating these two, so that a colorless display with headers is still possible ?

I prefer green for low usage / idle, and red for high usage which is the opposite of the current behavior (e.g. cpu usage, cpu frequency, disk throughput). Is it possible to switch color behavior?

I recently installed dstat on a cent 6.6 server in an attempt to find what processes are taking up the IO on the box, however I need the PIDs and not the names, because the only results will be 'java' as that's what all the servers run off. The -adv plugins should have the PIDs, except none of them exist in the install and I cant find anything at all about them other then they should exist...

Here is the error I get - Thank you

$ dstat -t --top-io-adv  --output dstat.csv
Traceback (most recent call last):
  File "/usr/bin/dstat", line 2554, in ?
    main()
  File "/usr/bin/dstat", line 2416, in main
    scheduler.run()
  File "/usr/lib64/python2.4/sched.py", line 105, in run
    void = action(*argument)
  File "/usr/bin/dstat", line 2514, in perform
    oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
  File "/usr/share/dstat/dstat_top_io_adv.py", line 75, in showcsv
    return self.val['i/o process'] + 'Top: %s\t%s\t%s\t%s' % (self.val['name'][0:self.width-20],      self.val['read_usage'], self.val['write_usage'], self.val['cpu_usage'])
KeyError: 'i/o process'


[root@ ~]$ python -V
Python 2.4.3

The first line of dstat output always has wrong values for CPU usage (and others). While this is okay for interactive use, it is not practical for use with the --noupdate option (if I just want 1 line):

With default settings, interactively ("top" says my CPU is really ~88% all the time, this is a database server under load):

$ dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
 57   9  32   1   0   1|  87k 2570k|   0     0 |   0     0 |4035  3331 
 86  13   1   0   0   2|   0  3896k| 342k  640k|   0     0 |6138  5254 
 86  13   0   0   0   1|   0  3468k| 348k  657k|   0     0 |6179  5098 
 85  14   0   0   0   1|   0  3552k| 353k  658k|   0     0 |6240  5164

I am running a database server and have a script calls dstat with arguments to only print one line and exit. This is the output:

$ dstat -cldnypmgs --tcp -D total --noupdate --nocolor 1 0 
----total-cpu-usage---- ---load-avg--- -dsk/total- -net/total- ---system-- ---procs--- ------memory-usage----- ---paging-- ----swap--- ----tcp-sockets----
usr sys idl wai hiq siq| 1m   5m  15m | read  writ| recv  send| int   csw |run blk new| used  buff  cach  free|  in   out | used  free|lis act syn tim clo
 51   8  39   1   0   1|29.8 30.0 22.9| 105k 2373k|   0     0 |3625  2996 |0.0 0.0 5.3| 395M 93.5M  468M 6498M|   0     0 |   0     0 |  4  92   0   0   0

However, the real CPU usage is much higher (top says around 88%). This only shows up after the second line. Here is the output for 3 lines:

$ dstat -cldnypmgs --tcp -D total --noupdate --nocolor 1 2 
----total-cpu-usage---- ---load-avg--- -dsk/total- -net/total- ---system-- ---procs--- ------memory-usage----- ---paging-- ----swap--- ----tcp-sockets----
usr sys idl wai hiq siq| 1m   5m  15m | read  writ| recv  send| int   csw |run blk new| used  buff  cach  free|  in   out | used  free|lis act syn tim clo
 53   8  37   1   0   1|28.3 29.6 23.8|  98k 2446k|   0     0 |3776  3118 |0.0   0 4.9| 395M 94.1M  475M 6490M|   0     0 |   0     0 |  4  92   0   0   0
 84  16   0   0   0   1|28.3 29.6 23.8|   0  3664k| 336k  631k|6003  4971 | 35 1.0   0| 395M 94.1M  475M 6490M|   0     0 |   0     0 |  4  92   0   0   0
 85  15   0   0   0   1|28.4 29.6 23.9|   0  4132k| 339k  634k|6038  4912 | 31 1.0   0| 395M 94.1M  476M 6490M|   0     0 |   0     0 |  4  92   0   0   0

This also happens when running interactively, the first line always has wrong values for some columns. Also, this happens if I set the window size to a higher value, e.g. one line for 10 seconds:

dstat -cldnypmgs --tcp -D total --noupdate --nocolor 10 0
----total-cpu-usage---- ---load-avg--- -dsk/total- -net/total- ---system-- ---procs--- ------memory-usage----- ---paging-- ----swap--- ----tcp-sockets----
usr sys idl wai hiq siq| 1m   5m  15m | read  writ| recv  send| int   csw |run blk new| used  buff  cach  free|  in   out | used  free|lis act syn tim clo
 55   9  35   1   0   1|27.6 28.6 24.2|  93k 2506k|   0     0 |3897  3218 |  0   0 4.7| 395M 94.7M  479M 6486M|   0     0 |   0     0 |  4  92   0   0   0

My dstat version is

$ dstat --version
Dstat 0.7.0
Written by Dag Wieers <[email protected]>
Homepage at http://dag.wieers.com/home-made/dstat/

Platform posix/linux2
Kernel 3.4.66-55.43.amzn1.x86_64
Python 2.6.8 (unknown, Mar 14 2013, 09:31:22)
[GCC 4.6.2 20111027 (Red Hat 4.6.2-2)]

Terminal type: screen (color support)
Terminal size: 69 lines, 175 columns

Processors: 2
Pagesize: 4096
Clock ticks per secs: 100

internal:
        aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp,
        unix, vm
/usr/share/dstat:
        battery, battery-remain, cpufreq, dbus, disk-util, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, memcache-hits, mysql-io,
        mysql-keys, mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3, nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, rpc, rpcd, sendmail,
        snooze, thermal, top-bio, top-cpu, top-cputime, top-cputime-avg, top-io, top-latency, top-latency-avg, top-mem, top-oom, utmp, vm-memctl, vmk-hba, vmk-int, vmk-nic,
        vz-cpu, vz-io, vz-ubc, wifi

When I use the option --snooze, nothing is displayed in the snooze column.

From what I can see, it seems that dstat gets the colors wrong: when using a display interval larger than 1, the intermediate values are displayed, but the final one isn't. Also, when running dstat in a script session, the script log file does show the values.
When I run dstat with --nocolor, the values are displayed correctly.

Example contents of script file (command: dstat --snooze):
ESC[7lESC[0;34msnoozeESC[0;0m
ESC[1;34mESC[4msnoozeESC[0;0m
ESC[0;0m -ESC[1;30m
ESC[0;0mESC[2KESC7ESC[1;37m1.0011ESC[1;30m
ESC[0;0mESC[2KESC7ESC[1;37m0.9999ESC[1;30m
ESC[0;0mESC[2KESC7ESC[1;37m0.9998ESC[1;30m

I am running dstat 0.7.2 on debian testing.

Edit: my terminal has a white background. With a non-white background, it appears that the text is white. The option '--bw' does not make a difference...

For instance I only want to display "/" mountpoint size, I don't need /run or /dev mountpoints size

dstat --cpufreq
Module dstat_cpufreq failed to load. (Cannot access acpi cpu0 frequency information)

It appears to work if I edit dstat_cpufreq.py and change scaling_cur_freq to cpuinfo_cur_freq although I'm not clear on the wisdom in that.

grep . /sys/devices/system/cpu/cpu0/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:830875
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:3900000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:3900000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>

--battery and --power fail due to "Module dstat_power failed to load. ([Errno 2] No such file or directory: '/proc/acpi/battery/')" which sucks since this dir is /sys/class/power_supply/BAT1 in modern Linux systems.

Traceback (most recent call last):
  File "/usr/bin/dstat", line 2554, in <module>
    main()
  File "/usr/bin/dstat", line 2416, in main
    scheduler.run()
  File "/usr/lib64/python2.7/sched.py", line 117, in run
    action(*argument)
  File "/usr/bin/dstat", line 2510, in perform
    o.extract()
  File "/usr/share/dstat/dstat_top_int.py", line 40, in extract
    total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
IndexError: list index out of range

0.7.2-r1 on gentoo.
also https://bugs.launchpad.net/ubuntu/+source/dstat/+bug/910038

It would be useful to support plugins to enable development of different output types - not just CSV.

For example, I want to run a performance test accross a very large number of clusters and I may choose to stream this data out to somewhere else and analyse runtime rather than copy CSV files and ingest etc..

Command:

dstat -cmdn --output logfile.txt 60

Problem:

Negative numbers appeared in the read and write columns of the disk stat.

Expected result:

Never give negative values.

The log file:
https://gist.github.com/log69/7839547

Negative values are at line 789 and 807 in the disk read and write columns.

Another problem is that dstat reprints the headers from time to time in the log file, no matter whether I specify --noheaders parameter or not.

System:

Dstat 0.7.2
Kernel 3.8.0-34-generic
Python 2.7.4 (default, Sep 26 2013, 03:20:26)
[GCC 4.7.3]
Terminal type: screen (color support)
Terminal size: 43 lines, 134 columns
Processors: 2
Pagesize: 4096
Clock ticks per secs: 100

Currently distros are still using the version 0.7.2 from 2012. I think a new release should be considered.

I upgraded my rhel5 machione with the latest version from dstat-0.7.2-1.el5.rfx.noarch.rpm. I have tried the new 'top' options. Out of all the top otions this command (top-io-adv) fails:
[root@xxxxxxxxx ~]# /usr/bin/dstat --noheaders --nocolor -t --top-io-adv --output /tmp/collect_stats/dstat6_test 1
Traceback (most recent call last):
File "/usr/bin/dstat", line 2554, in ?
main()
File "/usr/bin/dstat", line 2416, in main
scheduler.run()
File "/usr/lib64/python2.4/sched.py", line 105, in run
void = action(*argument)
File "/usr/bin/dstat", line 2514, in perform
oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
File "/usr/share/dstat/dstat_top_io_adv.py", line 75, in showcsv
return self.val['i/o process'] + 'Top: %s\t%s\t%s\t%s' % (self.val['name'][0:self.width-20], self.val['read_usage'], self.val['write_usage'], self.val['cpu_usage'])
KeyError: 'i/o process'

Hello.
I'd like to use --wifi on a raspberry pi with a tenda N150 dongle but the values are always:

|lnk s/n
| -   -

I went into the source and removed the qual.noiselevel == -256 check from this line of the dstat_wifi plugin:

if qual.quality == 0 or qual.signallevel == -101 or qual.noiselevel == -101 or qual.signallevel == -256 or qual.noiselevel == -256:

to read:

if qual.quality == 0 or qual.signallevel == -101 or qual.noiselevel == -101 or qual.signallevel == -256:

and it begun to show my link and signal levels as expected.

Why is a noise level of -256 always ignored? I don't know what this means but I guess my specific dongle always has a value of -256.

I could make a new plugin as a workaround but I was curious about it.

With -p option, the run and blk columns under procs section seem to have proc_running/proc_blocked divided by the delay parameter when output to csv file.

I have a 12 core machine and want to look at all 12 cores individually during a (very) long run of a job. the problem is that when I try to specify -C 0,1,2,3,4,5,6,7,8 or more I get a traceback and error report.

CORRECT:

# dstat -c -C 0,1,2,3,4,5
-------cpu0-usage--------------cpu1-usage--------------cpu2-usage--------------cpu3-usage--------------cpu4-usage--------------cpu5-usage------
usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq
  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0
  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0
  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0:  0   0 100   0   0   0

CORRECT but I get no output:

# dstat -c -C 0,1,2,3,4,5,6,7,8                   
Terminal width too small, trimming output.

Try outputting to a file and get error:

# dstat -c -C 0,1,2,3,4,5,6,7,8 --output dstat.out
Terminal width too small, trimming output.


Traceback (most recent call last):
  File "/usr/bin/dstat", line 1974, in ?
    main()
  File "/usr/bin/dstat", line 1923, in main
    oline = oline + o.showcsv() + o.showcsvend(totlist, vislist)
  File "/usr/bin/dstat", line 447, in showcsvend
    if self is not vislist[-1]:
IndexError: list index out of range

samuel@samuel-Lenovo-B560:~$ dstat --net

-net/total-

recv  send

0     0

12G   12G

8192M 8192M

4096M 4096M

12G   12G

8192M 8192M

4096M 4096M

16G   16G

8192M 8192M

4096M 4096M

12G   12G

8192M 8192M

4096M 4096M

12G   12G

8192M 8192M

4096M 4096M

12G   12G

12G   12G

4096M 4096M

4096M 4096M

12G   12G

Unfortunately, I'm definitely not getting 12GiB/s over WiFi.

I often use dstat to watch performance on several sequential tasks (e.g. shell script). It will be great if instead of default time to update counters, there is update-on-request e.g. on SIGUSR1.

Right now I can manually do it by starting dstat with a very log update interval and press Enter when the other task finishes, but haven't seen a way to automate that and cannot use --output. In other words for long and complex tasks (e.g. compile firefox) it is useless.

What I want is basically one update per (user defined) process, so that I can send SIGUSR1 to a running dstat, execute what I want to time and send SIGUSR1 again.

If anybody thinks it is a good idea, there can be SIGUSR1 to start the timer (and reset counters) and SIGUSR2 to stop the timer (and output counters).

Hi,

I am trying to use dstat to measure network numbers (bandwidth usage as well as sockets) while I run some performance tests using wrk. But I feel something is not right ..
Here is the output of dstat

-net/total- ----tcp-sockets---- ------sockets------
 recv  send|lis act syn tim clo|tot tcp udp raw frg
   0     0 | 12   3   0   0   0|195  10   2   0   0
  64B  220B| 12   3   0   0   0|195  10   2   0   0
  64B  204B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
 637B  188B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
  64B  188B| 12   3   0   0   0|195  10   2   0   0
2915k 5462k| 12 468   0   0   0|660  10   2   0   0
4959k 9690k| 12 612   0   0   0|804  10   2   0   0
4829k 9571k| 12 612   0   0   0|804  10   2   0   0
4843k 9455k| 12 804   0   0   0|996  10   2   0   0
4787k 9487k| 12 804   0   0   0|996  10   2   0   0
4803k 9515k| 12 804   0   0   0|996  10   2   0   0
4806k 9523k| 12 804   0   0   0|996  10   2   0   0
4801k 9398k| 12   1   0   0   0|  1  10   2   0   0
4722k 9356k| 12   1   0   0   0|  1  10   2   0   0
4718k 9348k| 12   1   0   0   0|  1  10   2   0   0
4734k 9380k| 12   1   0   0   0|  1  10   2   0   0
4771k 9454k| 12   1   0   0   0|  1  10   2   0   0
4731k 9373k| 12   1   0   0   0|  1  10   2   0   0
4730k 9373k| 12   1   0   0   0|  1  10   2   0   0
4731k 9373k| 12   1   0   0   0|  1  10   2   0   0
4735k 9383k| 12   1   0   0   0|  1  10   2   0   0
4783k 9477k| 12   1   0   0   0|  1  10   2   0   0
4705k 9322k| 12   1   0   0   0|  1  10   2   0   0
4713k 9340k| 12   1   0   0   0|  1  10   2   0   0
4730k 9373k| 12   1   0   0   0|  1  10   2   0   0
4751k 9411k| 12   1   0   0   0|  1  10   2   0   0
4739k 9392k| 12   1   0   0   0|  1  10   2   0   0
4726k 9363k| 12   1   0   0   0|  1  10   2   0   0
4731k 9375k| 12   1   0   0   0|  1  10   2   0   0
4725k 9363k| 12   1   0   0   0|  1  10   2   0   0
4786k 9482k| 12   1   0   0   0|  1  10   2   0   0
4732k 9377k| 12   1   0   0   0|  1  10   2   0   0
4732k 9375k| 12   1   0   0   0|  1  10   2   0   0
4722k 9358k| 12   1   0   0   0|  1  10   2   0   0
4725k 9363k| 12   1   0   0   0|  1  10   2   0   0
2652k 5238k| 12   3   0   0   0|195  10   2   0   0
  64B  204B| 12   3   0   0   0|195  10   2   0   0

See how 'act' connections grow to 804 and immediately reduce to 1 even if my wrk bench mark is running for next 20seconds with 1000 connections to this server. Wrk doesn't show any errors. So the code under test is working fine.

Whats happening here?

Btw, I am running dstat on Ubuntu box with this -
Dstat 0.7.2
Linux jupitor 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks,
Siddharth

Modern server frequently have many CPUs so detailed output of dstat for cpu become very long and don't fit into the screen, being that it gets "trimmed" i.e. deleted.

I request feature to make shorter all-cpu output, which should show only cpu load per cpu. So instead of 7 columns per cpu 'usr sys idl wai hiq siq stl' it will be just one, which should be sum of (usr sys wai hiq siq stl) or just (100 - idle). Such way it will be possible to see 7 times more cpus than now.

Additional useful improvement to that would be to show two column per cpu: load and iowait time. Load should be sum of (usr sys hiq siq stl) and iowait is wai (as I understand). That would be useful to see if cpu is actually crunching.

Whenever I try to use the freespace plugin to show disk usage, it always says terminal is too small:

$ sudo dstat --freespace
Terminal width too small, trimming output.

I've tried this on a very wide HDTV, with or without tmux, and always the same result.

Screenshot

On a 1920 x 1080 (1080p) HDTV screen, error still shows:

Reproducible: Always

Dstat Version

$ dstat --version
Dstat 0.7.2
Written by Dag Wieers <[email protected]>
Homepage at http://dag.wieers.com/home-made/dstat/

Platform posix/linux2
Kernel 3.10.0-229.20.1.el7.x86_64
Python 2.7.5 (default, Jun 24 2015, 00:41:19)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]

Terminal type: xterm-256color (color support)
Terminal size: 63 lines, 238 columns

Processors: 2
Pagesize: 4096
Clock ticks per secs: 100

internal:
  aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp, unix, vm
/usr/share/dstat:
  battery, battery-remain, cpufreq, dbus, disk-tps, disk-util, dstat, dstat-cpu, dstat-ctxt, dstat-mem, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, memcache-hits, mysql-io, mysql-keys,
  mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3, nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, qmail, rpc, rpcd, sendmail, snooze, squid, test, thermal, top-bio, top-bio-adv, top-childwait,
  top-cpu, top-cpu-adv, top-cputime, top-cputime-avg, top-int, top-io, top-io-adv, top-latency, top-latency-avg, top-mem, top-oom, utmp, vm-memctl, vmk-hba, vmk-int, vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

dstat was installed via RPM package on CentOS 7:

$ rpm -qi dstat
Name        : dstat
Version     : 0.7.2
Release     : 12.el7
Architecture: noarch
Install Date: Mon 09 Nov 2015 11:38:29 PM UTC
Group       : System Environment/Base
Size        : 769542
License     : GPLv2
Signature   : RSA/SHA256, Fri 04 Jul 2014 01:10:28 AM UTC, Key ID 24c6a8a7f4a80eb5
Source RPM  : dstat-0.7.2-12.el7.src.rpm
Build Date  : Tue 10 Jun 2014 02:45:28 AM UTC
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://dag.wieers.com/home-made/dstat/
Summary     : Versatile resource statistics tool
Description :
Dstat is a versatile replacement for vmstat, iostat, netstat and ifstat.
Dstat overcomes some of their limitations and adds some extra features,
more counters and flexibility. Dstat is handy for monitoring systems
during performance tuning tests, benchmarks or troubleshooting.

Dstat allows you to view all of your system resources instantly, you
can eg. compare disk usage in combination with interrupts from your
IDE controller, or compare the network bandwidth numbers directly
with the disk throughput (in the same interval).

Dstat gives you detailed selective information in columns and clearly
indicates in what magnitude and unit the output is displayed. Less
confusion, less mistakes.

$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
$ uname -a
Linux ec2-12-34-56-78.us-east-1.compute-1.amazonaws.com 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ python --version
Python 2.7.5

vmstat's swap in/out feature is very helpful in IO hang situation,could dstat also add this feature?

You have included some mysql plugins from [email protected] (this e-mail address is dead) into the Dstat 0.7.2 distribution, but in fact they are flawed and useless. For example dstat_mysql5_cmds.py doesn't show rate value of its variables (for example sel/Com_select), but show three major digits stripped of counter absolute value. For example:

[root@db dstat]# dstat --mysql5-cmds
------mysql5-cmds------
sel ins upd del
83 5 12 3
376 23379 52652 12796
376 23379 52652 12796
376 23379 52652 12796
376 23379 52652 12796
376 23379 52652 12796
376 23379 52652 12796
376 23379 52652 12796^C

Note that since second line values don't change. And in fact these values are even wrong, becasue "376" is meaningless number. If I change in /usr/share/dstat/dstat_mysql5_cmds.py self.width= from 5 to 11 output is like this:

[root@db dstat]# dstat --mysql5-cmds
------------------mysql5-cmds------------------
sel ins upd del
83 5 12 3
375980511 23379218 52652264 12796384
375980525 23379221 52652267 12796385
375980536 23379221 52652268 12796385
375980575 23379223 52652279 12796388
375980604 23379227 52652284 12796389^C

This is more meaningful, but still not very useful, as rate value would be more appropriate and expected (similar to dstat output model of other statistics.)

What values are in the first line (where '83') I don't even understand.

Currently all mysql plugins in dstat 0.7.2 is like this.

[root@db dstat]# dstat --mysql5-io
-mysql5-io-
recv sent
96.9k 1706k
421G 7413G
421G 7413G
421G 7413G
421G 7413G^C
...and same value continue on many lines. Which is not i/o rate at all. And first line values is obscure again.

I'm on a Centos 5.8 host running OpenVZ and just stumbled over the available plugins for monitoring vz's. Playing with them I had no luck in succcessfully getting any output. All I get are these traces, but my python knowledge doesn't bring me that far.

[root@ned dstat]# dstat --vz-cpu
Module dstat_vz_cpu is still experimental.
Traceback (most recent call last):
File "/usr/bin/dstat", line 2554, in
main()
File "/usr/bin/dstat", line 2416, in main
scheduler.run()
File "/usr/lib64/python2.6/sched.py", line 117, in run
action(*argument)
File "/usr/bin/dstat", line 2510, in perform
o.extract()
File "/usr/share/dstat/dstat_vz_cpu.py", line 52, in extract
if len(l) < 6 or l[0] == 'VEID': continue
NameError: global name 'l' is not defined

I don't understand why l is not recognized. My vestat output seems to look like in the example. But how I understand the error output the object iteration does not really work well.

For IO I get this:
[root@ned dstat]# dstat --vz-io
Module dstat_vz_io is still experimental.
Traceback (most recent call last):
File "/usr/bin/dstat", line 2554, in
main()
File "/usr/bin/dstat", line 2416, in main
scheduler.run()
File "/usr/lib64/python2.6/sched.py", line 117, in run
action(*argument)
File "/usr/bin/dstat", line 2510, in perform
o.extract()
File "/usr/share/dstat/dstat_vz_io.py", line 52, in extract
for line in dopen('/proc/bc/%s/ioacct' % veid).readlines():
File "/usr/bin/dstat", line 1672, in dopen
raise Exception, 'File %s does not exist' % filename
Exception: File /proc/bc/total/ioacct does not exist

It's absolutely true that there is no /proc/bc/total. But I guess the plugin should concat the available VE's.

[root@ned dstat]# dstat --vz-ubc
Module dstat_vz_ubc is still experimental.
Traceback (most recent call last):
File "/usr/bin/dstat", line 2554, in
main()
File "/usr/bin/dstat", line 2416, in main
scheduler.run()
File "/usr/lib64/python2.6/sched.py", line 117, in run
action(*argument)
File "/usr/bin/dstat", line 2510, in perform
o.extract()
File "/usr/share/dstat/dstat_vz_ubc.py", line 62, in extract
self.val[name] = (self.set2[name] - self.set1[name]) * 1.0 / elapsed
TypeError: unsupported operand type(s) for -: 'long' and 'list'

These errors stay unchanged after I switch python to python26. So it does not seem to relate to the language. Still I guess it's to simple for me to see the issue.

I installed dstat-0.7.2-1.el5.rfx.noarch.rpm. (rhel5)

Now the nfs3-ops module does not run:

[root@xxxxxxxxxxxxxx ~]# dstat --nfs3-ops
Module %s is still experimental.
Module dstat_nfs3_ops failed to load. (unsupported operand type(s) for %: 'NoneType' and 'str')
None of the stats you selected are available.

I am trying out the ne top options. The csv output is horribly scrambled:
Fo example:
[root@xxxxxxxxxxxx ]# rm /tmp/collect_stats/dstat6_test
rm: remove regular file `/tmp/collect_stats/dstat6_test'? y
[root@xxxxxxxxxxxx]# /usr/bin/dstat --noheaders --nocolor -t --top-bio --top-cpu-adv --top-oom --output /tmp/collect_stats/dstat6_test 1
----system---- ----most-expensive---- -------most-expensive-cpu-process------- --out-of-memory---
time | block i/o process |process pid cpu read write| kill score
21-02 11:39:04|sshd 127k 24k|kjournald 3194 0.0% 0 0 |layoutPlus 93k
21-02 11:39:05|layoutPlus 168k 248k|layoutPlus 310582.5% 58k 15k|layoutPlus 93k
21-02 11:39:06|pim 0 16k|layoutPlus 310582.8%8909B 22k|layoutPlus 93k
[root@xxxxxxxxxxxxx~]# cat /tmp/collect_stats/dstat6_test
"Dstat 0.7.2 CSV output"
"Author:","Dag Wieers [email protected]",,,,"URL:","http://dag.wieers.com/home-made/dstat/"
"Host:","cam-bc26-b10",,,,"User:","root"
"Cmdline:","dstat --noheaders --nocolor -t --top-bio --top-cpu-adv --top-oom --output /tmp/collect_stats/dstat6_test 1",,,,"Date:","21 Feb 2012 11:39:04 GMT"

"system","most expensive","most expensive cpu process","out of memory"
"time","block i/o process","process pid cpu read write","kill score"
21-02 11:39:04,sshd / 130068:24314,kjournald 3194 0.0% 0 0 Top: kjournald 0.00417118897096 0.0 0.0,layoutPlus / 93693%
21-02 11:39:05,layoutPlus / 172032:253952,layoutPlus 310582.5% 58k 15kTop: layoutPlus 2.5 59670.0 15285.0,layoutPlus / 93416%
21-02 11:39:06,pim / 0:16384,layoutPlus 310582.8%8909B 22kTop: layoutPlus 2.75 8909.0 22196.0,layoutPlus / 93755%

Hello ;)

I've been playing around with a httpd (apache) plugin, I'd need to display byte values, integers and float values, all as different vars of one plugin. Is there a good way to achieve this?

Thanks, Peter

Currently we use a comma as separator for the CSV output, and when implementing I thought that made most sense. However a semicolon is less common to be used inside the output/string as a comma.

Besides a comma is used in Europa as a radix point, rather than the dot. And therefore the default separator used by Excel/LibreOffice is configured to be a semicolon.

What do you think ?

Changing might have impact to people already processing it with a comma.

It would be nice to be able to monitor eg. NMIs or TLBs

dstat -tcin -C total -I eth0,eth1,ppp0,nmi,spu,pmi,iwi,tlb,mcp -N bond0,eth0,eth1,ppp0

It frequently happens that a line has extra breaks. Specifically, it only seems to happen happen when I add these two columns: dstat --top-bio --top-io provokes the error. Also, the header frequently disappears for as many line scrolls as extra newlines. Please let me know if you need more information.

screenshot

terminal

I usually run urxvt v9.18 (urxvt256c-ml), but it also happens in xterm v7.6.0. I also usually run in tmux, but it also happens in a normal shell, even a virtual console.

version info

% dstat --version
Dstat 0.7.2
Written by Dag Wieers <[email protected]>
Homepage at http://dag.wieers.com/home-made/dstat/

Platform posix/linux2
Kernel 3.9.9-302.fc19.x86_64
Python 2.7.5 (default, Jul  8 2013, 09:48:59) 
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)]

Terminal type: rxvt-unicode-256color (color support)
Terminal size: 54 lines, 239 columns

Processors: 8
Pagesize: 4096
Clock ticks per secs: 100

internal:
    aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp, unix, vm
/usr/share/dstat:
    battery, battery-remain, cpufreq, dbus, disk-tps, disk-util, dstat, dstat-cpu, dstat-ctxt, dstat-mem, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, memcache-hits, mysql-io, mysql-keys, 
    mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3, nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, qmail, rpc, rpcd, sendmail, snooze, squid, test, thermal, top-bio, top-bio-adv, top-childwait, 
    top-cpu, top-cpu-adv, top-cputime, top-cputime-avg, top-int, top-io, top-io-adv, top-latency, top-latency-avg, top-mem, top-oom, utmp, vm-memctl, vmk-hba, vmk-int, vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

Just learned this is possible. Dstat should try to do the right thing by default:
https://lwn.net/Articles/665053/

Hi,

Many thanks for dstat, I've found it very useful for ad-hoc monitoring. I've been struggling with what seemed like weird results, and I think I've found the problem.

$ dstat -ms --output out.csv 1 5

stdout:

------memory-usage----- ----swap---
 used  free  buff  cach| used  free
3955M  891M 2777M 48.6M|   0  4094M
3955M  891M 2777M 48.6M|   0  4094M
3955M  891M 2777M 48.6M|   0  4094M
3955M  891M 2777M 48.6M|   0  4094M
3955M  891M 2777M 48.6M|   0  4094M

out.csv

"Cmdline:","dstat -ms --output temp.csv 1 5",,,,"Date:","26 Apr 2014 14:28:19 BST"
"memory usage",,,,"swap",
"used","free","buff","cach","used","free"
4146851840,934621184,2911694848,50966528,306008064,77385728,20946944,0,4292866048
4146851840,934621184,2911694848,50966528,306008064,77385728,20946944,0,4292866048
4146851840,934629376,2911686656,50974720,305999872,77385728,20946944,0,4292866048
4146851840,934629376,2911686656,50974720,305999872,77385728,20946944,0,4292866048
4146851840,934617088,2911686656,50974720,306008064,77385728,20951040,0,4292866048

Note that although there are only 6 header fields, there are 9 fields of raw data. Taking a quick look at dstat_mem

self.nick = ('used', 'free', 'buff', 'cach')
self.vars = ('MemTotal', 'MemUsed', 'MemFree', 'Buffers', 'Cached', 'Shmem', 'SReclaimable')

it seems that the CSV gets every variable defined (7 of them) but the headers are based on the number of nicks. This means the labels are out of sync for every field coming after memory.

Thanks!

dstat is an amazing tool, however I frequently used to resort to iostat on our EC2 instances as %steal is a very important metric for us.

Looking at the TODO, it still says this needs to be added to --cpu-adv plugin, however running dstat --cpu-adv it is clear it is already implemented.

It would be great to update the docs so that people know this exists.

Note for anyone reading this

The version of dstat available from apt-get or other Debian based installers does not support --cpu-adv, I had to git clone this repo and run the binary directly.

dstat/examples/mstat.py doesn't work.

~/projects/dstat>./examples/mstat.py 
You did not select any stats, using -cdngy by default.
Traceback (most recent call last):
  File "./examples/mstat.py", line 35, in <module>
    title = title + '  ' + o.title()
  File "/mnt/DNAvertex/akislyuk/projects/dstat/examples/dstat.py", line 453, in title
    width = self.statwidth()
  File "/mnt/DNAvertex/akislyuk/projects/dstat/examples/dstat.py", line 441, in statwidth
    return len(self.nick) * self.colwidth() + len(self.nick) - 1
TypeError: object of type 'NoneType' has no len()

Also, the module shouldn't do stuff like print "You did not select any stats, using -cdngy by default." on import.

$dstat --net
-net/total-
 recv  send
   0     0 
  78B  184B
4096M 4096M
4096M 4096M
4096M 4096M
4096M 4096M
  19B 4096M
 772B 1396B
4096M 4096M
4096M 4096M
4096M 4096M
4096M 4096M
  19B   39B
4096M 4096M
4096M 4096M
4096M 4096M
4096M 4096M
 772B 1396B
4096M 4096M
4096M 4096M
4096M 4096M

$uname -a
Linux xxx 3.2.0-32-generic-pae #51-Ubuntu SMP Wed Sep 26 21:54:23 UTC 2012 i686 i686 i386 GNU/Linux

In case of traffic it seems to work correctly (here downloading image at ubuntu.com):

$ dstat --net
-net/total-
 recv  send
   0     0 
1663k   31k
 403k 8577B
1594k   29k
1390k   25k
1658k   31k
 962k   18k
 232k 5394B
1041k   21k
1659k   30k
1460k   27k
1657k   30k
1285k   24k
1658k   30k
1656k   31k
1661k   31k
 810k   15k
 291k 6168B
 506k   11k
1070k   21k
1660k   30k
1661k   31k
1656k   30k

I know this issue has been discussed a while ago but it seems to be reoccuring...Any ideas?

The nfs3 plugin calculates a 'readdir' statistic which is the sum of fields 17 and 18 in /proc/net/rpc/nfs. However comparing the contents of this file with the output of the 'nfsstat' command shows that 'readdir' should be fields 18+19. Also the 'filesystem value should be fields 20+21+22 (not 19+20+21) and the 'commit'' value should be field 23 and not 22

# cat /proc/net/rpc/nfs
net 0 0 0 0
rpc 3753467 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 0 1602112 28201 101419 220208 27 493468 1108826 84987 4140 4 0 62226 1112 2682 6 0 2003 41991 52 0 0
proc4 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
# cat /proc/net/rpc/nfs;nfsstat -c -3
net 0 0 0 0
rpc 3753827 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 0 1602333 28201 101451 220238 27 493468 1108848 85009 4140 4 0 62248 1112 2682 6 0 2003 42002 52 0 0
proc4 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Client rpc stats:
calls      retrans    authrefrsh
3753827    0          0       

Client nfs v3:
null         getattr      setattr      lookup       access       readlink     
0         0% 1602333  42% 28201     0% 101451    2% 220238    5% 27        0% 
read         write        create       mkdir        symlink      mknod        
493468   13% 1108848  29% 85009     2% 4140      0% 4         0% 0         0% 
remove       rmdir        rename       link         readdir      readdirplus  
62248     1% 1112      0% 2682      0% 6         0% 0         0% 2003      0% 
fsstat       fsinfo       pathconf     commit       
42002     1% 52        0% 0         0% 0         0% 

E.g. for disk I/O 5.4 MB are displayed as 5411k (yellow) and 11 MB are displayed as 11M (green). The proposed option would change this behaviour use the next suffix earlier, so that after 1023k (yellow) comes 1M (green). This is more natural too me, as to me 5 MB are 5 MB and not 5something kb. The change in colour is also something that would feel more natural too me, like "ah, we're at megabytes now". I know this is a loss in precision, so it should be an option. Anybody else seeing the described behaviour as more natural or intiuitive?