Re: Upgrade to dual processor machine?

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: "Henrik Steffen" <steffen(at)city-map(dot)de>
Cc: <pgsql-general(at)postgresql(dot)org>, <pgsql-performance(at)postgresl(dot)org>
Subject: Re: Upgrade to dual processor machine?
Date: 2002-11-14 17:15:45
Message-ID: u8k7tukariut2ud0fup9udpvbg0gvjo45n@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Thu, 14 Nov 2002 11:03:54 +0100, "Henrik Steffen"
<steffen(at)city-map(dot)de> wrote:
>this is how it looks like, when my system is busy (right now!!!)
>vmstat 1 5:
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 1 8 1 60 4964 5888 309684 0 0 176 74 16 32 25 9 66
> 0 6 3 60 4964 5932 308772 0 0 6264 256 347 347 13 9 78
> 0 5 1 60 4964 5900 309364 0 0 9312 224 380 309 11 6 83
> 1 4 1 60 5272 5940 309152 0 0 10320 116 397 429 17 6 77
> 1 4 1 60 4964 5896 309512 0 0 11020 152 451 456 14 10 76

More than 10000 disk blocks coming in per second looks quite
impressive, IMHO. (I wonder if this is due to seq scans?) But the
cpu idle column tells us that you are not CPU bound any more.

>free:
> total used free shared buffers cached
>Mem: 1020808 1015860 4948 531424 5972 309548
>-/+ buffers/cache: 700340 320468
>Swap: 1028112 60 1028052

There are two camps when it comes to PG shared buffers: (a) set
shared_buffers as high as possible to minimize PG buffer misses vs.
(b) assume that transfers between OS and PG buffers are cheap and
choose a moderate value for shared_buffers ("in the low thousands") to
let the operating system's disk caching do its work.

Both camps agree that reserving half of your available memory for
shared buffers is a Bad Thing, because whenever a page cannot be found
in PG's buffers it is almost certainly not in the OS cache and has to
be fetched from disk. So half of your memory (the OS cache) is wasted
for nothing.

FYI, I belong to the latter camp and I strongly feel you should set
shared_buffers to something near 4000.

Servus
Manfred

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-11-14 17:28:22 Re: postmaster, but not pg_ctl -i -i
Previous Message Aurangzeb M. Agha 2002-11-14 16:32:36 Re: postmaster, but not pg_ctl -i -i

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Conway 2002-11-14 17:20:49 Re: Docs about buffers and sortmem setting
Previous Message pginfo 2002-11-14 16:43:26 Sort time