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 |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Pierce | 2011-04-22 01:26:18 | Issue with partition elimination |
Previous Message | Scott Marlowe | 2011-04-21 20:11:51 | Re: oom_killer |