# Cheapest solution for maximized disk-IO?

## qeldroma

Hi again,

for a database, i need an extremly fast disk. The problem is not the bandwidth but the io, meaning many, many selects on about 70GB of data with hardly no possible caching!

My first idea was to build a raid1 with three or more SATA-disks, redundancy is not needed here. Unfortunately, i found some discouraging statistics about software raid 1 under Windows with multiple disks from gamers, so i know the speed isn't that much bigger.

I believe, that the reason is that typical sata-controllers are not good enough for multiple disk raid1-usage, athough i am not sure. 

And SAS is far to expensive...

Then i thought about SSD, but 70GB is a lot of money, too.

Anyone got experiences and revolutionary ideas for this?

Cheers, Florian

----------

## alex.blackbit

you wrote *Quote:*   

> My first idea was to build a raid1 with three or more SATA-disks, redundancy is not needed here.

 

could it be that you mean RAID-0, instead of RAID-1 ?

take care when it comes to SATA RAID controllers. most of them are fake.

real RAID controllers cost some money, e.g. 3WARE or adaptec 5xxx series. they bring reasonable performance.

a RAID-0 with some disks _will_ be fast enough for you.

----------

## qeldroma

Ups, yes, of course  :Sad: 

RAID0   :Embarassed: 

had too many RAID ones in the past ....   :Rolling Eyes: 

----------

## energyman76b

SSDs of the cheaper kindsuck at multiple IO. Very hard. And the expensive SSD are so expensive, that you can get some ultra fast 15k rpm scsi drivers for less. And those are good with io

(btw, I think he really meant raid 1 - it can stripe read access). 

Get a good scsi controller or a good raid controller. Software raid sucks in windows, but not so much in linux. Still, hw raid does have its advantages. Beware:

mainboard 'raid' is not hardware raid!

edit:oops too. raid0 - really?

----------

## qeldroma

Yes, i am aware of the hard- and software raid-differences, of course. But as the CPU isn't really affected while work's in progress(<20%), i would be able to do software-raid w/o reducing performance seriously.

If i do RAID0 with sata, i'ld maximize the bandwidth of course, but the access-time keeps the same as the slowest disk, because all are accessed in parallel and the raid0 controller waits until all are done.

So i wouldn't maximize IO/sec with building sata-based raid0 afaik..

ATM, SSD seems to be difficult to predict if used for database-access. Seems, that theese are more or less build for massive sequential access, but not random read-write access(although 300 - 3.500 IO/sec are not that bad  :Wink:  ).

Ok, seems that i am "forced" to think about scsi/sas...

Cheers, Florian

----------

## qeldroma

 *energyman76b wrote:*   

> (btw, I think he really meant raid 1 - it can stripe read access). 

 

I heard of it, but couldn't realize any performance increase under linux wile reading on software raid 1...

Perhaps this is only availlable on some hardware-controllers?

----------

## energyman76b

no, software raid in linux(md) does stripe reading access with raid1 bydefault, but:

if the data fetched is small, you have 0 advantage because most time is lost on seeking.

----------

## alex.blackbit

 *qeldroma wrote:*   

> Yes, i am aware of the hard- and software raid-differences, of course. But as the CPU isn't really affected while work's in progress(<20%), i would be able to do software-raid w/o reducing performance seriously.

 

your cpu(s) do not get hot because so much time is wasted waiting for I/O.

if you have fast I/O, you will have cpu load. and that's good, believe me.

----------

## qeldroma

You're right, didn't think of that..

----------

## HeissFuss

 *energyman76b wrote:*   

> SSDs of the cheaper kindsuck at multiple IO. Very hard. And the expensive SSD are so expensive, that you can get some ultra fast 15k rpm scsi drivers for less. And those are good with io
> 
> 

 

Yes, cheap SSDs suck.  However, decent SSDs really shine with random IO and multiple IO due to the fact that you aren't waiting on head movement.  A single SSD will outperform multiple spinning disks (even 15k ones) for random read/write activity.  The other factor is that read access is about 0.2ms consistently for reads and depending on the drive write latencies of 0.5-1.5ms.  This allows for a lot more IO operations per second, which is exactly the factor you want to maximize for random access.

For a good description of SSD performance, see this.

For an example, say you need to read 1000 4k blocks at random locations on the disk.  For SSD, that's 1000 * 0.2ms = 0.2s.  For a 15k SAS drive with a random seek time of 5ms (that's actually faster than any listed drive) 1000 * 5 = 5s.  For the same number of write requests, assuming a case of 1.5ms on SSD, 1.5s vs 5s for SAS.

For Random seek times of 15k SAS, see  this.

Now, this is assuming that's you're doing a lot of small block accesses in a very random manner.  For SAS drives, they have an advantage for blocks near each other.  For your 4k read access, you may get a good chunk of the blocks next to it since the drive had to read over that section of the disk anyway.  For SSD, you only get what you asked for.  Also, decent SSDs will cost 2-3x more than 15k SAS drives.

----------

## energyman76b

also scsi can held 15000 commands in its queue making 'random access' pretty non random. Compare that with 31 'ncq' depht for sata&co....

----------

