also sprach Henrique de Moraes Holschuh <hmh@debian.org> [2004.10.12.2329 +0200]: > We have a lot of resources, why can't we invest some of them into > a small three or four machine cluster to handle all debian email > (MLs included), and tune the entire thing for the ground up just > for that? And use it *only* for that? I agree. And I would offer my time to assist. I do have quite some experience with mail administration. > and tune it for spool work (IMHO a properly tunned ext3 would be > best, as XFS has data integrity issues on crashes even if it is > faster (and maybe the not-even-data=ordered XFS way of life IS the > reason it is so fast). I don't know about ReiserFS 3, and ReiserFS > 4 is too new to trust IMHO). This does not belong here, but you misunderstand XFS. It does not have data integrity issues on crashes; all other JFS's do. XFS takes a somewhat rigorous approach, but it makes perfect sense. When there is a crash, journaling filesystems primarily ensure the consistency of the meta data. XFS does so perfectly. The problems you raise relate to the infamous zeroing of files, I assume. Well, no performant filesystem can ensure the consistency of the file content, and rather than trying heuristically to reconnect sectors with inodes after a crash, XFS zeroes all the data over which it is unsure. I think this is important, or else you may one day find /etc/passwd connected to the /etc/login.defs inode. I say performant filesystems in the above because I do not see ext3/journal as a performant filesystem. Nevertheless, it is a very mature filesystem (already!) and works well for a mail spool, though I suggest synchronous writes (chattr +S). That said, I find any filesystem that requires a recheck of its metadata every X mounts to be fundamentally flawed -- did the authors assume it would accumulate inconsitencies, or what is the real reason here? That said, I am using XFS effectively, successfully, and happily on all the mail spools I administer. For critical servers, I mount it with 'wsync', which effectively makes sure that I never lose mail, but which also brings about a 250% performance impact (based on some rudimentary tests, and assuming the worst case). I can suggest XFS confidently. > The third is to not use LDAP for lookups, but rather cache them > all in a local, exteremly fast DB (I hope we are already doing > that!). That alone could get us a big speed increase on address > resolution and rewriting, depending on how the MTA is configured. The way we do it here is to use a local LDAP server which sync's with the external one. Using an external LDAP is definitely a no-do because of the SSL and TCP overheads. I have had much success with using PostgreSQL, both for direct use and to dump postfix Berkeley DB files from its data at regular intervals when the user data does not change every couple of minutes. Berkeley DB is definitely the fastest, IME. > Others in here are surely even better experienced than me in this > area, and I am told exim can be *extremely* fast for mail HUBs. > Why can't we work to have an email infrastructure that can do 40 > messages/s sustained? postfix does this here on a Dual Itanium 2GHz with 2 Gb of RAM and an XFS filesystem, 2.6.8.1 and Debian sarge. The mail spool is on a software RAID 1, the machine also does Amavis/F-prot mail scanning and it rarely ever breaks a sweat. At peaks, we measure about 40 mails/second. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
signature.asc
Description: Digital signature