At 09:01 AM 2/18/99 -0500, Jere Cassidy wrote:
>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?
Correct. They are two different controls.
The -c option defines how many inbound connections you will accept at one time.
concurrencyremote defines how many *outbound* connetions you will initiate
at one time.
>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 ?
As I've said previously. I'd be surprised if backlog is a problem. Now that
I think about it, limits may be a problem if tcpserver has inherited low
limits. But that's additional to changing to -c. One thing at a time.
>It would be difficult to take it out at this point. It has helped us immensely in
Right. Well let's just get the local settings right first and see what happens.
>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.
I agree. You have a lot more horsepower than I've used for much larger user
bases.
So, change the tcpserver to use -c and restart tcpserver. There is no need
to restart qmail.
Regards.
