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@gmail.com> wrote:
>> On Tue, Jan 6, 2009 at 7:45 PM, Scott Marlowe <scott.marlowe@gmail.com>
>> 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@ucdavis.edu