From owner-freebsd-hackers Mon Dec 6 12:54:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CF905158EB for ; Mon, 6 Dec 1999 12:51:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA72513; Mon, 6 Dec 1999 12:51:25 -0800 (PST) (envelope-from dillon) Date: Mon, 6 Dec 1999 12:51:25 -0800 (PST) From: Matthew Dillon Message-Id: <199912062051.MAA72513@apollo.backplane.com> To: David Wolfskill Cc: jeremyp@gsmx07.alcatel.com.au, hackers@FreeBSD.ORG, rfg@monkeys.com Subject: Re: tmpfs .. ? References: <199912062023.MAA44565@pau-amma.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) :>From: Matthew Dillon : :> The actual problem is sendmail's constant *rescanning* of the directory. : :To the extent that the directory is populated, yes. (Scanning an empty :directory isn't an overwhelmingly resource-intensive operation.) :... : (lots of good stuff removed) :... :-- :David Wolfskill dhw@whistle.com UNIX System Administrator It's an O(N^2) failure mode. If your sendmail gets overloaded then queue files build up which in turn make sendmail less efficient. The result is a cascade failure - where the mail queue directory gets so large that it cannot recover even when the load drops back down to normal. We had dozens and dozens of such failures at BEST before I went to the multi-queue method. This obviously only applies to servers that have a lot of mail volume. When you are getting four or five emails a second at peak and something out of your control goes down, the queue can build up very rapidly. I will also note that the problem is exasperated by FreeBSD's current use of malloc buffers instead of the VM cache to cache directories. Once any given directory gets too large, the machine suddenly starts going to disk every time you scan it! In 4.x you can turn on VMIO backing for directories (sysctl -w vfs.vmiodirenable=1). It isn't on by default only due to a bug somewhere in softupdates that causes an occassional panic, apart from that all the necessary work has been done (by yours truely, of course :-)). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message