Since the discussion involves Dell PERC controllers, does anyone know if
the performance of LSI cards (those with the same chipsets as Dell) also
have similarly poor performance?
I have a LSI 8888ELP card, so would like to know what other people's
experiences are...
-bborie
Scott Marlowe wrote:
On Wed, Jan 7, 2009 at 2:02 PM, Stefano Nichele
<stefano.nichele@xxxxxxxxx> wrote:
On Tue, Jan 6, 2009 at 7:45 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx>
wrote:
I concur with Merlin you're I/O bound.
Adding to his post, what RAID controller are you running, does it have
cache, does the cache have battery backup, is the cache set to write
back or write through?
At the moment I don't have such information. It's a "standard" RAID
controller coming with a DELL server. Is there any information I can have
asking to the SO ?
You can run lshw to see what flavor controller it is. Dell RAID
controllers are pretty much either total crap, or mediocre at best.
The latest one, the Perc 6 series are squarely in the same performance
realm as a 4 or 5 year old LSI megaraid. The perc 5 series and before
are total performance dogs. The really bad news is that you can't
generally plug in a real RAID controller on a Dell. We put an Areca
168-LP PCI-x8 in one of our 1950s and it wouldn't even turn on, got a
CPU Error.
Dells are fine for web servers and such. For database servers they're
a total loss. The best you can do with one is to put a generic SCSI
card in it and connect to an external array with its own controller.
We have a perc6e and a perc5e in two different servers, and no matter
how we configure them, we can't get even 1/10th the performance of an
Areca controller with the same number of drives on another machine of
the same basic class as the 1950s.
Also, what do you get for this (need contrib module pgbench installed)
pgbench -i -s 100
pgbench -c 50 -n 10000
? Specifically transactions per second?
I'll run pgbench in the next days.
Cool. That pgbench is a "best case scenario" benchmark. Lots of
small transactions on a db that should fit into memory. If you can't
pull off a decent number there (at least a few hundred tps) then can't
expect better performance from real world usage.
Oh, and that should be:
pgbench -c 50 -t 10000
not -n... not enough sleep I guess.
--
Bborie Park
Programmer
Center for Vectorborne Diseases
UC Davis
530-752-8380
bkpark@xxxxxxxxxxx
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
