Yeah, i've toggled around with the tcpserver options, even going as far as turning off TCPREMOTEHOST and TCPREMOTEINFO lookups without any promising results.
Here's the exact runfile i'm using #!/bin/sh QMAILDUID=`id -u qmaild` NOFILESGID=`id -g qmaild` #exec /usr/local/bin/softlimit -m 25000000 \ /usr/local/bin/tcpserver -c 150 -v -p -R -t 20 \ -u $QMAILDUID -g $NOFILESGID `head -1 config/IP` smtp \ ./qpsmtpd 2>&1 What i find interesting about the issue is even if i set -t to 3 seconds, is that it ends up still having the delay. Shouldn't it drop right in if after 3 seconds it can't resolve the remote host? We're currently running a bind 9 caching nameserver locally on one machine and dnscache on another to test thier results and neither seem to be getting hit too hard at all. I'll look into selectserver and see how it runs in comparrison. ----- Original Message ----- From: "Matt Sergeant" <[EMAIL PROTECTED]> To: "ross mueller" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 05, 2003 2:50 AM Subject: Re: High volume problem > On 5 Nov 2003, at 3:18, ross mueller wrote: > > > Anyone have any ideas what may be causing this delay? > > Hard to tell without full tcpserver command line. Make sure you're not > doing slow things like identd lookups (you say you have -R which turns > that off, so it's probably something else). > > If it's not that, do you have a local caching dns server (I use djb's > dnscache)? > > You might also want to consider the new SelectServer instead of > TcpServer (in CVS) which handles many more concurrent connections > (though will probably break at around 1000 and you'll need to up your > ulimit) and probably performs slightly better. Though it's slightly > premature at the moment - might need either some extra hands or another > couple of weeks before it's absolutely solid, but I've been running it > happily here now for a few days (processed a few thousand mails through > it). > > Matt. > >
