Re: oom_killer

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: oom_killer
Дата
Msg-id BANLkTimv_Jzw_J-UpsQ5TAa9Va=+c-oS9Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: oom_killer  (Tory M Blue <tmblue@gmail.com>)
Список pgsql-performance
On Thu, Apr 21, 2011 at 3:08 PM, Tory M Blue <tmblue@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue <tmblue@gmail.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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: J Sisson
Дата:
Сообщение: Re: oom_killer
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: oom_killer