Tag Info

Hot answers tagged

14

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


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

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) ...


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 ...


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

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


3

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 ...


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

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, ...


2

I like using the collectl utility for this purpose. I mentioned this in another answer for someone looking for specific I/O statistics output for replay. You should be able to tailor the output to your specific needs. With Ubuntu, this should be available via the normal repositories. The caveat is that you won't see the percentages you are you looking for. ...


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

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. ...


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

Try iostat 1 or for more detailed view iostat -x 1 You should also check out command sar. Actually, in your case sar is probably what you want since you need the actual readings instead of averages. For example, sar -d 1 1 shows you I/O statistics.


2

cancelled_write_bytes: 349511680 For me this is due to truncate. As explained below: If a process writes 1MB to a file and then deletes the file, it will in fact perform no writeout. But it will have been accounted as having caused 1MB of write. mysql tmp files will be created and truncated accordingly which is the reason why you seeing those cancelled ...


2

Citing the iostat manpage: The first report generated by the iostat command provides statistics concerning the time since the system was booted, unless the -y option is used, when this first report is omitted. Each subsequent report covers the time since the previous report. This means that the first read will show a low value because ...



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