From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Linux2.6 overcommit behaviour |
Date: | 2003-09-01 02:37:58 |
Message-ID: | 3F52B106.8030600@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>Andrew Dunstan wrote:
>
>
>>I believe that the swap slot can be subsequently freed, though. In
>>theory your available virtual memory should be (almost) RAM+swap. In
>>practice, Linux can run too close to that limit, (or way over it if you
>>turn the checks off). But restricting the maximum possible pages to
>>RAM/2 + swap should normally be fine. IANAKH, though.
>>
>>Also note that the truly bad thing about the OOM killer is that it can
>>affect a process that is not making any new memory demands at all.
>>
>>
>
>How does the OOM killer kill processes, kill -9 or kill -1 and wait?
>
>
It sends a SIGKILL (9) unless the process is doing raw io, in which case
it sends SIGTERM (15). It can't really wait - at this stage the kernel
is in trouble - it can either kill processes or panic. The whole idea of
strict accounting is not to let it get to this stage in the first place.
see mm/oom_kill.c
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-01 02:39:22 | Re: Preliminary notes about hash index concurrency (long) |
Previous Message | Bruce Momjian | 2003-09-01 01:51:02 | Re: pg_dump bug? |