| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Monitoring backlog queue off MQ listener for Linux |
View previous topic :: View next topic |
| Author |
Message
|
| tczielke |
 Posted: Fri Nov 14, 2014 5:38 am Post subject: Monitoring backlog queue off MQ listener for Linux |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
FYI - For anyone interested in monitoring the backlog queue of your MQ listener on distributed Linux. I recently ran across the ss command, that seems to be able to do this on later versions of the Linux kernel.
For example, if I do the following ss command with my listener being 1414:
| Code: |
[size=9][size=7]>ss -lnt
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 100 *:1414 *:* [/size][/size]
|
the Send-Q shows the backlog max is 100 for this 1414 listener, and the current backlog value is zero. I did a test with some modified listener code, where the listener would sleep between the listen and accept call to see if the Recv-Q is accurate. The Recv-Q count went from zero to one when I created a connection into this “sleepy” listener, so it does look accurate.
This looks like a viable way to monitor your backlog queue on your listener for MQ on Linux (for later kernels), to see if the current backlog count (Recv-Q) is ever getting close to approaching your backlog max (Send-Q). This monitor would be helpful as an "early warning system" or for trend reporting to see if your listener is ever getting close to (or is) being overrun with connection requests. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Nov 14, 2014 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well.
Ok.
It's interesting information.
I'm not sure there's any direct action that can be taken as a result of it.
Perhaps there's some kind of tuning in the TCP stack, maybe.
And without an action plan to resolve any significant impacts in this data, it's the kind of thing that can cause an auditor to have you run through a long period of time trying to explain the reason for the impacts, and why you didn't resolve them. Likewise during a post-mortem.
So unless there's some direct action to take based on this data, it may not be helpful in the larger picture to capture it. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Nov 14, 2014 6:10 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I have used this type of information to help with resolving issues with CTG listeners being overrun with connections. In that case, we just added more CTG address spaces.
For the MQ use case, if your listener is close to or is being overrun with connections, some options would be to adjust the configuration of the connecting applications or add more queue managers to support the work. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 14, 2014 6:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Or simply add another listener.
But I've never really heard of people having trouble with their listeners being saturated. But my practical hands-on managing an MQ estate is several years ago, so. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 14, 2014 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tczielke wrote: |
| I have used this type of information to help with resolving issues with CTG listeners being overrun with connections. In that case, we just added more CTG address spaces. |
Really? Your CICS people selected an odd solution to the problem.
| tczielke wrote: |
| For the MQ use case, if your listener is close to or is being overrun with connections, some options would be to adjust the configuration of the connecting applications or add more queue managers to support the work. |
For the MQ use case, I would put it to you the same information is available via the queue manager, with the added advantage that steps can be taken via the client channels to manage the situation without changing the connecting application or adding more queue managers. Understanding that, of course, in the longer term such measures may prove to be the best course.
I agree with my most worthy associate however; I've never heard of the listener being saturated. Typically it can hand off the connection to the relevant MCA at the same speed or faster than they can arrive.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Nov 14, 2014 6:58 am Post subject: Re: Monitoring backlog queue off MQ listener for Linux |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| tczielke wrote: |
| The Recv-Q count went from zero to one when I created a connection into this “sleepy” listener, so it does look accurate. |
Hmmm. I don't see a listener queue count going from zero to 1 to be an event significant enough to warrant a tuning effort. Or am I missing something?
Have you run out of low-hanging fruit in your tuning effort?
_________________
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 |
|
|
| tczielke |
| Posted: Fri Nov 14, 2014 7:07 am Post subject: Re: Monitoring backlog queue off MQ listener for Linux |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| bruce2359 wrote: |
| tczielke wrote: |
| The Recv-Q count went from zero to one when I created a connection into this “sleepy” listener, so it does look accurate. |
Hmmm. I don't see a listener queue count going from zero to 1 to be an event significant enough to warrant a tuning effort. Or am I missing something?
Have you run out of low-hanging fruit in your tuning effort? |
The point of my comment there was just to say that I verified that the Recv-Q count was accurately reflecting that there was an item in the established connection backlog queue. |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
