Re: Measuring IOPS

[Jens Axboe <axboe@kernel.dk>]

On 2011-08-04 12:23, Martin Steigerwald wrote:
>> Not quite measuring RAM (or copy) performance, at some point fio will
>> be blocked by the OS and prevented from dirtying more memory. At that
>> point it'll either just wait, or participate in flushing out dirty
>> data. For any buffered write workload, it'll quickly de-generate into
>> that.
> 
> Which depends on the size of the job, cause I for bet 1 GB/s with 250000 
> IOPS I need some PCI express based SSD solution - a SATA-300 SSD like the 
> Intel SSD 320 in use here can´t reach this (see attached file). It seems 

Right, you'll need something state-of-the-art to reach those numbers,
and nothing on a SATA/SAS bus will be able to do that. Latencies and
transport overhead are just too large.

> with 8 GB of RAM I need more than one GB to write in order to get 
> meaningful results (related to raw SSD performance). With Ext4 delayed 
> allocation a subsequent rm might even cause the file to not be written at 
> all.

Depending on the kernel, some percentage of total memory dirty will kick
off background writing. Some higher percentage will kick off direct
reclaim. So yes, the usual rule of thumb for buffered write performance
is that the job size should be at least twice that of RAM to yield
usable results.

> For the application side of thing it can make perfect sense to measure 
> buffered writes. But one should go with a large enough data set in order to 
> get meaningful results. At least when the application uses a large dataset 
> too ;).

Indeed.

-- 
Jens Axboe