Date: Thu, 16 May 2002 17:12:43 -0700 From: Peter Wemm <peter@wemm.org> To: Alfred Perlstein <bright@mu.org> Cc: Doug White <dwhite@resnet.uoregon.edu>, Omar Thameen <omar@clifford.inch.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: tuning a CPU bound server Message-ID: <20020517001243.07997380A@overcee.wemm.org> In-Reply-To: <20020516224303.GA20683@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Peter Wemm <peter@wemm.org> [020516 15:41] wrote: > > > > The only real problem that I know of with postfix is that it still suffers > > from select(2) collisions (FreeBSD kernel problem) when it tries to shut > > down a bunch of idle smtp senders. That can cause transient load average > > spikes - this can be a bit alarming but doesn't actually affect things very > > much. > > Is there a paper on avoiding this? I know how Linux does it, but > they seem to need to hammer on the scheduler lock quite a bit as a > workaround. Postfix minimizes it on freebsd by using file locking to avoid many of the key scenarios. But that does not catch them all. kqueue would completely solve it, but the author wants to keep it clean and portable. I would actually like to see a proof-of-concept implementation of kqueue though, but that would need somebody who is more familiar with kqueue than I. It would probably require greater abstraction of postfix to allow a select, poll, kqueue, /dev/poll etc style choice of backends. We could probably sell the author on this sort of thing though. FreeBSD's "bug" is is twofold: 1) we can only track one process selecting on a shared fd at one time, and 2) we never deregister selects. Tracking more than one is fine, but that either requires memory management as a result of making it dynamic (there is no point making space for 5 to select at once if we are failing with 600+ selecting at once). Memory management then requires that we have an opportunity to 'deselect' so that we can free up resources. Hmmm... We can do this lazily reuse and reclaim stale dynamic records the *next* time a new select happens or when the file is closed or something. The fundamental problem is that select() is supposed to be instantanious and stateless. kqueue solves it by seperating the register/deregister state from the checking of pending events so that we can keep the state active across the loops and avoid the expense of register/deregistering each time. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20020517001243.07997380A>