[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
btree)
mv $BASENAME.$$.db $BASENAME.db
;;
ndbm)
mv $BASENAME.$$.dir $BASENAME.dir
mv $BASENAME.$$.pag $BASENAME.pag
;;
dbm)
mv $BASENAME.$$.dir $BASENAME.dir
mv $BASENAME.$$.pag $BASENAME.pag
;;
gdbm)
mv $BASENAME.$$.gdbm $BASENAME.gdbm
;;
esac
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>
- References:
- aliases
- From: Shawn Robinson <srobins1@tps.tci.telus.com>