On Mon, 2004-09-06 at 23:19 -0500, Edgar Lovecraft wrote:
> Also a note, the size of exim varies on what features you compile into
> the binary, only compile those things that you need, as an example,
> I have 3 different 'versions' of exim on three different servers, as
> they all do different things, they do not need the same features, and
> none of them need ALL of the features. (such as one machine talks only
> to other internal exim servers, as such, it only accepts mail from those
> servers, so there is no type of SMTP auth or encryption compiled in, as
> the network it is on, is already private, even from clients)
Frankly this will make zippo difference to the amount of memory used by
exim on a machine. The code size will be shared between all the
running exim processes, and so the only difference is in the data size
used by the binary - and in general if you don't have configuration for
a feature it won't be taking up additional data size (ie if you have
compiled in mysql but don't configure it in the config file then there
will be zero overhead in memory terms for mysql, and a minimal overhead
in cpu cycles when doing a lookup).
> here are the 'sizes' of the exim binary files as found by 'ls'
> the exim version is 4.34, and these all have perl compiled in,
> remove perl and the size reduces by '56276', remove LDAP support
> and drop the size by another '13730'
serious falacy here....
If you are using perl, then the memory overhead is going to be several
megabytes, not the code stubs that hook into the perl shared library.
And again who cares about 56K of data thats shared over the system...
although the thing that will hit you here is the shared library link up
- which I guess also costs you some pages of link table probably not
shared between separate invocations (although fork() will share it).
Oddly enough, you may well get the best speed up and memory use
optimisation (although that can be very hard to measure), by compiling
exim static (can't remember if you still need to do special tweaks to
set ZMAGIC and stuff like the old days). That will lose you your shared
library fixup overhead (memory and processing) on startup, and give you
a fully shared chunk of code.
I don't do this because on a modern system there just isn't the memory
pressure and its more cost effective to just add more hardware at the
moment.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
