2

I'd like to make sure that I'm measuring IOPS correctly across Windows and Linux servers. We're busy trying to figure out which SAN would best suit our environment and measuring IOPS across our servers is the kind of thing I just can't get wrong. Little bit of procurement paranoia kicking in.

On the Windows servers I'm using the \PhysicalDisk(_Total)\Disk Reads/sec and \PhysicalDisk(_Total)\Disk Writes/sec performance counters. On the Linux servers I run vmstat and am looking at the bi (read) and bo (write) counters. I'm pretty sure that I've got this right and that both sets of counters equate to IOPS.

If these counters are correct then I have a problem. The SAN we're going for can handle about 1600 IOPS. Our two mail filter servers, which run MailScanner, MailWatch and Sophos, are hitting around 1500 IOPS collectively. Our two MySQL server run at about 1600 IOPS collectively. We're way over the 1600 IOPS theoretical limit.

Hence the question, am I measuring correctly?

Ossan

Athanasios
  • 355
  • 1
  • 2
  • 7
  • What do you mean when you say IOPS? – MadHatter Jan 28 '11 at 08:15
  • Hi MadHatter, IOPS would be block reads/writes per second. – Athanasios Jan 28 '11 at 08:39
  • 1
    In that case, may I say that your SAN is no good? 1600 blocks/s with 512-byte blocks means 800kB/s, and that's pretty awful. I say this not to criticise your SAN, which I'm sure is lovely, but to bring to light that I think you're not comparing apples with apples. Can you shed more light on the SAN in question, and the limit? – MadHatter Jan 28 '11 at 09:37
  • 1
    IOPS are not blocks. IOPS are requests, which most of the time bare bigger (example: SQL Server makes 64kb IO to 256kb IO). A disc riges between 100 and 450 IOPS, a SSD sometimes 30.000. – TomTom Jan 28 '11 at 09:39
  • Seems you guys have answered my question, thanks a lot. A number of articles state that the Windows PhysicalDisk Disk Read/sec and Disk Write/sec perf counters are definitely used to measure IOPS, but what about the Linux side? Both vmstat and iostat measure blocks in/out per second. – Athanasios Jan 28 '11 at 10:17
  • I spot a fundamental problem with your numbers, I don't know what SAN you are looking at, but it is most likely speced at **random IOPS**, often speced in 4 KB blocks. A SAN that does 1600 random IOPS is pretty decent, I would say that you could do that with 12-16 SAS disks in RAID10. The same SAN can probably do tens of thousands of IOPS if sequential reads or writes. – 3molo Apr 06 '12 at 19:13

3 Answers3

2

Following on from the comment thread above, iostat -dxk 1 will give you r/s and w/s (read and write requests/sec) as well as kbytes read and written.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
0

Possibly. Raid 5 is slow for updates. I never have seen Raid 5 used in high perofrmance setups, unless you count Raid 0s over multipel raid 5's as such (Raid 50, 60). On top, seriously - a 5 disc raid 5 is not a "SAN" as "able to handle 100.000thousands of IOPS". It is an end user thingy.

Note the difference: Backup ismost likely not writing out randomly and / or read operrations on a Raid are faster than write.

TomTom
  • 50,857
  • 7
  • 52
  • 134
  • Hi TomTom, I've removed the part about the backups as I realised it isn't relevant. The backup server has a 5 disk RAID 5 set, not the SAN we're looking at. I do apologise for not being clear enough. – Athanasios Jan 28 '11 at 08:38
0

Two important points here:

  1. be careful using your existing numbers -- depending on the workload, your current usage may reflect what the underlying storage is capable of. For example, you may see mysql using 1600 iops now because that's what those disks can do. If you put it on a SAN that can do 3000 iops, say, then mysql might start doing 3000 iops, and your queries would return faster. Talk with your vendor to properly size based on your workload.

  2. It's important to consider both iops and throughput (MBps), since they are not necessarily proportional and either can be a bottleneck at various points in the SAN -- disk, controller, hba, network, etc. Which of these will apply to you depends on how sequential or random your workload and the i/o size. Again, talk with your vendor to properly size based on your needs.

carillonator
  • 805
  • 3
  • 12
  • 22