Comments on: MySQL 101: Monitor Disk I/O with pt-diskstats

By: Masroor Farooqi

Masroor Farooqi — Fri, 19 Sep 2014 23:21:31 +0000

gggeek Agreed. I was a database consultant for a long time, so I have seen my fair share of, lets say, architectural abuses 🙂 and it’s invaluable to know what is the disk spinning for. I have not personally used DRBD for database replication, but have for offsite backups (we used a proprietary block replication solution called Compellent). Anyway’s good to know for future.

Have a good one

By: gggeek

gggeek — Thu, 18 Sep 2014 18:46:38 +0000

In reply to Masroor Farooqi. @Masroor I pretty much agree. But as a web consultant, I often come across servers which are not dedicated to database serving, and they can host the webserver as well as memcache, solr, queueing services and whatnot. It is thus important to be able to easily tell apart IO coming from the different services, and which disks/partitions are being hit. And while NFS is not so good a choice for a db storage, using DRBD is quite a common practice to achieve high-availability setups.

By: Masroor Farooqi

Masroor Farooqi — Thu, 18 Sep 2014 18:37:31 +0000

I like that this is a read only tool. Combine that with fact that it polls /proc/diskstats means that one does not have to worry about additional overhead to the disk subsystem. As may be obvious to most readers of this post, I/O access is the most expensive operation that a database does and DBAs spend (or should spend) a lot of time fine tuning this. Careful use of a tool like this, or say, iostat should be a “must use” tool in any DBAs toolkit.

One point I’d like to make to gggeek in the context of databases is that please do not try to put database datafiles on NFS volumes. In fact, something like Oracle actually checks for NFS and if it finds its tablespaces are on NFS it will refuse to go online. This is because NFS is a no guarantee file subsystem. Couple that with the fact that it uses TCP as a transport mechanism and the result is that database access is (a) slow, and (b) not fully guaranteed.

By: Valerie

Valerie — Fri, 05 Sep 2014 23:17:54 +0000

Doesn’t work on FreeBSD. Sad face.

Cannot open /proc/diskstats: No such file or directory at /usr/local/bin/pt-diskstats line 3355.

By: Ernie Souhrada

Ernie Souhrada — Fri, 05 Sep 2014 08:26:19 +0000

NFS mounts are ignored; pt-diskstats collects its information from /proc/diskstats, which does not contain any information about NFS volumes. For DRBD volumes, both the actual physical disk and the DRBD volume will appear in the pt-diskstats output, often with very different numbers, since the DRBD metrics will include network and DRBD overhead but the physical device metrics will just be from the raw disk. The same is true for LVM, since you might have multiple LVs on a given PV or a singe LV spanning multiple PVs.

By: gggeek

gggeek — Thu, 04 Sep 2014 08:33:50 +0000

Pardon my ignorance, but how does this work for NFS mounts? Are they ignored, treated as physical disks, or something else? And drbdb volumes?

One of the things I often find hard to grok when looking at the output of the disk-statistics tools is how to map the data to the underlying physical disks – esp. when there are network filesystems and LVM at play