| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Linear Log sizing |
« View previous topic :: View next topic » |
| Author |
Message
|
| jhalstead |
 Posted: Wed Feb 20, 2002 10:25 am Post subject: |
 |
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Just a quickie on media recovery image size on UNIX.
In the manual, recording a media image is said to take 800 bytes + the image size. Is this image going to consist of every persistent message on a queue when the image is taken? So for instance in my worst case scenario 50,000 messages are on the queues with an average size of 50K.
Therefore the disk space required for the media image Is:
800bytes + Image, where Image is In segments of 15700bytes each with a 300byte overhead.
Now how do I work out the size of the image? Is it the sum of all the persistent messages at the time the image was taken? Given the details above this would be around 2.5Gb... Does that sound right?
If so over half my potential active primary log space is taken up by the media image, is this correct or am I calculating the image size incorrectly?
Thanks
Jamie
[ This Message was edited by: jhalstead on 2002-02-21 01:19 ] |
|
| Back to top |
|
 |
| dgolding |
| Posted: Thu Feb 21, 2002 12:45 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Hi Jamie
Yep, that seems about right - if you have 50,000 50k messages in one or more queues, when you record the image it will be 50,000 x (50k + .8k) = 2.54Gb. Unless you want the recording to miss stuff out 
However, don't confuse 50,000 messages that have been MQPUT'd and then subsequently MQGET'd - in which case the net effect is zero, as all messages have gone - so the RCDMQIMG records - nothing. |
|
| Back to top |
|
|
| jhalstead |
| Posted: Thu Feb 21, 2002 1:20 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Thanks for your help. I was kinda hoping that the image might be compressed or something...
Cheers J |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Feb 21, 2002 4:50 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Hi Jamie
There is a supportpac (MS62) that can be run, say as a CRON job nightly (on Unix systems), which will compress your logfiles (or delete them if you prefer) that are no longer required. It's a PERL script, and will run on NT as well I believe.
BUT logfiles have to stay uncompressed for MQ to write to them, otherwise they'll be being compressed and uncompressed all day long - which will make it
run a bit slower to say the least!
|
|
| Back to top |
|
|
| jhalstead |
| Posted: Thu Feb 21, 2002 9:31 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Thanks for that, when sizing the logs I'm just working on a worst case scenario basis - i.e. application not available to retrieve messages from the queue. Should the media image be taken in to account when determining the number of primary and secondary logs defined when creating the queue manager? I.e. just base the number of log files on the persistent puts, gets , commits, checkpoints and mesage data. Or should this also include the media image?
Alternatively does the number of primary and secondary log files for linear logging act in a similar way to circular logging, i.e. the active ones are only really relevant from the latest checkpoint onwards (during normal operation) - so they need to be sized to cover 10,000 operations?
Thanks Again
Jamie
|
|
| Back to top |
|
|
| jhalstead |
| Posted: Thu Feb 28, 2002 1:34 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Sorry to be a logging bore.
Do I calculate the number of primary and secondary logs required by MQSeries based on 10,000 operations between checkpoints - as I would for circular logging? (MQ v5.2 & no long running transactions).
Thanks
Jamie |
|
| 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
|
|
|
|
