| Author |
Message
|
| spfdgio |
 Posted: Fri Jan 07, 2005 6:45 am Post subject: AMQ7469 - why? |
 |
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Running MQ v5.3 CSD05 on AIX. Starting to receive the following msg during the time period when I run a scheduled rcdmqimg to record all objects. I run a scheduled rcdmqimg every 2 hrs to this qmgr.
12/30/04 16:01:24
AMQ7469: Transactions rolled back to release log space.
EXPLANATION:
The log space for the queue manager is becoming full. One or more long-running transactions have been rolled back to release log space so that the queue manager can continue to process requests.
ACTION:
Try to ensure that the duration of your transactions is not excessive. Consider increasing the size of the log to allow transactions to last longer before the log starts to become full.
My qm.ini LOG definition for this qmgr is as follows:
Log:
LogPrimaryFiles=10
LogSecondaryFiles=40
LogFilePages=1024
LogBufferPages=17
I have about 6gb of space on the mount point backing only these logs and do not run out of physical space. I also have a substantial amount of quite large messages on multiple queues to backup.....usually the rcdmqimg runs for about 2 minutes wall clock time before being done. We use a lot of logs per minute as well.
I read the sysadmin manual - but still unsure of a few things.
1) What is the long running transaction that is being backed out and how can I see it (or them)?
2) What can I do to tune better so that I don't encounter this problem?
3) How can I proactively calculate 'good numbers' so that I know ahead of time when I am out of space?
Thank you! Dan in Harrisburg..... |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Fri Jan 07, 2005 7:12 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
You are running out of ~/active log space. From your post:
| Code: |
LogPrimaryFiles=10
LogSecondaryFiles=40
LogFilePages=1024
LogBufferPages=17
|
Since you stated you have 6gb of space I would suggest editing your qm.ini to the following:
| Code: |
LogPrimaryFiles=60
LogSecondaryFiles=3
LogFilePages=1024
LogBufferPages=512
|
Then stop and restart the MQManager. This should give you 13 more 4meg logs and buy you some time.
Eventually you will want to consider either reducing the amount of persistent messages going through the MQManager or increasing the size of your logs.
Are you using Circular or Linear logging?
If you are using Circular logging I don't believe you will be able to recover your MQManager using the rcdmqimg/rcrmqobj utilities. I have always been left with the impression that these utilities can only be successfully used with Linear logging.
That being said if you are using Circular Logging you may be wasting your time running the rcdmqimg tool. If you just want to backup the objects on your MQManager (Queues, Channels, etc) use:
MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs
http://www-1.ibm.com/support/docview.wss?rs=203&q1=mA1J&uid=swg24000673&loc=en_US&cs=utf-8&lang=en
The saveqmgr script will build a text file that you can use to recreate the objects in your MQManager.
If you wish to switch from Circular to Linear Logging or increase the size of the defined logs in the ~/active you will have to delete then re-create the MQManager.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| spfdgio |
| Posted: Fri Jan 07, 2005 9:57 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
| Thanks for the update - yes, Linear logging and yes, doing saveqmgr. I am leary of making changes without understanding what is causing the issue or how I can tell what numbers I should expect to see. One concern is not knowing which long running transaction(s) was backed out - I don't understand why the MQ code just doesn't provide this info when it issues the message. My applications are either coded to recover or ignore the MQRC_RESOURCE_PROBLEM. If I increase LogBufferPages to 512, will this have any negative impact or counter-tuning issues to my running MQ qmgr? |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Jan 07, 2005 10:12 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
| Quote: |
| Thanks for the update - yes, Linear logging and yes, doing saveqmgr. |
Sorry, I don't understand. Did you mean yes, you are using Linear Logging? Is LogType=LINEAR or CIRCULAR?
Larger buffers lead to higher throughput, especially for larger messages.
Generally having larger BufferPages will not have a negative impact performance.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| spfdgio |
| Posted: Mon Jan 10, 2005 9:12 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Yes, I am using Linear logging LogType=Linear. Sorry I wasn't clear before. I spoke with IBM about this and I believe I understand the issue now. We have lots of large messages being stored on the queues of the qmgr in question, and seems that when rcdmqimg is issued they take up all the space in my working active/secondary log set. Seems the message 'long running transaction' being backed out is really not accurate in my case.....the trans being backed out may be recent but backed out due to so much stuff being recorded by rcdmqimg. I was advised (as you suggested) to increase my logs...however, with only 13 more possible, it would only give me about 50mb which is not enough. I need to get the large messages out of this qmgr and/or redefine my qmgr to increase the logfilepages to give me much more than 4mb each log - perhaps to 64mb each. I am pursuing these actions - along with the logbuffer pages increase you suggested. Do these actions make sense or can you supply any wisdom into these thoughts? Thanks, Dan  |
|
| Back to top |
|
|
| csmith28 |
| Posted: Mon Jan 10, 2005 9:48 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
Well, to increase the logfile sizes you need to delete then re-create the MQManager. There is a way to cheat on this called Cold Booting the MQManager but it is not supported by IBM if you do it that way.
If you have 6gig dedicated you will need to figure out how many 64meg log files you can create while not exceeding and alert threshold.
On one of my MQManagers Servers I have 9gig devoted to /var/mqm/logs with 60 primary logs and 3 Secondary, 64meg size. The 60 Primary logs consume 79% of the 9gig. This means that if the MQManager starts creating the secondary logs the /var/mqm/log filesystem will quickly reach 80% capacity and start to alert.
So if you don't have any extra space you could go with 40 64meg Primary logs and your choice of secondary.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| spfdgio |
| Posted: Wed Jan 12, 2005 8:18 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
| Thank you....good update, I appreciate it. Im going to recreate the qmgr and bring the size up to 64MB and then see how much more dasd I can get before deciding on the pri/sec numbers. I also figure we can run rcdmqimg less often and just be more exposed to a point-in-time recovery scenario, which we have no firm business requirements at this point. I think this wraps up my concern.....take care and talk later, Dan |
|
| Back to top |
|
|
|
|
