| Author |
Message
|
| angka |
 Posted: Thu Jan 04, 2007 10:43 pm Post subject: Queue File size |
 |
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
Is there any limit on the queue file size?? The MQ document state "WebSphere MQ supports queues larger than 2 GB" so it means it limits the queue file size to the disk size?
Btw queue file will not be deleted when the message is deleted from the queue?? it will only overwrites when new messages come in and deletes when the queue manager restart?? Thanks |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Thu Jan 04, 2007 10:57 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Jan 04, 2007 11:31 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Version 5.3 QMgrs (Unix and Windows - not z/OS) support Q file size larger than 2 GB. But it depends on the operating system, if Qs may really become larger than 2 GB.
Ask you system administrator, if the operating system supports large files!
_________________
Regards
Hubert |
|
| Back to top |
|
|
| angka |
| Posted: Fri Jan 05, 2007 1:36 am Post subject: Re: Queue File size |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
| angka wrote: |
Hi,
Is there any limit on the queue file size?? The MQ document state "WebSphere MQ supports queues larger than 2 GB" so it means it limits the queue file size to the disk size?
Btw queue file will not be deleted when the message is deleted from the queue?? it will only overwrites when new messages come in and deletes when the queue manager restart?? Thanks |
Hi,
Thanks... But how about my second question. cant find much info from the Documentation.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 05, 2007 1:48 am Post subject: Re: Queue File size |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| angka wrote: |
| Btw queue file will not be deleted when the message is deleted from the queue?? it will only overwrites when new messages come in and deletes when the queue manager restart?? Thanks |
AFAIK the file is created when the queue is defined, and only changes when more/less space is needed; all managed by the queue manager internally. Certainly not deleted when the queue manager restarts - persistant messages would be a bit tricky if it did!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| angka |
| Posted: Fri Jan 05, 2007 2:24 am Post subject: |
|
|
Chevalier
Joined: 20 Sep 2005
Posts: 406
|
Hi,
What I meant is the file will still be there just tt the message header and data is deleted for non persistent message and thus the file size changes to a smaller value... I tested on MQ V6 on Windows platform it seems to work this way.. The reason why i post ths question is if a queue is filled up to a few hundred mb, and after clearing the queue, the file will stay til a few hundred mb if the queue manager is not restarted thus it will take up disk space. Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 05, 2007 2:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
As I posted previously, the queue manager handles expansion contraction internally and I'm not aware of any way that can be influenced (admin command or similar).
There are clearly 3 schools of thought regarding physical queue size:
1) Queues should always be nearly empty in a properly running system so allocate enough disc to hold a few messages;
2) As 1 but allocate enough space to hold all the messages recieved during the most likely outage period or most likely backlog;
3) Allocate enough space to service the queue at max depth.
Given how cheap disc is these days 3 is not as uncommon as it used to be, and is a wonderfully low maintenance solution. 1 relies on very proactive monitoring and intervention. I personally go for 2 with an extra 20% on the top for safety, and making sure the MQ "out of disc" error (the code for which I can't remember atm) is properly caught by the monitoring software.
Unless it's a high availability situation where I go for 3!
My 2 cents. Other views are equally valid.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
