Tag Info

Hot answers tagged

11

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

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

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


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

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


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

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


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

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

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

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

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

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

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.


2

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


2

The svc_t time measures in milliseconds the "round trip": "bottom" of the operating system - disk subsustem - "bottom" of the operating system It is not completely correct that "100% busy means we're chocked on disk IO". This means that the disk was busy 100% of the time doing something, not necessarily that it cannot do more than this nor that it does not ...


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

dtrace is definitely the tool you are looking for. you can use a relatively simple script to find out which syscall is exactly most time-consuming. Something like this: #!/usr/sbin/dtrace -s syscall:::entry /execname == "iostat"/ { self->ts = vtimestamp; } syscall:::return /self->ts/ { @[probefunc] = sum(vtimestamp - self->ts); @["- ...


2

Yes, The iSCSI "mount" is really presented to your machine as a block device. From dmesg output... scsi3 : iSCSI Initiator over TCP/IP scsi 3:0:0:4: Direct-Access NEXENTA COMSTAR 1.0 PQ: 0 ANSI: 5 sd 3:0:0:4: Attached scsi generic sg3 type 0 sd 3:0:0:4: [sdc] Attached SCSI disk So... df -h shows: Filesystem Size Used Avail ...


2

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


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


2

Since the transfer rates are the same, the output you provide says to me that the MD layer caches transactions and then writes them to the physical disk in larger chunks. The slowness you're seeing with reloading the database is likely due to indexes, as you said. You can avoid this by just not having the indexes update as you load the data, then just ...



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