Author |
Message
|
Prahasith |
Posted: Thu Nov 13, 2003 7:19 am Post subject: runmqlsr/inetd |
|
|
 Disciple
Joined: 16 May 2003 Posts: 184 Location: Kansas City
|
FYI---
In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources (memory, threads, file descriptors), then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them.
The inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrsta processess, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrsta processes even when the queue manager is shut down.
WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so. This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa processes as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. |
|
Back to top |
|
 |
bower5932 |
Posted: Thu Nov 13, 2003 7:35 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
|
Back to top |
|
 |
fordcam |
Posted: Thu Dec 18, 2003 9:48 am Post subject: |
|
|
 Apprentice
Joined: 28 Mar 2002 Posts: 35 Location: MGIC
|
We've found that amqrmppa is running into our limit (this is Solaris) for the number of files a process can use. We have it set to 1024 (ulimit -n 1024), and a particular instance of amqrmppa can hit that. We see FDCs when the process is attempting to open the qm.ini file, or checking /etc/group or /etc/passwd. The errcode is x'18' which means "too many open files".
I'm trying to get the Unix admin to increase the limit, and he's trying to get me to reduce the number of threads per amqrmppa process. Is there any way that I can do this? |
|
Back to top |
|
 |
JasonE |
Posted: Fri Dec 19, 2003 2:01 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Details of tuning parms to achieve this are contained in support pack MP7A pg2 (or 6/21 in the pdf) |
|
Back to top |
|
 |
fordcam |
Posted: Fri Dec 19, 2003 7:31 am Post subject: |
|
|
 Apprentice
Joined: 28 Mar 2002 Posts: 35 Location: MGIC
|
MP7A is for Windows only, though, and we're on Solaris. |
|
Back to top |
|
 |
JasonE |
Posted: Fri Dec 19, 2003 7:40 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Same tuning parms, put them in the Channels stanza of the ini file...! (same place as MaxChannels etc normally go, I assume). |
|
Back to top |
|
 |
fordcam |
Posted: Fri Dec 19, 2003 7:51 am Post subject: |
|
|
 Apprentice
Joined: 28 Mar 2002 Posts: 35 Location: MGIC
|
I think I get it now! We have the Agent ClassMap and Agent ClassLimit parms set to a decent amount, but we don't have any PP tuning parameters set (because they're not documented anywhere!!!). It looks like those will let us avoid our amqrmppa problems.
We don't use Windows, and I know that amqmdain is a Windows-only command so I figured it wouldn't help. But all that amqmdain does is maintain the registry version of the ini file, right? |
|
Back to top |
|
 |
JasonE |
Posted: Fri Dec 19, 2003 8:19 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Yep, precisely. Prior to 5.3 we had to tell people to hack the registry and ensure the security gets set correctly, and amqmdain is a much neater way of doing it!
Note you probably need 5.3 csd03 or higher to get correct results as there were some pool threading problems resolved via an apar (no idea what the number is).
Its easy enough to test - set it very low and see what happens! |
|
Back to top |
|
 |
|