Hot answers tagged

17

ls -l /dev/mapper/*, the device minor number (field 6 of what ls -l outputs) corresponds to the number in dm-\d+.


9

Depending on the version of iostat you have the -N option will do this for you: -N Display the registered device mapper names for any device mapper devices. Useful for viewing LVM2 statistics. Edit: versions >= 7.1.4 of systat (which includes iostat) have that option. 2007/04/29: Version 7.1.4 - Sebastien Godard (sysstat wanadoo.fr) ...


9

It means that the load is due to IO wait, not CPU contention. So, accessing a hard drive, accessing an NFS share, accessing swap space (and hence (usually) a local hard drive... I'm not sure if pure network access contributes to this, but my gut says no. NFS just adds to it because it uses the FS layer. "top" usually has a "wait" or "iowait" percentage ...


7

Iostat is part of the sysstat package. You can download and install the sysstat RPM and you should get what you're looking for. After downloading the package to your server, call "rpm -i package_name" You should be able to get the sysstat RPM from the RedHat Network, but here's another link: http://rpmfind.net/linux/rpm2html/search.php?query=sysstat


6

that's a single iostat invocation, which does not provide meaningful data for "per second" values, only counters are useful - it can not calculate change per second from a single value, it needs to know two values and time between them. to see real values, try something like : iostat -d 1 2 second output will be real values. from iostat manpage: "The ...


6

I ran into the same problem (on an EC2 instance running Ubuntu Lucid Lynx) and figured out the solution via a comment at the top of the plugin code. Basically the plugin by default skips all hard drives which have a number in them. To avoid this you need to add the following lines to the plugin config file (/etc/munin/plugin-conf.d/munin-node for me - I ...


5

I know RTFM is not the answer you are looking for, but this time it is appropriate. Try man iostat, all the values are explained there. In case you are somehow missing the man pages, here's a webified version, although your Linux distribution might have a more current version of that man page.


5

The following articles will give you a better idea about iostat. I always use iostat -x . http://mituzas.lt/2009/03/11/iostat/ http://www.igvita.com/2009/06/23/measuring-optimizing-io-performance/


5

The fact that your device is /dev/xvdb1 implies that you're running under Xen. How is your storage configured? Is there contention for the underlying device, and how does iostat look on that? Unless you can eliminate that as likely, that's where I'm going to point the whirling spinner of poor performance blame. Basically, the overall approach to untangling ...


5

The source code for iostat has a cut off of 100% on the calculation for %util. Either your version of iostat has some modification in this computation and it doesn't mean what it normally means or something very strange has happened. Take a look at lines 381 and 382 in the iostat.c source: if (busy > 100.0) busy = 100.0; ...


4

AWS overcontend their VM servers; they're assuming that not everyone will be consuming all the resources allocated to them, and so Amazon can make more money per unit of hardware deployed. Thus you can have two otherwise-identical systems running with wildly different performance patterns. The correlation with the upgrade is likely to be a coincidence. A ...


4

This seems practical only if you can afford the downtime for the disk check. Also note that you would need to automatize this somehow. So for me it looks more reasonable to monitor the SMART data of your disks. Check out smartd, for example. If you have a RAID (which is standard for production servers), then you should configure your RAID software to ...


4

Some of the concepts in the Windows kernel differ significantly from those in Linux, this is why you do not see an iowait counter in Perfmon. First, the entity of scheduling in Windows is a thread, not a process. A process is just a container for 1+ threads. Additionally, Windows does not define an uninterruptible sleep state for its threads (more ...


4

IOSTAT provides stats for individual block devices, and won't tell you which process is actually driving IO. However, it's useful for characterizing your I/O access patterns. You can generate a large log-file with this command: iostat -x sda -c 2 -t > stats.log This will monitor sda (-x sda) every 2 seconds (-c 2) with a timestamp (-t). The logfile is ...


3

http://www.linuxinsight.com/proc_sys_vm_block_dump.html Set vm.block_dump for a second, and then turn it off immediately (sysctl -w ... ; sleep 1; sysctl -w ...). dmesg then reveals all the low-down.


3

As you already used iotop,I am not sure how much this is useful,but you can use systemtap like stap -v iotop.stp and it will give you output Process KB Read KB Written Xorg 21 0 crond 10 0 wfica 2 0


3

iowait, as a measure of system load, is only a problem inasmuch as it's consuming CPU time that could be reasonably used by other processes. If you've still got idle CPU time, then high iowait (in and of itself) is not a problem. On the other hand, a high iowait can be a symptom of a problem; however, you really should be profiling your application to see ...


3

Disk utilisation is more important, you can measure that with: iostat -xm 5 it will probably say close to 100%


3

you can try lsblk command which shows the Logical Volume used by respective dev-mapper. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 8G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 7.5G 0 part ├─vg_root-lv_root (dm-0) 253:0 0 ...


3

ls -l /dev/disk/by-id/ should do the trick


3

iowait is basically The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them. Measured on a per io basis from the front of the io scheduler until io is done. It covers the time that is taken through scheduler, driver, controller, ...


3

iostat is part of the sysstat package (yum whatprovides "*/iostat"). You need to download the sysstat RPM package. Where to download is a bit tricky, if I remember correctly the Red Hat repos are not publicly available. If you have another Red Hat server (same version) with Internet, you can run yumdownloader --destdir /tmp/ sysstat. That will download ...


3

I followed the way from this post, using SystemTap tool. Fisrt, install systemtap. For Debian/Ubuntu: apt-get install systemtap linux-image-$(uname -r)-dbg linux-headers-$(uname -r) Create systemtap script, save as blockio.stp: global writes global reads probe ioblock.request { if(bio_rw_num(rw) == BIO_WRITE) writes[devname] <<< ...


3

The best answer I can give you is "iowait is too high when it's affecting performance." Your "50% of the CPU's time is spent in iowait" situation may be fine if you have lots of I/O and very little other work to do as long as the data is getting written out to disk "fast enough". Conversely it could be catastrophic if the server is doing a high amount of ...


2

"High" is entirely subjective. Any metric is "high" when it is causing a degradation in service quality beyond what is acceptable to whomever you are providing the service to.


2

I'm not sure how to get the iostat formatting you're looking for. The tool I use for this type of monitoring, though, is customizable to the point where you could display the relevant fields. It's also excellent for generating data for replay and graphing purposes. I use Collectl monitoring (available in CentOS via yum), and the disk check flags should give ...


2

Assuming a recent version of Linux, I'd look at the iotop utility. You don't mention your distribution of Linux, but the tool is available for most in the default package repositories.


2

To answer it simply, yes. The main indicator is the 53.2% wait time on the CPU. If your I/O wait percentage is greater than (1/# of CPU cores) then your CPUs are waiting a significant amount of time for the disk subsystem to catch up. Inserts create disk write I/O, and that's generally the worst kind for virtual disks with a hard disk drive subsystem. HDDs ...


2

Also, don't keep staring at load alone. It's quite cantankerous. Your I/O-states and CPU-states are easier to read and less likely to lie to you. To give you an example: make ten nfs-mounts. Take de nfs-server down. Your box has now a load of 10 (and a bit) and no I/O or CPU-usage to speak off. Your nfs-mounts want to know when the nfs-server comes back. ...



Only top voted, non community-wiki answers of a minimum length are eligible