Nevermind that -t comment, i just looked at the manpage and the usage of -R removes the potential for that having anything to do with it.
----- Original Message ----- From: "ross mueller" <[EMAIL PROTECTED]> To: "Matt Sergeant" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 05, 2003 5:20 AM Subject: Re: High volume problem > 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. > > > > >
