Skip site navigation (1) Skip section navigation (2)

Re: oom_killer

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tory M Blue <tmblue(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: oom_killer
Date: 2011-04-21 20:12:37
Message-ID: BANLkTi=DSS4mO+FcXs4-h+Wt2F4aBeyhgw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, Apr 21, 2011 at 3:08 PM, Tory M Blue <tmblue(at)gmail(dot)com> wrote:
> On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue <tmblue(at)gmail(dot)com> wrote:
>>
>>> 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.
>>
>> How many of those 300 max connections do you generally use?  If you've
>> always used a handful, or you've used more but they weren't memory
>> hungry then you've been lucky.
>
> max of 45
>
>> work_mem is how much memory postgresql can allocate PER sort or hash
>> type operation.  Each connection can do that more than once.  A
>> complex query can do it dozens of times.  Can you see that going from
>> 20 to 200 connections and increasing complexity can result in memory
>> usage going from a few megabytes to something like 200 connections *
>> 100Megabytes per sort * 3 sorts = 60Gigabytes.
>>
>>> 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.
>>
>> Just because you've been walking around with a gun pointing at your
>> head without it going off does not mean walking around with a gun
>> pointing at your head is a good idea.
>
>
> Yes that is what I gathered. It's good information and I'm always open
> to a smack if I learn something, which in this case I did.
>
> We were already working on moving to 64bit, but again the oom_killer
> popping up without the system even attempting to use swap is what has
> caused me some pause.

Your shared_buffers is way way to high...you have dangerously
oversubscribed this system.  I would consider dropping down to
256-512mb.  Yeah, you have PAE but that only helps so much.  Your
server can only address so much memory and you allocated a huge chunk
of it right off the bat.

Also, you might want to consider connection pooler to keep your
#backends down, especially if you need to keep work_mem high.

merlin

In response to

pgsql-performance by date

Next:From: Paul PierceDate: 2011-04-22 01:26:18
Subject: Issue with partition elimination
Previous:From: Scott MarloweDate: 2011-04-21 20:11:51
Subject: Re: oom_killer

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group