mytop is one of my favorite tools and it is fairly simple aside from a few caveats and issues that persist to this day.
To install it on Centos:
yum -y install centos
Tired of checking iotop and seeing that your drbd partition is using 99.99% of io all the time and finding your drbd device performs slow in general?
This is especially an issue in versions of DRBD in the 8.3 tree in particular one documented case is on "8.3.13" but it likely applies to other devices.
The symptoms are that resyncing is fine and normal but any reasonable amount of activity is very slow and lagged and creates a high server load and con........
I have not found the source of this but essentially it seems like drbd and ext4 may not play well but I have to confirm still.
In either case an older DRBD setup with older hard drives seems to have little to no iowait, but the main difference is the drbd partition is ext3 and not ext4. I will experiment and see if that fixes this, then we will know that DRBD and ext4 have issues.........
This happened while an mdadm array was syncing, all access from writing a new blank file to opening a small .txt file was very slow:
[222117.312078] kjournald starting. Commit interval 5 seconds
[222117.685060] EXT3-fs (md0): using internal journal
[222117.685096] EXT3-fs (md0): mounted filesystem with ordered data mode
[222122.376847] kjournald starting. Commit interval 5 seconds
[222122.602825] EXT3-fs (md2): using internal jour........
The units in echo are kB as in kilobyte.
Setting a high sync speed
echo 120000 >/proc/sys/dev/raid/speed_limit_min
This will increase the speed, note that sometimes a rebuild is slow due to current disk activity/iowait.
If that is not the cause then you may have a hardware issue (controller, cable or a bad drive).
Setting a lower sync speed
echo 1200 >/proc/sys/dev/raid/speed_limit_max........
Here's a proven example of what a bad hard drive can do, it was technically functioning OKin a RAID array but the system became extremely low and the load become high and IOWAIT was even higher and I always thought it was a bad application. The truth is that this failing 1TBHitachi has slowly gotten worse and caused huge slowdowns, (eg. 100% load on Thunderbird waiting for e-mails to load etc..). After swapping it out, tabs change instantly, emails are not lagged, and........
I thought only a faster CPUand SSDwould help but I already have a Quad-Core CPU and it wasn't being maxed out. The actual tests were performed on an AMD-V enabled 128MB dual core VMWare container though.
There is a flag that can be passed to make in order to start multiple threads, by specifying 4 threads I was able to reduce the whole kernel compilation time from scratch by about 50%! (65minutes vs 31minutes!). *Yes I did do a make clean before each co........
high IO wait
424 root 39 19 1900 848 552 D 0.0 0.0 0:00.91 updatedb
root 424 0.0 0.0 1900 848 ? DN Mar11 0:00 /usr/bin/updatedb -f sysfs?rootfs?bdev?proc?cpuset?binfmt_misc?debugfs?sockfs?usbfs?pipefs?anon_inodefs?futexfs?tmpfs?inotifyfs?eventp........
The binary "iostat" comes from the package "sysstat" and is available on all Linux/Unix like platforms.
Use the "-m" option to give you what you probably want, which is to see in MB/s how much bandwidth each disk is doing.
Linux 18.104.22.168 ((none)) 04/16/10
avg-cpu: %user %nice %system %iowait %steal %idle
top - 09:34:12 up 2 days, 20:57, 2 users, load average: 1.83, 1.99, 2.03
Tasks: 59 total, 2 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st
That 99.7% wa is iowait, it means the server is waiting for a process to complete an IOoperation or in plain English, there is a delay in........