| Author |
Message
|
| Ward |
 Posted: Wed Feb 11, 2004 8:20 am Post subject: SYSTEM.CLUSTER.REPOSITORY.QUEUE growing |
 |
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
Hi,
During some problems with our cluster removing and adding a few queue managers we invoked a few times the REFRESH CLUSTER(xxx) command. Each time we executed this command the SYSTEM.CLUSTER.REPOSITORY.QUEUE seemed to grow considerably. I was convinced this command would empty the queue and rebuild it with the new information but it seems to leave all the old info on there. Is there a safe way to get rid of it and rebuild this local repository ? We're using MQ 5.2 CSD 5 on AIX.
Thanks,
Ward. |
|
| Back to top |
|
 |
| JasonE |
| Posted: Wed Feb 11, 2004 9:40 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
How many records and what is the maxumsgs of the qmgr. It compacts when a certain number of records are on the queue (max 5000, I think), otherwise all is probably ok.
I assume amqrrmfa is still running, and that the system.cluster.command.queue is mostly 0 |
|
| Back to top |
|
|
| Ward |
| Posted: Wed Feb 11, 2004 1:39 pm Post subject: |
|
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
Yes, amqrrmfa is still running, and the system.cluster.command.queue is mostly 0.
The max queue depth of those system queues is (by default, I believe) 640000, so there's no risk of them filling up that easy.
What I was worrying about is that by executing a Refresh Cluster command only new messages are added and none are removed. Although most of those messages are pretty small, few of them are quite large and for sure a lot of the messages (probably two thirds in our case) are superseded. So I'd like to tidy things up... |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 11, 2004 1:44 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| Ward wrote: |
| So I'd like to tidy things up... |
just shutdown and restart your Qmgrs regularly (not on a daily basis...  ), the restart process rebuilds the repository on the REPOSITORY queue and 'compresses' the info that is needed.
try and see on a test system.
Michael |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Feb 11, 2004 2:05 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Every so often, amqrrmfa will compress the repository queue records, you dont need to restart. Even refreshes, deletes, reinsertions etc will get sorted out and the redundant ones removed - dont worry about it unless the depth goes over about 5000 (off the top of my head we should compress before then). |
|
| Back to top |
|
|
| Ward |
| Posted: Wed Feb 11, 2004 2:21 pm Post subject: |
|
|
Voyager
Joined: 27 Jun 2001
Posts: 98
Location: Europe
|
OK, thanks...
Queue depth is close to 4000 for the moment, will keep an eye on it and try not to worry  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 13, 2004 3:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Yes, the depth of the SYSTEM.CLUSTER.REPOSITORY.QUEUE is mysterious indeed! One day I just kept issuing the REFRESH command. The depth would go up by about 230 each time, until it came to a 1000. Then it would rollover and start from a low number again.
The weird thing was if I issued REFRESH and the depth was 900, it would go to 130. If it was at 800, it would go to 30! If it kept going up by about 230 each time, how in the world could it end up with some number substationally less than 230 for a depth and keep working? 
This is a cluster of 3 QMS with about 300 queues. Obviously it is not a one to one relationship. That's what I though it was, because if the depth was n, and I added a new queue to the cluster, the depth would always go up by one. But apparantly this REFRESH command is doing some weird stuff under the covers, like Jason said.
Now that we are 5.3 CSD04, we have not seen a cluster so screwed up where we felt the only solution was to empty the repository queue and start from scratch, something we had to do a few times back at 5.2. I'm sure we have also learned about clustering as well since then, eliminating problems we caused for ourselves to begin with.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JasonE |
| Posted: Sat Feb 14, 2004 12:27 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Think of the repository manager as a process which gets commands and puts responses to appropriate places. Just before the get, if we think we need to compress, then we do it. The get though may come back with (in your case) a refresh command, which results in messages put to our own queue and to other qmgrs command queues (and ones from them coming back). Hence until we have finished the processing of that message we dont get around to the compress phase again.
Now its not quite that simple, as refresh is a real killer for this, so during the processing of some commands we also check the message counts. The thing we cant afford to hit is maxumsgs, so the limit is based around that. Have you changed yours by any chance? I really cant remember how the calculation is done (and cant be bothered to look...), so 1000 may not be odd either. |
|
| Back to top |
|
|
|
|
