Re: oom-killer why ?

[Marco Nietz <m.nietz-mm@iplabs.de>]

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.
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>