[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.021 / U:12.988 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site