Re: oom-killer why ?

Marco Nietz
2008-08-27T06:21:37Z

Thank you all for your Help.

My first guess that the oom where caused by running out of Lowmem was
confirmed and the Solution is to upgrade the Server to a 64bit OS.

All right to that point, but why this was affected by the raised up
Sharded Buffers from postgres ? Is shared buffer preferred to be in lowmem ?

With the smaller Buffersize (256mb) we haven't had any Problems with
that Machine.

> Larry Woodman wrote:
>> On Tue, 2008-08-26 at 18:48 +0530, Balbir Singh wrote:
>>> Balbir Singh wrote:
>>>
>>> Looking closely, may be there is a leak like Christoph suggested (most of the
>>> pages have been consumed by the kernel) - only 280kB+244kB is in use by user
>>> pages. The rest has either leaked or in use by the kernel.
>>>
>> There is no leak. Between the ptepages(pagetables:152485), the
>> memmap(4456448 pages of RAM * 32bytes = 34816 pages) and the
>> slabcache(slab:35543) you can account for ~99% of the Normal zone and
>> its wired. You simply cant run a large database without hugepages and
>> without CONFIG_HIGHPTE set and not exhaust Lowmem on a 16GB x86 system.
>
> Thanks for looking at it more closely, Yes, we do need to have CONFIG_HIGHPTE
> enabled.