"news.tele.dk" skrev i meddelandet
. ..
Hi,

We've bought the following server:

2 x Xeon 3.2Ghz 1mb lvl2 cache
Intel Server Board SE7320SP2LX
4 Gb of DDR400 REG/ECC
12 x +9 SATA, 120GB, 8MB, Fluid (in hotswap casings)

And put in an Adaptec 21610SA + battery option.

The server should do massive SQL-database transactions.

I wouldn't recommend using SATA drives for online transactions, assuming
that's what you intend.
Using SCSI drives is what I would recommend for I/O intensive applications.

Just to test the setup we created on big stripe with all the disk's ....

But no matter what we cannot get read/write performance to exeed 100mb/sec
Considering that we can do around 55mb/sec on just one of the disk's
(configured as a single volume),
we consider this SUB-optimal...

What is your target bandwidth? Also, are you sure high bandwidth is what you
need? To me it sounds like you're going to need IOPS (I/O per second). I'm
not sure what specific SQL engine you'll be using, but generally SQL uses an
I/O size of 2-8 kB for online transactions. Data warehouse is another
matter.
I don't have any figures on-hand what kind of I/O rate a single SATA drive
can do while keeping a reasonable response time (20 ms being the maximum
value I've learned) but considering the drive's specs are 7,2 krpm and
average seek 9.3 ms (taken from the data sheet of a Maxtor DiamondMax Plus
9) I don't expect this drive to be able to handle more than maybe 100-120
IOPS in a random r/w I/O pattern. Let's for arguments sake say it can
deliver up to 200 IOPS, and each I/O is 8kB. The total bandwidth would then
be 200*8*12 (12 is the number of drives in your setup) = 19.2 MB/s. This is
of course not factoring in RAID overhead.


Are we doing something wrong or is it just a very crappy card ???
We are sure it is mounted in a PCI-X (66Mhz / 64 bit) slot, so that's not
it.
No, most likely not.


I've also tested the system with bonnie :
[snip]
Sorry, I can't interpret the output from bonnie.


AAAAArrhhhggggggggg money out the window....

Possibly, but it might depend on what you consider "massive SQL-database
transactions". Then again, in my experience many on-line SQL systems I've
delivered the disk subsystem to hardly uses any disk resources during normal
operation. Most transactions are handled in RAM, and never see the disks.
RAM being so cheap today, it makes good sense cramming as much memory into
the host and not worry about the disk subsystem. Perhaps this is what you'll
see too.
Good luck!
/charles