Re: oom_killer

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Tory M Blue <tmblue(at)gmail(dot)com>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: oom_killer
Date: 2011-04-21 20:11:51
Message-ID: BANLkTimv_Jzw_J-UpsQ5TAa9Va=+c-oS9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
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.

I think this might have been the 32 bit address space biting you. But
that's just a guess. Or the OS was running out of something other
than just plain memory, like file handles or something. But I'm not
that familiar with OOM killer as it's one of the things I tend to shut
off when building a pg server. I also turn off swap and zone_reclaim
mode.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2011-04-21 20:12:37 Re: oom_killer
Previous Message J Sisson 2011-04-21 20:08:01 Re: oom_killer