Re: [PERFORM] Quad processor options - Mailing list pgsql-admin

From Bjoern Metzdorf
Subject Re: [PERFORM] Quad processor options
Date
Msg-id 40A13A78.9000607@turtle-entertainment.de
Whole thread Raw
In response to Re: [PERFORM] Quad processor options  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: [PERFORM] Quad processor options  ("scott.marlowe" <scott.marlowe@ihs.com>)
Re: [PERFORM] Quad processor options  (Paul Tuckfield <paul@tuckfield.com>)
List pgsql-admin
scott.marlowe wrote:

> Well, from what I've read elsewhere on the internet, it would seem the
> Opterons scale better to 4 CPUs than the basic Xeons do.  Of course, the
> exception to this is SGI's altix, which uses their own chipset and runs
> the itanium with very good memory bandwidth.

This is basically what I read too. But I cannot spent money on a quad
opteron just for testing purposes :)

> But, do you really need more CPU horsepower?
>
> Are you I/O or CPU or memory or memory bandwidth bound?  If you're sitting
> at 99% idle, and iostat says your drives are only running at some small
> percentage of what you know they could, you might be memory or memory
> bandwidth limited.  Adding two more CPUs will not help with that
> situation.

Right now we have a dual xeon 2.4, 3 GB Ram, Mylex extremeraid
controller, running 2 Compaq BD018122C0, 1 Seagate ST318203LC and 1
Quantum ATLAS_V_18_SCA.

iostat show between 20 and 60 % user avg-cpu. And this is not even peak
time.

I attached a "vmstat 10 120" output for perhaps 60-70% peak load.

> If your I/O is saturated, then the answer may well be a better RAID
> array, with many more drives plugged into it.  Do you have any spare
> drives you can toss on the machine to see if that helps?  Sometimes going
> from 4 drives in a RAID 1+0 to 6 or 8 or more can give a big boost in
> performance.

Next drives I'll buy will certainly be 15k scsi drives.

> In short, don't expect 4 CPUs to solve the problem if the problem isn't
> really the CPUs being maxed out.
>
> Also, what type of load are you running?  Mostly read, mostly written, few
> connections handling lots of data, lots of connections each handling a
> little data, lots of transactions, etc...

In peak times we can get up to 700-800 connections at the same time.
There are quite some updates involved, without having exact numbers I'll
think that we have about 70% selects and 30% updates/inserts.

> If you are doing lots of writing, make SURE you have a controller that
> supports battery backed cache and is configured to write-back, not
> write-through.

Could you recommend a certain controller type? The only battery backed
one that I found on the net is the newest model from icp-vortex.com.

Regards,
Bjoern
~# vmstat 10 120
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  1  0  24180  10584  32468 2332208   0   1     0     2    1     2   2   0   0
 0  2  0  24564  10480  27812 2313528   8   0  7506   574 1199  8674  30   7  63
 2  1  0  24692  10060  23636 2259176   0  18  8099   298 2074  6328  25   7  68
 2  0  0  24584  18576  21056 2299804   3   6 13208   305 1598  8700  23   6  71
 1 21  1  24504  16588  20912 2309468   4   0  1442  1107  754  6874  42  13  45
 6  1  0  24632  13148  19992 2319400   0   0  2627   499 1184  9633  37   6  58
 5  1  0  24488  10912  19292 2330080   5   0  3404   150 1466 10206  32   6  61
 4  1  0  24488  12180  18824 2342280   3   0  2934    40 1052  3866  19   3  78
 0  0  0  24420  14776  19412 2347232   6   0   403   216 1123  4702  22   3  74
 0  0  0  24548  14408  17380 2321780   4   0   522   715  965  6336  25   5  71
 4  0  0  24676  12504  17756 2322988   0   0   564   830  883  7066  31   6  63
 0  3  0  24676  14060  18232 2325224   0   0   483   388 1097  3401  21   3  76
 0  2  1  24676  13044  18700 2322948   0   0   701   195 1078  5187  23   3  74
 2  0  0  24676  21576  18752 2328168   0   0   467   177 1552  3574  18   3  78

pgsql-admin by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: download problems
Next
From: Tom Lane
Date:
Subject: Re: download problems