[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: forwarded comment from comp.mail.sendmail on zmailer vs sendmail
At 02:30 AM 2/24/95 +0200, Matti Aarnio wrote:
>> > - no mention of Zmailer config: how many routers?, RAM, etc
>> RAM - 80 Meg, Routers 10
> But the queues as seen by the management (and users) were
> not on the routers, I presume ? ("mailq -ss") Rather on
> the scheduler ?
It seemed to wander between them sometimes. If you happened to restart when
you had a fairly large queue, then the scheduler queue would be the biggest
>> > - if machine was in "constant I/O wait", doesn't that indicate that
>> >Zmailer had reached hardware limitations and that nothing could do
>> Your right Zmailer had reached its limit on that hardware, but Sendmail on
>> that machine was only using half the capacity of the machine to send on
>> average 30 percent more mail per hour. The point is that Sendmail seems to
>> be more efficient.
> At FUNET we have a PP running X.400 gatewaying, and it uses
> many of similar processing models as ZMailer. It is an IO-
> killer too -- or WAS until that machine got installed an
> PrestoServer (the NFS-accelerator), then its throughput
> increased dramatically. All that just because of massive
> amounts of syncronous disk-writes (directory updates)...
> Now what is so different in between sendmail, and ZMailer
> in this respect ? Sendmail has two files (?) per message
> all in one directory, while ZMailer has those two too, but
> in a bunch of directories which are constantly being created
> and deleted.. Now THAT is an IO-killer..
> Also while the message is in processing, sendmail does not
> fork and exec a child (well, perhaps "Mlocal" is different?)
> with its own startup pains to do the transport.
> Monolithic approach has its benefits.
Sendmail allowed us to split the I/O among multiple paths, we installed a
second Sbus, and basically split the load between the two. The single
scheduler process also seems to be a bottleneck. One other thing is that
when a chunk of smtp mailers were started it seemed that nothing else would
be scheduled until all the children finished, this could be a real problem
if one child is waiting for a timeout. I like the ideas that zmailer has in
regards to the queueing system, but the implementation needs a bit more
work. Multiple schedulers would be a good start.
> I don't see any good ways out of it, expect keeping all
> messages in one directory (transporter ?) and thus reducing
> the amount of sync-writes. (Yes, it CAN be done with
> zmailer-2.99.x, because its scheduler uses its internal
> work-database to see, if a filename from readdir() is
> already in works.. The lock-rescanning uses it.)
> Any (other) ideas folks ?
>> James W. Howell
>> Cornell Information Technologies - Network Resources Collaboration Systems
>> Home Page: <http://lmbass.cit.cornell.edu/>
>> Phone: (607)-255-9369 Email: email@example.com
> /Matti Aarnio <firstname.lastname@example.org>
James W. Howell
Cornell Information Technologies - Network Resources Collaboration Systems
Home Page: <http://lmbass.cit.cornell.edu/>
Phone: (607)-255-9369 Email: email@example.com