I'm trying to estimate IOPS requirements of my application running on 32-bit CentOS 6.2. I started to take some measurement on a machine with SATA disks and I'm quite confused of difference between IOPS and tps measured by sar.

According to wikipedia SATA disk should perform 75-100 IOPS. ioping utility seems to confirm this for random access test:

It does not really mind if this load is sequential (dd with various block sizes) or random access (ioping), value is still the same. I thought tps actually is IOPS and I would expect it go down with larger chunks transferred.

So what exactly does the tps value mean? And how does it relate to IOPS?

I believe you're seeing higher IOPS in the TPS value because of disk cache.
–
ceejayozDec 1 '13 at 20:48

Ok, I tried a 10GB file through dd with 256kB block to actually fill the cache and after ~90 seconds tps drops to ~200, so maybe you're right. But still 80 and 200 is quite a difference... Is it possible that read and write IOPS differ? And is there any way to figure out required IOPS from this value?
–
pystoleDec 1 '13 at 21:34

1

Can you describe why your are after IOPS? read and write are quite a different pair of shoes that get thrown into the same pot here.
–
NilsDec 1 '13 at 22:18

The reason is I need to describe a minimum HW requirements. I have a server that receives data over network (we can assume constant bitrate here) and writes received data to disk. Data is written to files sequentially but there could be hundreds (e.g. 800) of them in parallel. I have figured out that when number of clients reach some point I start to get large iowaits. Actual disk throughput I can achieve is about 25MB/s which is quite low, less clients with higher bitrate can do 35MB/s, pure sequential about 130MB/s. So I guess IOPS is what matters here...
–
pystoleDec 1 '13 at 22:44

2 Answers
2

Transactions are single IO-commands (fetch block/write block) that are written to the RAW-disk (in your example dm-0). The linux-kernel tries to order those commands into a better sequence or tries to compress them into more efficient commands (like: get two blocks at once instead of get one block and get another block right after this one). These are the transactions that go out to the disk-controller (tps for sda).

Good controllers migth have a logic of their own that reduce the real number of transactions further.

A transaction might be the SCSI-command "write 2 GB to crontoller 1 target 2 lun 3 starting from sector 22). As you can see this can not be brought into direct correlation with throughput-numbers.

What you are after is the sustained write-rate. You have a couple of limiting factors here:

client-connection: If the network is Gigabit you will never have more than 100 MB/s input

disk-controller: If this is a 3 Gb controller you will never have more than 300 MB/s throughput

disk: Look up the manufacturers value for sustained write performance

Filesystem: There is a little overhead since the OS needs to process data - test that in a RAM-disk...

My guess for your system is: Get a good hardware-raid-controller that is capable of doing raid 10 or 5 and get at least 6 fast (15k) disks.