Mark,
We removed the -c options because we are currently using
qmail/control/concurrencyremote and qmail/control/concurrencylocal. should we also
add -c options to tcpserver?
I know that the backlog _is_ an issue. Our performance increased so much when we did
-b30 instead of letting the default take over (5). Every time we have upped this
number, we get performance gains. The problem is that if only one server is left in
the Alteon's rotation, it seems to get more than 128 connections in a matter of
minutes. These then seem to have a logarythmic effect. The more connections queue
up, the more connections are delayed, the more connections are queued up... etc...
This leads to the 700 number (which i do admit is extermely high-- netstat showed
some 590 smtp connects). During the slow time this morning after i got all 3 servers
handling mail, we had about 24 connections total (not just smtp).
Now that i think about it... it seems if the connections eclispse approximately 200,
we start to have incredible delay on the smtp connects. (this leads me to believe
that 128 limit mentioned in Redhat Linux 5.2's `man listen` might be our problem). I
am unsure what to do next.... is there a way to up this limit (besides hacking the
kernel somewhere)? Do other unices perform better in this area? Doesn't anyone else
have this problem ?
The alteon takes out servers that are not responsive to its SMTP and/or POP3
connects.
It would be difficult to take it out at this point. It has helped us immensely in
system availability, but I truly believe that our main server (an alpha633) would be
able to handle _all_ the load if it didnt run into these tcpserver/max connection
issues.
Thanks again for the help Mark and anyone else who wishes to contribute!
-Jere
Mark Delany wrote:
> >Yes, 700 connections seems high, but after some period of down time, it seems to
>
> Just to emphasize what I was saying. I reckon for 30K users (was that the
> number-ish?), 700 is far higher than normal. I know there is no such thing
> as normal, but...
>
> > tcpserver -l$hostvalue -q -b100 -H -R -D 0 pop-3
> > tcpserver -l$hostvalue -q -b50 -H -R -D 0 2001
> > tcpserver -l$hostvalue -t8 -q -b5000 -D -u502 -g2108
> > tcpserver -l$hostvalue -t8 -q -b50 -D -u502 -g2108
>
> In all cases, change the -b to a -c
>
> >After reading "man listen" I am reminded of the help this list gave us when we
> >had this problem before. Our connections were being artificially limited by
> >Linux to 5 at a time! This was solved with adding the -b20 (then later upping
>
> It *may* be worth upping it beyond the default, but the listen queue really
> only comes into effect if tcpserver isn't keeping up with the inbound
> connection rate.
>
> As long as tcpserver is doing the accept and passoff to qmail-smtpd in
> enough time, the backlog doesn't apply. the concurrency with -c does of course.
>
> >If one server reaches this limit, it is overloaded and if lucky it is dropped
> >out of the rotation by the alteon. This causes the other servers to overload
> >and reach the same state.
>
> Is the alteon configured to load balance of switch on no response?
>
> Also, is it possible to bypass the Alteon for a while? There may be some
> unknown interaction there.
>
> Regards.
--
------------------------------------------------------------------------
// Jere Cassidy - System Administration - D&E SuperNet
email: [EMAIL PROTECTED] phone: (717)738-7054
web: http://www.desupernet.net/jere
pager/pcs: [EMAIL PROTECTED] - (717)203-0042
~~~ "While sowing the seeds of Utopia,
you invoked a convenient amnesia" -BR ~~~
------------------------------------------------------------------------
