| Author |
Message
|
| andrewfemin |
 Posted: Sat Dec 09, 2017 11:14 pm Post subject: Multiple instances of a SVRCONN channel |
 |
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
Hello,
This post is in connection with the below post:
http://www.mqseries.net/phpBB2/viewtopic.php?t=58057&postdays=0&postorder=asc&start=0
I have a SVRCONN channel(let's say MY.SVRCONN) defined in my Queue Manager and an application connects to it as a client. When I run DIS CHS(MY.SVRCONN), I see hundreds of instances of this channel. This is causing the RAM usage of the server(which has the Queue Manager) to shoot up.
I understand that the root cause of the issue is the application not closing the connections it's opening. While I wait for the application team to make changes, is there anything I can do at the QM to limit this. Limiting MAXINST is the obvious option, but this will throw the client application into an error that the application ran out of connections.
Can something be done on the queue manager to remove the existing instance of MY.SVRCONN channel when the same ip address opens another connection? |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Sun Dec 10, 2017 10:52 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
What you are asking is......" is there a way to tell MQ to break a perfectly health connection from an application automatically?!".
Well, not that I can think of of, no. As you say, there are ways to prevent an application from consuming too much resource, such as MAXINST and MAXINSTC, but that would ultimately cause the application to see error codes. If an application is not re-using it's connection and just connecting again and again then clearly this is a basic error of the application, it is remarkable that it got through your testing cycle without being detected. Perhaps something else you should look at.
The only thing you can do, that I can think of, is 'manually' issue STOP CONN' to clear up the connections that are no longer needed. If you have MQSCX it would be pretty easy to write a script to run through the existing connections, say every 30 seconds, and stop the connections from this application that had been running for more than a minute.
Cheers,
Paul
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sun Dec 10, 2017 10:58 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
As soon as I hit send on this reply I remembered that we had reused the DISCINT parameter on the Channel Definition so let me change my reply.
If you set the DISCINT value of your SVRCONN to a non-zero value then it tells MQ to drop the connection after that many seconds of no activity.
My apologies, I had forgotten all about it and, to be honest, I haven't used this feature for years, but it is definitely worth a try.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| andrewfemin |
| Posted: Thu Dec 14, 2017 3:35 am Post subject: |
|
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
| Thanks a lot Paul. I'll try this out and get back with the results. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 14, 2017 3:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If you wish to conserve QM host resources, you can also increase the SHARECNV value from the default of 10 to a higher value.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| andrewfemin |
| Posted: Wed Dec 20, 2017 9:03 pm Post subject: |
|
|
Acolyte
Joined: 26 Aug 2017
Posts: 54
|
| PaulClarke wrote: |
| If you set the DISCINT value of your SVRCONN to a non-zero value then it tells MQ to drop the connection after that many seconds of no activity. |
Changing DISCINT to a non-zero value dropped the unused channel instances, which is great. I'm yet to get data on its effect on system resources. I'll update as soon as I get it.
| zpat wrote: |
| If you wish to conserve QM host resources, you can also increase the SHARECNV value from the default of 10 to a higher value. |
Thanks for the pointer. I'll try this. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 22, 2017 10:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| andrewfemin wrote: |
| zpat wrote: |
| If you wish to conserve QM host resources, you can also increase the SHARECNV value from the default of 10 to a higher value. |
Thanks for the pointer. I'll try this. |
Be aware that this will decrease the performance of the individual connections, since they may at times be competing for the same connection. If that drop in performance is enough to be noticed is another question.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 22, 2017 10:51 am Post subject: Re: Multiple instances of a SVRCONN channel |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| andrewfemin wrote: |
| This is causing the RAM usage of the server(which has the Queue Manager) to shoot up. |
Other than increased use of RAM, what problem/symptom/issue are you seeing? Are your apps missing SLA's (service level agreements)?
RAM is an inexpensive resource - buy more.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
