Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception

On Wed, 27 Aug 2008, Florian Weimer wrote:

> * henk de wit:
>
>> On this table we're inserting records with a relatively low
>> frequency of +- 6~10 per second. We're using PG 8.3.1 on a machine
>> with two dual core 2.4Ghz XEON CPUs, 16 GB of memory and Debian
>> Linux. The machine is completely devoted to PG, nothing else runs on
>> the box.
>
> Have you disabled the OOM killer?

my understanding of the OOM killer is that 'disabling' it is disabling
memory overcommit, making it impossible for you to get into a situation
where the OOM killer would activate, but this means that any load that
would have triggered the OOM killer will always start getting memory
allocation errors before that point.

the OOM killer exists becouse there are many things that can happen on a
system that allocate memory that 'may' really be needed, but also 'may
not' really be needed.

for example if you have a process that uses 1G of ram (say firefox) and it
needs to start a new process (say acroread to handle a pdf file), what it
does is it forks the firefox process (each of which have 1G of ram
allocated), and then does an exec of the acroread process (releasing the
1G of ram previously held by that copy of the firefox process)

with memory overcommit enabled (the default), the kernel recognises that
most programs that fork don't write to all the memory they have allocated,
so it marks the 1G of ram that firefox uses as read-only, and if either
copy of firefox writes to a page of memory it splits that page into
seperate copies for the seperate processes (and if at this time it runs of
of memory it invokes the OOM killer to free some space), when firefox does
an exec almost immediatly after the fork it touches basicly none of the
pages, so the process only uses 1G or ram total.

if memory overcommit is disabled, the kernel checks to see if you have an
extra 1G of ram available, if you do it allows the process to continue, if
you don't it tries to free memory (by throwing away cache, swapping to
disk, etc), and if it can't free the memory will return a memroy
allocation error (which I believe will cause firefox to exit).

so you can avoid the OOM killer, but the costs of doing so are that you
make far less efficiant use of your ram overall.

David Lang