| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| When is storage freed when msgs are removed from a queue ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| spfdgio |
 Posted: Mon Jan 16, 2006 7:17 am Post subject: When is storage freed when msgs are removed from a queue ? |
 |
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Running MQ v5.3 CSD10 on AIX 5.2 ML5. We had 5 queues which had persistent messages on them (I can see each msg, they were each committed in a single unit of work) which accounted for about 2GB of disk space. We purged all msgs on those queues, but the space was not physically freed. The method I used see this was 2 fold:
1) Went to the physical disk location: /var/mqm/qmgrs/QM1/queues/ and changed directory into each of the 5 queues and the total space used was unchanged for each.
2) Performed a 'df -m | grep /var/mqm/qmgrs' and watched free space stay the same.
-
Went to one of the queues and did an fuser command and saw that a amqzlaa0 process had a handle on it. After about 30min to 1hr or so, the disk space was indeed freed up. Why is there a delay, and is there a way to force the release of disk immediately rather than wait this timeframe? Could the delay be related to updating the logs since the msgs were persistent?
Thanks! Dan in Harrisburg  |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Mon Jan 16, 2006 7:33 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| This subject has come up before. The bottom line is that WMQ will free up the space when it is ready to. You can do some things to try and force it to do it earlier. I can't remember all of the details on what to try. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Jan 16, 2006 7:40 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| spfdgio |
| Posted: Mon Jan 16, 2006 10:20 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Thanks for the responses - I appreciate your time and talent.
-
mquseless - in my situation, I cannot end the qmgr so I suppose I am waiting for 2 checkpoints and no processes holding the queue open. As I indicated, I saw the amqzlaa0 process holding the queue open. From another post, this is said: "Every time an application program does an MQCONN a AMQZLAA process will be started. This acts as the "gateway" between the protected bit of MQ and your bit". So I guess I am waiting for some app to do an MQDISC to the qmgr owning the queues in question.
If I issue a rcdmqimg for the queues in question 2 times, would that count as 2 checkpoints ....that is, is the checkpoint at the queue level or qmgr level? And if I issue a DISPLAY QSTATUS I believe I can identify the app holding the queue opened, but with MQ v5.3 I don't have the DISPLAY CONN or STOP CONN commands to force the app off the qmgr (MQ v6).
I would like to write a script to be run to force the reclaim of space, but it seems it is not possible....?? The thing that bugs me the most is the total lack of control of WHEN I can get my space back. Any further discussion is certainly welcomed.......and much appreciated. Thank you. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 16, 2006 11:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
|
| Back to top |
|
|
| spfdgio |
| Posted: Mon Jan 16, 2006 1:16 pm Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Peter - thank you for the info. Yes- that's exactly what I needed to see. I wish it didn't work that way, but it does and that's just what we have to live with.
Thanks to all who responded!! |
|
| Back to top |
|
|
| spfdgio |
| Posted: Wed Jan 25, 2006 1:18 pm Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Seems there is more to the picture here - the space gets released in a variety of ways, according to this IBM post which expains detail:
http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&q1=How+MQ+reclaims+space+used+by+a+queue&uid=swg21110841&loc=en_US&cs=utf-8&lang=en
I was pretty confused after reading this, so I conducted my own test on AIX and found the following:
1. You first need to clear the queue of messages. If you clear messages from a queue using the RFHUTIL utility, you need to close the tool (or switch to a different queue) to force an MQCLOSE - otherwise the target queue will still show an open handle as a client connection (not ipprocs or opprocs) and the next step wont free the space. Use 'status' on mq/explorer for the queue object to ensure no one has the queue open.
2. After there are no ipprocs/opprocs or channels that have the queue open (channels may if the target queue is a resolution for a QR on a different queue manager) you can issue this command to force (1) checkpoint and your space will be released immediately. You dont need to wait for 2 checkpoints, this will do it:
/usr/bin/rcdmqimg -m QMGR -l -t ql TARGET.QUEUE > /tmp/rcd.out 2>&1
Check the output file to be sure the command was successful.
So the big issue is getting to a point in time where there are no ipprocs/opprocs or open handles to a queue. We found one scenario that seems to work for us, in our situation....just sharing this thought:
We run the WBIMB broker - and the queues we were having problems with were used strictly to hold audit messages which did not feed any further downstream processes. Instead of having to terminate an execution group and cause an outage, we created a new qmgr called AUDIT and made these audit queues local there and referenced via QA/QR definitions from the broker's qmgr. That means that all we have to do is stop the sender channel from the broker's qmgr to the AUDIT qmgr to get the target queue freed of handles. We run the rcdmqimg to force a checkpoint, reclaim space, then start the channel up. Any traffic queued up just sits in the transmit queue and will be sent once the channel is fired up, no loss. Of course, we make sure we code expiration on the target audit queue messages and manage to them daily - but for those times where we just want our space back, this is a good way to get it.
Hope this helps.....if anyone finds anything in this post to clarify or correct, please do so. Anyone else with similar experiences is welcomed!
Thanks again, Dan in Harrisburg, PA |
|
| 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
|
|
|
|
