Author |
Message
|
aditya.aggarwal |
Posted: Tue Jun 09, 2009 9:49 pm Post subject: MQRC_RESOURCE_PROBLEM with Channel |
|
|
 Master
Joined: 13 Jan 2009 Posts: 252
|
Recently we have facced the MQRC_RESOURCE_PROBLEM error while starting a SDR channel. After checking logs(circular) we found that logs(Default numbers) are full and thre are 20000 persistant messages pending in the queue. Queue MAXDEPTH(600000) .
We have resolved the issue after increasing the number of logs. I was just wondering is there any other way to resolve this issue without increasing the number of MQ logs? was this issue can be resolvd after bouncing the queue manager also?
Can we set some alert on the logs( i think not possible)? so that we will be informed before the logs get full?
Cheers,
Aditya |
|
Back to top |
|
 |
exerk |
Posted: Tue Jun 09, 2009 11:16 pm Post subject: Re: MQRC_RESOURCE_PROBLEM with Channel |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
aditya.aggarwal wrote: |
...I was just wondering is there any other way to resolve this issue without increasing the number of MQ logs?... |
Yes...make sure an application removes the messages!
aditya.aggarwal wrote: |
...was this issue can be resolvd after bouncing the queue manager also?... |
Think that one through, and you'll find you already know the answer.
aditya.aggarwal wrote: |
...Can we set some alert on the logs( i think not possible)? so that we will be informed before the logs get full? |
You got an alert: MQRC_RESOURCE_PROBLEM _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
aditya.aggarwal |
Posted: Tue Jun 09, 2009 11:36 pm Post subject: |
|
|
 Master
Joined: 13 Jan 2009 Posts: 252
|
Thanks exerk.
exerk wrote:
Quote: |
Think that one through, and you'll find you already know the answer. |
??????????
exerk wrote:
Quote: |
You got an alert: MQRC_RESOURCE_PROBLEM |
We got this error while starting the channel. How can we set this as monitoring alert?
We are using CA agent for MQ monitoring
Cheers,
Aditya |
|
Back to top |
|
 |
exerk |
Posted: Tue Jun 09, 2009 11:53 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
aditya.aggarwal wrote: |
?????????? |
Your logs were already full, messages in the queue, and when you restart the queue manager do you really think the logs would magically not still be 'full', and the queue magically not have 20,000 messages on it? Of course, if the implied question was, 'if I increase the number of logs (disk space permitting), and bounce the queue manager, will the resource problem disappear?', and you were looking for reassurance on that point, then yes, it will solve the problem - temporarily.
If you have a queue with the max depth you stated, and you know the size of the messages, you should not have run out of log space because you should have done the sums and worked out what you needed, therefore this situation should never have arisen. So, the question is, why do you think you got the error when starting the channel? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
aditya.aggarwal |
Posted: Wed Jun 10, 2009 2:33 am Post subject: |
|
|
 Master
Joined: 13 Jan 2009 Posts: 252
|
Thanks exerk.
exerk wrote:
Quote: |
If you have a queue with the max depth you stated, and you know the size of the messages, you should not have run out of log space because you should have done the sums and worked out what you needed, therefore this situation should never have arisen. |
We have requested the Message size from the application team. After this we will plan the log space.
exerk wrote:
Quote: |
So, the question is, why do you think you got the error when starting the channel? |
Because logs were full.
Rgds,
Aditya |
|
Back to top |
|
 |
Sam Uppu |
Posted: Wed Jun 10, 2009 11:00 am Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
As the msgs are persistent, they will be written to the log files. your log files should be big enough to accomodate the bulk msgs. If you are running on version 6, the log file size is of 4MB each and if you are running on version 7, it is 16 MB each(the log file pages have been increased in version 7). Try to create the log files with higher log file pages. The max limit is 65535. If you use 65000 as lf while creating the QMgr, the log will be created with a size of 260 mb each.
Note: if you want to increase the log file pages, you have to recreate the qmgr with lf flag setting. if you want to increase the number of primary/ secondary log files, just pump up and restart the qmgr.
Thanks. |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu Jun 11, 2009 10:28 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
The Log files will only contain uncommitted work for circular logs. Not every last persistent message. The amount of uncommitted work is what you need to plan for.
Your Logs should not be on the same file system as the QMGR data (queues).
You would need to recreate your QMGR, but plan to make your LogFilePages as large as you can and then plan to occupy 70% with primary and the rest with secondary. Then CA can emit warnings at 71% and critical at 81%. |
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Jun 11, 2009 7:59 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
JosephGramig wrote: |
The Log files will only contain uncommitted work for circular logs. Not every last persistent message. The amount of uncommitted work is what you need to plan for. |
Correct. There need to be enough circular logs to contain the oldest uncommitted message. Look at the last modified time on the oldest log to see how long it takes to cycle through them all. If there is a long running unit of work it may cause resource problems for other apps (including MCAs) that use MQ syncpoint. _________________ Glenn |
|
Back to top |
|
 |
aditya.aggarwal |
Posted: Fri Jun 12, 2009 8:41 am Post subject: |
|
|
 Master
Joined: 13 Jan 2009 Posts: 252
|
gbaddeley wrote:
Quote: |
JosephGramig wrote:
The Log files will only contain uncommitted work for circular logs. Not every last persistent message. The amount of uncommitted work is what you need to plan for.
Correct. There need to be enough circular logs to contain the oldest uncommitted message. Look at the last modified time on the oldest log to see how long it takes to cycle through them all. If there is a long running unit of work it may cause resource problems for other apps (including MCAs) that use MQ syncpoint. |
But when we get the error that time 20000 message in the queue were in commited state.
and we were getting the MQRC_RESOURCE_PROBLEM error while starting the channel.
Does it mean that this error can be resolved by just restarting the queue manager?
Sam uppu wrote:
Quote: |
As the msgs are persistent, they will be written to the log files. |
non persistnat message also written in log on temporary basis. MQ will not reconver the the non persistant message from the queue in case of failure, it other parametrs of queue is set to default value.
Cheers,
Aditya |
|
Back to top |
|
 |
gbaddeley |
Posted: Sun Jun 14, 2009 4:42 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
aditya.aggarwal wrote: |
non persistnat message also written in log on temporary basis.... |
Where do the MQ manuals say that? _________________ Glenn |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jun 14, 2009 6:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
gbaddeley wrote: |
aditya.aggarwal wrote: |
non persistnat message also written in log on temporary basis.... |
Where do the MQ manuals say that? |
I believe the manual specifies that this happens if the message is part of a Unit Of Work (UOW)... Non persistent messages that are not part of a UOW do not get logged. _________________ MQ & Broker admin |
|
Back to top |
|
 |
gbaddeley |
Posted: Mon Jun 15, 2009 7:04 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
fjb_saper wrote: |
gbaddeley wrote: |
aditya.aggarwal wrote: |
non persistnat message also written in log on temporary basis.... |
Where do the MQ manuals say that? |
I believe the manual specifies that this happens if the message is part of a Unit Of Work (UOW)... Non persistent messages that are not part of a UOW do not get logged. |
Non persistent messages can be a part of a syncpoint UOW (and be committed and backed out), but the are NOT written to the recovery log files, even "temporarily". Management of the state of non-persistent messages in a UOW is done outside of the recovery log files. Presumably it is done in memory and in the the Q file.
Its easy to demonstrate this behaviour. I put non-persistent messages under syncpoint at a very fast rate. After 200,000+ messages the recovery log files had not budged. The queue depth was increasing but I could not browse any messages. I put-disabled the queue while it was putting the messages, the next MQPUT failed with Reason code 2051 (MQRC_PUT_INHIBITED), the program called MQBACK, and they were all backed out from the Q file successfully. It took less than half a second to back them out (on my Windows box). _________________ Glenn |
|
Back to top |
|
 |
aditya.aggarwal |
Posted: Thu Jun 18, 2009 5:14 am Post subject: |
|
|
 Master
Joined: 13 Jan 2009 Posts: 252
|
gbaddeley wrote:
Quote: |
fjb_saper wrote:
gbaddeley wrote:
aditya.aggarwal wrote:
non persistnat message also written in log on temporary basis....
Where do the MQ manuals say that?
I believe the manual specifies that this happens if the message is part of a Unit Of Work (UOW)... Non persistent messages that are not part of a UOW do not get logged.
Non persistent messages can be a part of a syncpoint UOW (and be committed and backed out), but the are NOT written to the recovery log files, even "temporarily". Management of the state of non-persistent messages in a UOW is done outside of the recovery log files. Presumably it is done in memory and in the the Q file.
Its easy to demonstrate this behaviour. I put non-persistent messages under syncpoint at a very fast rate. After 200,000+ messages the recovery log files had not budged. The queue depth was increasing but I could not browse any messages. I put-disabled the queue while it was putting the messages, the next MQPUT failed with Reason code 2051 (MQRC_PUT_INHIBITED), the program called MQBACK, and they were all backed out from the Q file successfully. It took less than half a second to back them out (on my Windows box). |
We have faced an issue some time back when our active logs became full due to some uncommited nonpersistant message , which were part of UOW. These message were set for the expiry time. and the log space become avaialble after bouncing the queue manager.
So i belive non-persistant message under UOW also written in to mq logs on temprorary basis?
Cheers,
Aditya |
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Jun 18, 2009 3:03 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
Quote: |
We have faced an issue some time back when our active logs became full due to some uncommited nonpersistant message , which were part of UOW. These message were set for the expiry time. and the log space become avaialble after bouncing the queue manager.
So i belive non-persistant message under UOW also written in to mq logs on temprorary basis?
Cheers,
Aditya |
I think you are wrong, non-persistent messages are never written to the logs. Can anyone back me up on this, or shoot me down? _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jun 18, 2009 4:41 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9470 Location: US: west coast, almost. Otherwise, enroute.
|
non-persistent messages are not written to the logs.
There are a variety of WMQ references. Here is one from the WMQ System Admin manual, Recovery and Restart:
Persistent updates to message queues happen in two stages. First, the records representing the update are written to the log, then the queue file is updated. The log files can thus become more up-to-date than the queue files.
Another, same doc, from table 19 log overhead:
Put persistent message 750 bytes + message length
From the APG:
Persistent messages are written to logs and queue data files. _________________ 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 |
|
 |
|