From owner-freebsd-hackers Wed Feb 7 15:59:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 2EE8437B6A6 for ; Wed, 7 Feb 2001 15:59:19 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f17NxIa97960; Wed, 7 Feb 2001 15:59:18 -0800 (PST) (envelope-from dillon) Date: Wed, 7 Feb 2001 15:59:18 -0800 (PST) From: Matt Dillon Message-Id: <200102072359.f17NxIa97960@earth.backplane.com> To: Dan Phoenix Cc: Andrew Reilly , Alfred Perlstein , Andre Oppermann , Rik van Riel , Mike Silbersack , Poul-Henning Kamp , Charles Randall , Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: vinum and qmail (RE: qmail IO problems) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yes maxusers stopped the dmesg errors....it seemed. Only thing I do not :like to much about postfix is that it only tries one MX record and then :does not try any others...."default"....yes there is still backlog with :#'s I gave you. Right now 8 min to get an email from sending...I have :another machine here still with qmail on it....going to try to evenly :distribute the mail between them and see how it goes. I cannot get you :stats from linux box because i wiped it out with freebsd....I will do :everything in my power to keep this box freebsd. Why qmail and linux was :handling the load I will never know now but regardless.....with 600 megs :being pushed a day with all that included backlog .....how many megs do :you think one ide drive can handle will be the biggest question to tackle :over next few days. : :... : :Per-Hour Traffic Summary : time received delivered deferred bounced rejected : -------------------------------------------------------------------- : 0000-0100 9788 9514 373 430 5 : 0100-0200 5800 5782 374 352 1 : 0200-0300 6438 6951 553 361 0 : 0300-0400 11497 10192 591 420 0 :... : 0800-0900 12691 9925 922 452 2 : 0900-1000 12174 12354 1205 645 2 : 1000-1100 13884 10220 837 465 1 It looks like you are maxing out at 13000 or so emails per hour, which is 3.6 a second. Well, that accounts for the disk activity :-) Its too bad you don't have stats from when the box was running Linux, it's difficult to determine whether there was actually a problem with the mail flow without knowing what the box was capable of prior to putting FreeBSD on it. I really can't imagine the linux box doing any better short of turning off fsync(). -- When mail is going in and out at this rate, there are a bunch of things you need to tune to optimize things. I do not know much about postfix, so read the documentation and FAQs carefully on postfix performance configuration issues. You have enough memory to be able to handle at least 120 simultanious mail connections, and possibly more. As for the rest of the system, I recommend the following: * You want at least two mail machines (as you indicated above you intend to test with two machines. I recommend that you use at least two machines *permanently*). It is fairly easy to scale mail systems by adding machines. If you scale this way, you do not have to spend money on RAID subsystems or multiple disks. However, to make the most use of the cpu power on each individual machine you may want to throw in multiple disks and either stripe them together, or run multiple queue directories (one queue directory per disk). Having multiple mail machines has many advantages, not the least of which being that you can take one down for maintainance without interrupting your entire flow of mail. Just have two MX records (at the same MX priority), one pointing to each host. * You want to run a recursive named for DNS lookups locally on each mail machine. Do not point resolv.conf to an outside machine. Do not restart the named -- let the cache build up. * I recommend SCSI over IDE, especially for the random-seek/write situations that you have here. A 2U VALINUX box running FreeBSD with two or three medium sized SCSI drives is a good base unit, then scale up from there by adding more machines. Multi-queue (one queue per drive) is recommended rather then striping them all into a single filesystem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message