[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-kernel's extremely slow turnaround time
Simon Kirby enscribed thusly:
> On Fri, 8 Jan 1999, Alan Cox wrote:

> > > > Is there anything that can be done to speed things up?

> > > Convince David Miller that for linux-kernel being an order
> > > of magnitude faster is more important than having an order
> > > of magnitude less junk.

> > I doubt DaveM needs convincing, if someone can ship him a bigger box to
> > replace Vger Im sure he'd be very happy

> What's limiting it? CPU? Disk? Sendmail waiting for slow mail hosts on
> the other end?

Having run a mailing list with several thousand subcribers on it,
I would place my money on sendmail. When the NTSecurity mailing list
topped 2,000 subscribers, the list latency was exceeding a day or more
depending on slow hosts. The problem is that, for a given message, sendmail
will only deliver to one address at a time and go sequentially through
that list.

There are some address organizers / spitters that help by
splitting one message into multiples, sometimes organized by domain name.
That lets more copies of sendmail run and reduces the latency. I found
that, in the end, those splitters eventually caused more problems than
they solved.

On my one list engine at ISS, we now use QMail for delivery. I
personally think that Dan Bernstein's claims about security and QMail are
way over hyped and I've seen it commit enough random acts of terrorism not
to trust it exposed to the outside world, but it does deliver mail at least
and order or two fast than sendmail for extremely large receipient lists.
I saw hour latency through the list drop from days to hours.


Make sure you have LOTS of inodes in the kernel. When you open him
up to the maximum number of processes he will deliver mail faster than a bat
out of hell, but he will consume an large number of kernel inodes with all
of those processes.

Also build your spool filesystem with the maximum number of
filesystem inodes. One of the worst brain farts I saw QMail commit
occured because the filesystem ran out of inodes and QMail's error
recovery really sucks wind seriously. It spammed our entire mailing
list with empty messages "from root" over and over again until I shut
it down and fixed the filesystem problem.

But... If you keep it pampered and keep it well within the system
limits, it will outperform sendmail on large mailing lists, no if ands or
buts about it!

> What equipment is it currently using?

> Simon-
> | Simon Kirby | Systems Administration |
> | | NetNation Communications |
> | | Tech: (604) 684-6892 |

Michael H. Warfield | (770) 985-6132 |
(The Mad Wizard) | (770) 925-8248 |
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.077 / U:7.576 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site