Re: Has anyone run on the new G5 yet - Mailing list pgsql-performance

From Paul Tuckfield
Subject Re: Has anyone run on the new G5 yet
Date
Msg-id 1070526289.4666.35.camel@localhost.localdomain
Whole thread Raw
In response to Has anyone run on the new G5 yet  (Sean Shanny <shannyconsulting@earthlink.net>)
Responses Re: Has anyone run on the new G5 yet
List pgsql-performance
(hope I'm posting this correctly)

You wrote:

>First question is do we gain anything by moving the RH Enterprise
>version of Linux in terms of performance, mainly in the IO realm as we
>are not CPU bound at all? Second and more radical, has anyone run
>postgreSQL on the new Apple G5 with an XRaid system? This seems like a
>great value combination. Fast CPU, wide bus, Fibre Channel IO, 2.5TB
>all for ~17k.

Wow, funny coincidence:  I've  got a pair of dual xeons w. 8G + 14disk
fcal arrays, and an xserve with an XRaid that I've been screwing around
with.  If you have specific tests you'd like to see, let me know.

--- so, for the truly IO bound, here's my recent messin' around summary:

In the not-so-structured tests I've done, I've been disappointed with
Redhat AS 2.1.  IO thruput.  I've had difficulty driving a lot of IO
thru my dual fcal channels:  I can only get one going at 60M/sec, and
when I drive IO to the second, I still see only about 60M/sec combined.
and when I does get that high it uses about 30% CPU on a dual xeon
hyperthreaded box, all in sys (by vmstat).  something very wrong there,
and the only thing I can conclude is that I'm serializing in the driver
somehow (qla2200 driver), thus parallel channels do the same as one, and
interrupt madness drives the cpu up just to do this contentious IO.

This contrasts with the Redhat 9 I just installed on a similar box, that
got 170M/sec on 2 fcal channels, and the expected 5-6% cpu.

The above testing was dd straight from /dev/rawX devices, so no buffer
cache confusion there.

Also had problems getting the Redhat AS to bind to my newer qla2300
adapters at all, whereas they bound fine under RH9.

Redhat makes the claim of finer grained locks/semaphores in the qla and
AIC drivers in RH AS, but my tests seem to show that the 2 fcal ports
were serializing against eachother in the kernel under RH AS, and not so
under RH9.  Maybe I'm useing the wrong driver under AS. eh.

so sort story long, it seems like you're better of with RH9.  But again,
before you lay out serious coin for xserve or others, if you have
specific tests you want to see, I'll take a little time to contrast w.
exserve.  One of the xeons also has an aic7x scsi controler w 4 drives
so It might match your rig better.

I also did some token testing on the xserve I have which I believe may
only have one processor (how do you tell on osX?) and the xraid has 5
spindles in it.  I did a cursory build of postgres on it and also a io
test (to the filesystem) and saw about 90M/sec.  Dunno if it has dual
paths (if you guys know how to tell, let me know)


Biggest problem I've had in the past w. linux in general is that it
seems to make poor VM choices under heavy filesystem IO.  I don't really
get exactly where it's going wrong , but I've had numerous experiences
on older systems where bursty IO would seem to cause paging on the box
(pageout of pieces of the oracle SGA shared memory) which is a
performance disaseter.  It seems to happen even when the shared memory
was sized reasonably below the size of physical ram, presumably because
linux is too aggressive in allocating filesystem cache (?) anyway, it
seems to make decisions based on desire for zippy workstation
performance and gets burned on thruput on database servers.  I'm
guessing this may be an issue for you , when doing heavy IO.  Thing is,
it'll show like you're IO bound kindof because you're thrashing.


pgsql-performance by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: autovacuum daemon stops doing work after about an hour
Next
From: "Passynkov, Vadim"
Date:
Subject: Async Query Processing on Solaris