Re: ZMailer "hangs up" on message queues...

[Michael Loftis <mike@activemessage.com>]

Matthias Urlichs wrote:
> 
> At 12:44 -0700 2001-07-24, Michael Loftis wrote:
> >We've been submitting messages to the postoffice/router directory int he
> >format <NUM>-<NUM>  where num is a non-zero number, one is the PID the
> >other a message sequence count.
> 
> You cannot spool mails directly to the router directory. That's what
> the public/ directory is there for.
> 
> The algorithm to use is really very simple:
> - Create file with unique name (pid+timestamp) in public/.
> - Write envelope, header, body.
> - Close file.
> - Stat() file, retrieving inode number.
> - Rename file to ../router/INODENUMBER.

We do perform the mv into router, and create messages in public.

> 
> The stat() will _not_ cost you anything because it's already in the
> cache, and even if not, you need it for the next step (the rename)
> anyway.
> 
> If you write directly to router/NUMBER, you risk (a) that the number
> isn't unique, or (b) that the router will try to process your message
> while you didn't yet write it and it's still empty, i.e. you have a
> race condition. Ouch.
> 
> If you really have performance problems, change file systems.
> Seriously. Old file systems like FFS(*BSD) or ext2(Linux) have a
> linear directory, so the processing of mails is an O(n^2) operation
> WRT the number of stalled mails. This may bite you sooner or later --
> for instance, after somebody has sent you 200 emails to a domain with
> a nonresponsive DNS server.
> 
> By contrast, some newer file systems (reiserfs under Linux) handle
> directory contents as a B-tree, and thus only get slowed down
> O(n*log(n)).

Linux + ReiserFS still isn't stable.  I personally have lost several
boxen to it of recent memory and atleast every week, usually more often,
watch a new post to the ReiserFS list froms omeone with the current
release or even one rev back with patches lost all their data.

> 
> The same thing applies to the scheduler's directories.
> 
> Another datapoint to ask yourself is, do you need to be 1000% sure
> that every mail gets delivered, no matter when the system crashes? If
> you mount your file system asynchronously (the default on Linux), you
> do not have that guarantee, but directory operations are ten times
> faster...

We're running UFS + SOFT-UPDATES + NOATIME which nulls out alot of the
disk I/O by doing aggressive journal caching...  IE the file create then
mv ends up dropping hte file where it should be, it's all in RAM. 
Performance is much better, but not as good as ReiserFS would be if it
were stable.  If I ever even have to rebuild one box that totally
engates any performance gained by such a filesystem.

I'd rather lose a hundred messages/second and save myself from having to
reload the machines when the blow up.

> --
> Matthias Urlichs
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi