Re: oom_killer - Mailing list pgsql-performance

From Tory M Blue
Subject Re: oom_killer
Date
Msg-id BANLkTikMuHj=F7W8vzeDJMk3B3POH1sVdA@mail.gmail.com
Whole thread Raw
In response to Re: oom_killer  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: oom_killer
Re: oom_killer
List pgsql-performance
On Thu, Apr 21, 2011 at 8:57 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 5:50 PM, Tory M Blue <tmblue@gmail.com> wrote:
>> # - Checkpoints -
>> checkpoint_segments = 100
>> max_connections = 300
>> shared_buffers = 2500MB       # min 128kB or max_connections*16kB
>> max_prepared_transactions = 0
>> work_mem = 100MB
>> maintenance_work_mem = 128MB
>> fsync = on
>
> That's an unrealistic setting for a 32-bit system, which can only
> address 3GB of memory per process.
>
> You take away 2500MB for shared buffers, that leaves you only 500M for
> data, some of which is code.
>
> There's no way PG can operate with 100MB work_mem llike that.
>
> Either decrease shared_buffers, or get a 64-bit system.

While I don't mind the occasional slap of reality. This configuration
has run for 4+ years. It's possible that as many other components each
fedora release is worse then the priors.

The Os has changed 170 days ago from fc6 to f12, but the postgres
configuration has been the same, and umm no way it can operate, is so
black and white, especially when it has ran performed well with a
decent sized data set for over 4 years.

This is not the first time I've posted configs to this list over the
last few years and not once has anyone pointed this shortcoming out or
said this will never work.

While i'm still a newb when it comes to postgres performance tuning, I
don't generally see things in black and white. And again zero swap is
being used but oom_killer is being called??

But if I remove

pgsql-performance by date:

Previous
From: Claudio Freire
Date:
Subject: Re: oom_killer
Next
From: Claudio Freire
Date:
Subject: Re: oom_killer