This one time, at band camp, Greg Kochanski said:
> 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 .
On linux. This is not available on many systems, as has been previously
noted.
> 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.
This sounds like something to implement in an ACL, not within exim
itself. Writing code that deals with all of the possible memory
management schemes in all of the OS's exim runs on is neither trivial,
nor worth it, IMHO.
> > ... 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.
Of course I have. If you consistently run into this sort of
situation, though, you're doing something wrong. Buy more RAM, do
less with the machine, or alter how the kernel swaps by adjusting
/proc/sys/vm/swappiness (again, linux, and also only in 2.6 kernels)
This is, at least IMHO, the right place to do this kind of tuning.
Trying to make individual apps compensate for design flaws doesn't seem
like the right approach to me, though.
[snip]
> 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.)
See above - works fine here.
> 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.
Configure for less swap space, and set swappiness to a high value, and
write the ACL.
Consider the opposite case - a low-end mail server running with 16 or
32MB of RAM - when do we start deferring? Immediately?(most of the
RAM will be in use most of the time on that machine). I can imagine
scenarios where that type of machine would exist, and I certainly don't
want exim to just not work on it.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@??? |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
