[Bumper comments issue on several messages....]
G.E.Fowler@??? said:
} We keep a check on user mailbox sizes. When they get ridiculous (usu. >
} 10MB which is, plainly, ridiculous!) they are normally moved out of
} the way and we then wait until said user screams... it doesn't have to
} be done very often, mind, as the default install of Eudora here has
} 'leave messages...' unchecked.
We see *messages* bigger than that.
The largest mailbox we have at present is 3GB.
michael@??? said:
} Larger ISPs restrict the size of user mail boxes. Most users don't
} keep too much email in their mail boxes, though, because it slows down
} their clients. :)
Depends on your mail spool layout. POP is very light on our system and
users only hit a problem when they get to a few 100,000 messages.
} Can anybody provide some data on typical POP3 request rates per user
} with larger dialup installations?
No immediately... maybe I should look at those stats.
} While looking at performance issues: With a Pentium II running at 450
} MHz, 512 MB RAM and a RAID configured as 0/1 with 6 disks, using Linux
} 2.0.35, I only get Exim to accept mail with a rate of up to 30-40
} emails per second. Why? I wrote a few lines C to flood a server with
} SMTP requests, in case anybody is interested in profiling.
I can guess exactly where the bottleneck is and there is little that exim
can do about it. You may be able to find some interesting profiling notes
on the postfix site -
http://www.postfix.org/ - postfix is the release
name for what has been known as Vmailer. Wietse (who wrote postfix, and
gave a talk at SANE98 - again see if the slides are available at
http://www.nluug.nl/events/sane98/ ).
Wietse's profiling showed that the single major bottleneck on a mail
system is the file system. Exim writes 3 files per message minimum
(headers, data, msglog). The real bottleneck is that for the vast
majority of Unix systems file creation is a synchronous operation which
requires you to talk to the disk. This happens no matter what is being
done with the message - queue only mode would only create 2 files (no
msglog), local delivery is likely to involve other files, remote delivery
involves network stuff but probably no other local files (at your end -
the recipient still has to play with them).
How could you speed this up...(ordering is pretty random)?
1. Use fewer files (postfix does this)
2. Preallocate queue files and use them round robin (no create
sync overhead - I think postfix does something like this,
3. Async filesystem. You don't really want to trust your mail
to something like this do you???
4. Don't sync on close (fine when it all works, you lose mail
when it goes wrong).
5. Use RAM disks. Not safe unless you have persistent RAM devices.
Some sendmail systems do very ornate things with multiple
queues on RAM disks.
6. Different file system designs - an interesting topic which I
know almost nothing about.
7. Ignore the filesystem and do something similar to CNFS for news
mick@??? said:
[about mailbox scan time for large mailboxes]
} This is a really big problem if you use mbox format, since the whole
} file must be scanned each check. I'd like to try one of the non-mbox
} formats, does anyone know of a pop server that supports one of these
} formats?
The qmail one surprisingly enough handles maildir format - and can be
tweaked for a few efficiency fixes (must submit those back to Dan
sometime). [For those interested, by default the qmail popper stats every
file on startup giving a long pause on startup which is painful if you
have a million or so entries. We changed this to only stat the file
(which is done to obtain the message size) when its needed - normally when
you run LIST - LIST is normally output IO bound so slowing it down is not
noticable]
Nigel.
--
[ Nigel.Metheringham@??? - Systems Software Engineer ]
[ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ]
[ Real life is but a pale imitation of a Dilbert strip ]
[ We're recruiting http://www.theplanet.net/profile/recruit.htm ]
--
*** Exim information can be found at
http://www.exim.org/ ***
