Stephen Gran wrote:
> This one time, at band camp, Andreas Metzler said:
>>Should exim really have that fine grained knowledge for a specific
>>target platform (detect "when the free RAM is small and the system is
>>starting to swap") built in?
>
>
> Absolutely not - that's what the kernel VM is for. The kernel VM (at
> least on linux) will hold as much of an app in memory as possible, and
> swap it out if it needs to free up some memory. Sometimes all of the
> memory is actively being used, and the kernel has to resort to the OOM
> killer. How could exim possibly know whether or not memory being used
> is able to be swapped out, or whether it is in active use?
How? It looks in /proc/meminfo .
Now, I think you're assuming that exim needs to do a very good
job of understanding the system's memory allocation, but that's
not true under either of two conditions:
(1) Your system almost never runs out of RAM, and the limit is
just for emergencies. In that case, it's not important to be
precise.
(2) You put a soft threshold in, so that as the memory usage passes
the setting, exim starts gradually rejecting and/or deferring more
work. Since things happen gradually, it is (again) not important
that the threshold be set precisely. If you accidentally set it
too low, then exim will just operate inefficiently. Eventually,
you'll look in the log files and figure out that there's a problem,
and you'll fix it.
> ... It is
> technically possible to do these sorts of things, of course, but it is
> absurd - much better to let the kernel do it's job and exim do it's job.
> If the machine runs out of memory, don't worry - mail will be deferred
> by the OOM killer :)
>
I take it you've never tried to use a Linux machine that's doing
a lot of swapping. It can take 30 seconds to repaint the
screen.
Recently, I had some code that was suffering from a memory leak,
and as the virtual memory footprint went from 400 to 600 megabytes on
a machine with 512 meg of memory, the performance dropped
by a factor of sixty. This is quite expected: instead of waiting
100 nanoseconds for data from RAM, the CPU needs to wait 10 milliseconds
for data from disk. That's 100000 times longer.
The trouble with letting the kernel do the dirty work is that it
can't do a very good job of it. Given that huge ratio of access
times, unless the kernel can do a virtually perfect job of
predicting memory access, even an occasional swap will drastically
cut performance.
(And, for some applications, like lookups in a hash table, the kernel
has no hope of predicting memory access correctly.)
Assuming that the linux box is configured with a largish amount of
swap space, performace could be pitifully bad for a long time
before you fill up the swap and finally invoke the OOM killer.
