| Author |
Message
|
| PeterPotkay |
 Posted: Tue Aug 10, 2004 6:03 am Post subject: MaxChannels - How high can you go? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
How do you go about determining what the highest value you can put on a Queue Manager's MaxChannels parameter?
Is there a formula to use based on your setup that will give you the largest number you can safely put there? (I am thinking in terms of instances of SVRCONN channels running at the same time.)
The particular machine I am wondering about is a Windows 2000 server with 2 GIG of memory. 5.3 CSD04.
Are certain hardware/OSs better suited to handle huge numbers of concurrent MQClient connections?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| kingsley |
| Posted: Tue Aug 10, 2004 6:14 am Post subject: |
|
|
Disciple
Joined: 30 Sep 2001
Posts: 175
Location: Hursley
|
Dont put too much load on windows box. The number of threads increases and after a certain point, new connections will not be able to connect and will give an error.
We have already experienced such connections. Don't try beyond 500. Even 500 is great. We stress tested with 700 -1000 channels including svrconn,sender,receiver, the windows performance is lost proportionally as the channels number increases. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 10, 2004 1:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| tallison |
| Posted: Wed Aug 11, 2004 4:51 am Post subject: |
|
|
Apprentice
Joined: 18 Jun 2002
Posts: 39
Location: Round Rock, Texas
|
Peter,
With windows the max active connections is 1300-1600. Once this limit is reached the system will crash. This is not an MQ issue but a Windows issue. We attempted to use two windows servers to service 2500+ clients across the country. If both servers were active they would run but very slow, if one system went down the TCP stack of box 2 would exceed 1500+ connections and also crash.
I know that the table shows numbers much higher than this but the proof is in the pudding (so to speak).
We have had great success with AIX / Solaris and Linux for maximum performance and a large number of client connections (5000+)
_________________
Cheers!!
Tony Allison
_________________
MQSeries Certified Specialist
MQSeries Certified Developer
MQSeries Certified Solutions Provider |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 11, 2004 5:04 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hi Tony. I guess I am looking for some documentation that I can point to that says "This is how many connections this type of set up can safely handle, or this is how you figure it out."
I also feel a Windows box is not the best platform for such a high number of connections. But *feel* is not good enough for changing architectures.
I hear you when you say you crashed a Windows box at 1300-1600 conections. But who's to say that is not something unique to the way you set up you Windows box? IBM had a Windows box with thousands of connections. On a few occasions our Windows box hit the max channels limit of 1500, without crashing.
I would like to have a QM that acts as a concentrator be able to handle maybe 5000 connections. If a single Windows QM can't handle that, I need multiple servers/QMs, or a different QM / OS. Either way, I need some hard numbers to make my case.
If I could point to some doc that says "Windows only allows x TCP connections", that would suffice. Or, "A QM on Windows only allows this many connections given X Y X hardware specs".
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Aug 27, 2004 5:05 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
The problem here is there is no 'limit' coded in the product, its down to the environment.
One of the big issues with handling large numbers of connections was solved at v5.3 by the channel pooled process (amqrmppa's) - This means rather than say 2000 threads in the listener, all fighting for process wide locks, you have more processes and less threads in each process which removes this contention
The other major issue with large numbers of clients is if you pull the cable out the back of the machine. Believe it or not, one of the things causing the most trouble is logging all the error messages (as you are bottleneckingthrough the amq*.log files) - This has been helped tremendously by the message suppressing options (documented in the large cluster support pack).
Aside from that, you can go higher but as is usually the case, the higher you go then the more resources / contention you hit. The other question is how many of your connections will be concurrently issuing things and how many will be silently connected.
There is no straight answer to this - different hardware responds differently, so you wont really see documentation quoting anything other than what you have already quoted. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Fri Aug 27, 2004 12:45 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
In a z/OS lpar (zSeries-2064) in a stress probe, we connect 16000 Clients on 2 QMgr's, sending (+/-) 1000 * 4 Kb msg/sec, NPM.
This msgs. was Reply/Request IMS tx (no DB access) Send_Then_Commit from 8 Solaris. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 31, 2004 4:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| We routinely have several thousand client connections to a mainframe QM. No problems at all, as long as you have enough ECSA defined. |
|
| Back to top |
|
|
|
|
