Date: Thu, 23 Nov 2000 00:55:52 +0100 From: Arjan.deVet@adv.iae.nl (Arjan de Vet) To: lconrad@Go2France.com Cc: hackers@freebsd.org Subject: Re: Fwd: Re: still in the woods (tuning for postfix hub) Message-ID: <20001123005552.A57254@adv.devet.org> In-Reply-To: <5.0.2.1.0.20001122183002.023debf0@mail.Go2France.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <5.0.2.1.0.20001122183002.023debf0@mail.Go2France.com> you write: >Somebody here must know who is Mr. Hub Admin, no? postmaster@freebsd.org I guess? >Can somebody tell me who admins FreeBSD/postifx mail hubs? > >I need some help opening up FreeBSD for postfix and 200K msgs/day. Below is an old posting of Peter Wemm to the postfix mailing list about the FreeBSD mailing list server. It gives you some of the information you are asking for. Arjan -- Arjan de Vet, Eindhoven, The Netherlands <Arjan.deVet@adv.iae.nl> URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl From: peter@netplex.com.au (Peter Wemm) Subject: Re: huge mailout tuning? Date: 9 Jul 1999 07:16:38 +0200 Message-ID: <19990708214148.91C7F79@overcee.netplex.com.au> References: <D6C355D59E6DD2119AED00104BCC644C4D3F6F@ccs-exchange.ccsc.com> "Dunstan, Andrew" wrote: > > > > -----Original Message----- > > From: wietse@porcupine.org [SMTP:wietse@porcupine.org] > > > > 2M deliveries in 12 hours is almost 50 a second. Now that is going > > to hit your disk really hard. Each queue file involves synchronous > > disk accesses for creating, writing the message to file and for > > unlinking. Remember, the issue is disk seeks, not I/O bandwidth. > > > [Andrew>] Yes. Would using some sort of raid striping help? If you are prepared to loose mail on a crash, run the filesystem with the queue directory async, or something like the BSD softupdates code to safely avoid directory sync writes. (safely from the perspective of filesystem recovery, not safety from lost mail). If it's a bulk mailout then perhaps this is a acceptable. > > Given that SMTP is a somewhat chatty protocol (unlike HTTP), you > > will need to run hundreds of deliveries in parallel. Postfix uses > > select(), and by default is limited to 1024 open files. In order to > > increase the limit, recompile with a larger size for FD_SETSIZE > > in util/sys_defs.hm at the start of the #ifdef SUNOS5 section. > > > [Andrew>] How do I run "hundreds of deliveries in parallel"? (and > where does postfix multiplex io?) On the freebsd.org machines, we recompiled postfix with FD_SETSIZE set to (overkill) 4096 (freebsd's kernel implementation has variable sized fd_sets). We currently run with 250 delivery smtp processes, and have used higher limits in the past. We manage to fit the entire /var/spool/postfix queue in memory on that machine and with softupdates, a good amount of writes are entirely avoided. (ie: an incoming queue entry gets created, processed (fed to majordomo), then deleted. Under async writes, this data gets written back. Under softupdates it's entirely cancelled out (I believe. :-)) since it was deleted so quickly and never even partially existed on disk before it was unlinked. Again, those machines are not processing critical or sensitive mail so lost mail is unfortunate but tolerable. I *think* we've peaked sustained delivery at about 60/sec for short periods in some circumstances - but we have a *LOT* of slow and/or congested remote sites. I'm pretty sure I've seen transient delivery rate spikes go quite beyond that though but that's probably more luck and timing than anything. Again, *from memory*, the mailing list traffic runs about 1/2 million recipients per day and there is loads of spare capacity as a good deal of this happens in bursts at peak times when a lot of folks read and post to the lists at about the same time of day. > > > I realise that a distributed solution might be necessary, but I want to > > know > > > what we can achieve with our current platform. > > > > > > How can we best tune postfix to maximise delivery rate? Are there issues > > > with queue directories becoming huge? > > > > You can configure postfix to hash queues. By default, only the > > directory for deferred logfiles is hashed. See the hash_queue_names > > parameter. Examples in conf/* > > > [Andrew>] I set have hashing on for incoming, deferred and defer. > Is that right? What is the penalty for increasing the hashing levels? (2 > levels for 2m files would still give me around 10,000 per directory (ouch)). > So I'd prefer to go to 3 or even 4 levels if this doesn't involve a big > performance hit. Also, if you can get the machines, I'd suggest a small cluster of outgoing sender machines. Set up a round-robin DNS entry, say mail-outgoing.you.com where mail-outgoing has 5 or 10 IP addresses or MX records. Then use mail-outgoing for your outbound host. Your core box will send envelopes to the outbound boxes for relaying in a fairly distributed way. We use this technique for freebsd.org mail delivery for some geographical mail exploder relays. For example, mail-relay.de.freebsd.org points to 4 machines, and *.de is exploded via them with a transports entry. Two servers are primary and share the load evenly and the other two are fallbacks on different networks with different international links. eg: [5:06am]~/Mail-251> host mail-relay.de.freebsd.org mail-relay.de.freebsd.org mail is handled (pri=100) by mail.rz.tu-clausthal.de mail-relay.de.freebsd.org mail is handled (pri=100) by baerenklau.de.freebsd.org mail-relay.de.freebsd.org mail is handled (pri=200) by sol.terramedia.de mail-relay.de.freebsd.org mail is handled (pri=300) by ra.dkuug.dk [2:30pm]/etc/postfix-132# fgrep .de /etc/postfix/transport .de smtp:mail-relay.de.freebsd.org This approach works with sendmail too, but you need something like bulk_mailer to presort the envelopes at injection time to get any advantage of multiple recipients per envelope. Anyway, hope this is of use for some ideas. > cheers > > andrew Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001123005552.A57254>