Re: linux, memory (mis)accounting/reporting, and the planner/optimizer

From: "M(dot) Edward (Ed) Borasky" <znmeb(at)cesmail(dot)net>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Dave Youatt <dave(at)fyreball(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: linux, memory (mis)accounting/reporting, and the planner/optimizer
Date: 2009-01-22 18:39:08
Message-ID: 4978BD4C.905@cesmail.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Smith wrote:
> On Wed, 21 Jan 2009, M. Edward (Ed) Borasky wrote:
>
>> Re the OOM killer -- maybe a patch to the kernel could make things
>> "better"??
>
> People have tried to raise awareness of it; sample:
>
> http://lkml.org/lkml/2007/2/9/275
>
> without much success. The Linux kernel hackers dislike the whole
> approach PostgreSQL uses to allocate shared memory anyway--witness the
> backlash against any attempt to raise SHMMAX.
>
> I found the long thread that beats this issue to death in the archives
> again:
>
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00026.php
>
> That discussion should get raised to a higher profile eventually, maybe
> a summary on the wiki.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
Yes, please collect as much detail as you can in some centralized place.
For recent kernels (2.6.25+) the memory accounting is much better, and
if nothing else, there might be some things PostgreSQL could do to
minimize the probability of getting hit, at the cost of some
platform-dependent (/proc reading) code. The problem is that
"enterprise" Linux distros aren't running 2.6.25+ yet. :(

--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2009-01-22 19:00:12 Re: postgresql 8.3 tps rate
Previous Message Simon Riggs 2009-01-22 18:05:45 Re: caching written values?