Re: [Exim] Exim performance on large mail systems

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Vadim Vygonets
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [Exim] Exim performance on large mail systems
Quoth Tom Samplonius on Sat, May 05, 2001:
> There are usually a lot of misconceptions about what "free memory" is on
> a Unix based system. "free memory" is supposed to be small, otherwise
> memory is being wasted. You should looking at swap activity instead.


It depends on the OS. On some systems, almost all of the free
memory is immediately taken by the buffer cache. On others, free
memory is what is available to the processes, should they ask for
it.

And when you start looking at swap activity, it's too late :)

> Something that doesn't get recommended enough: link exim static. The
> dynamic linker adds startup overhead everytime a new exim processed is
> run. Do not be fooled by the larger size of the exim binary as this will
> likely save memory. All modern Unix systems use a COW VM, so multiple
> intances of the same executable don't use any more memory.


Again, this depends on the OS. The reason they won't use lots of
memory is because the text segment is shared. COW just helps you
to fork faster (sounds beefy). But on some systems, all the
memory for data + bss + stack for the new process is allocated on
fork, and the pages are copied on write to the allocated memory;
on others, memory is allocated on the fly, so if you don't write
to some of the pages, you save memory this way (it's not
allocated, so it's available to others), and this is what usually
happens (for most of them exec almost immediately after fork,
_maybe_ touching one page, so allocating all the pages is
pointless and can kill the process for no good reason (if the
process is big, but what it wants to exec is small)), but if the
process is long-running and it suddenly tries to write to a page
marked COW (therefore causing memory allocation on the fly) and
the memory is not available, you're screwed.

All this has nothing to do with static/shared libs. I.e., the
behavior is same whether the binary in question uses shared libs
or not.

> This is usually more efficient with a static binary.


You save time, you *may* lose some memory (other (i.e., non-exim)
processes, after all, use the same libraries).

Vadik, your resident bored sysadmin.

--
To err is human, to moo bovine.