[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: aliases

> We are currently using Zmailer 2.99.43 as our mail transport, and are
> running into some problems with the use of the aliases database.
> Since the router and scheduler leak memory, and have occasionally freezed,
> we restart them every hour.  As well the aliases database is rebuilt every
> 15 minutes by a cron script.  (Shutdown router, newaliases, pause 10
> seconds, restart router).

	You can have perfectly reliable "newaliases" which updates
	the databases on flight, but if you do the final stage with
	mistaken order, you will end up with weird errors.

	The scheduler does not leak, not for a long time for my knowledge.
	It does grow big, if your queue is big, but that is another story.

	The router, on the other hand, does seem to leak, and ..43 is
	from nearly a year back, and a lot has happened since.

	I do debug several router memory "leakages", my post-2.99.49p8
	code contains tricks to limit the number of symbols that the
	router creates for itself. (Because I use 'incore' databases,
	and the splay-trees underneath are 'scalar to dataobject' type
	things needing ways to translate key strings to scalars in unique
	and reliable manner.  That is something the system used to use
	objects called 'symbols', and those just kept accumulating,
	until no memory was left free...)

	Router that only moments ago did grow up to "ulimit -d" (max
	data size) grows now very much slower.  Routing a message with
	1500 recipients takes only about 10 MB at nic.funet.fi per router
	process now, instead of far larger (30 MB or so) a moment before.

	Oh yes, the router script language is rather too sensitive to
	correct writing style to be of easily usable.  Use wrong style,
	and your memory consumption may go up exponentially.
	I am hunting that kind of things now.

> We've noticed that messages addressed to valid aliases in the aliases
> database (dbm) are seen reported as "non existant user"s by the smtpserver
> process--on a sporadic basis--and not anywhere near the period where the
> aliases database is rebuilt.  Does anyone have any ideas why this may be
> happening?  Or have a suggestion for a better way to update the aliases?

	Yes, I have seen that too.  For this reason I wrote script
	called "newdb" for the latter versions.  It essentially makes
	sure the (sub-)file replacement order is correct:

# Now install the files

case "$DBTYPE" in
        mv $BASENAME.$$.db $BASENAME.db
        mv $BASENAME.$$.dir $BASENAME.dir
        mv $BASENAME.$$.pag $BASENAME.pag
        mv $BASENAME.$$.dir $BASENAME.dir
        mv $BASENAME.$$.pag $BASENAME.pag
        mv $BASENAME.$$.gdbm $BASENAME.gdbm

	Things DO blow up on your face, if you replace DBM/NDBM files
	in order:  PAG, DIR, instead of: DIR, PAG

	Also make sure your relation definition has "-m" in it, only then
	will this automatics work.

> Any comments are appreciated.
> Thanks 
> Shawn

/Matti Aarnio <mea@nic.funet.fi>