Author |
Message
|
csmith28 |
Posted: Fri May 13, 2005 8:05 am Post subject: LogWriteIntegrity? |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
W2003 Server
WMQ 5.3.0.0
Can the LogWriteIntegrity value be modified for an existing WMQManager without having to delete and re-create it?
Also what about LogBufferPages?
Can I alter these fields in the registry and bounce the MQManager to have them take affect?
I am pretty sure this is the case because the WMQ Admin Guide doesn't specifically say that you can't. I just wanted to double check. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
csmith28 |
Posted: Fri May 13, 2005 3:08 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
Yes well, thanks everyone.
Nice to see I can count on you when I have a question. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri May 13, 2005 6:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I haven't messed with this parameter...
So I don't know.
And I figured you'd already given the docs a good once over.
So where can I help?  _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
vennela |
Posted: Sat May 14, 2005 2:27 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
|
Back to top |
|
 |
xxx |
Posted: Sat May 14, 2005 10:39 pm Post subject: |
|
|
Centurion
Joined: 13 Oct 2003 Posts: 137
|
http://www.mqug.org.uk/anonftp/021131%20-%20performance.pdf
you can change it , But I don't know why we need to change that , any performace issues ?
The other parameter vennala mentioned yes , we definetly should change that to a higher value than default 17
------
If you do have a high performance cached disc subsystem, you can take
advantage of setting LogWriteIntegrity to SINGLE.
Default is LogWriteIntegrity = TRIPLE.
WMQ log files are structured into pages
Optimally, will always write a full page of data. However, if not sufficient
logging througput, then need to write a partial page. For some disc systems,
filling the remainder of the page can wipe out the start of the page, thus we
write the full page in 3 stages for safety.
1) partial page into page 1 2) put remainder of what will be page 1 into page 2 3) copy contents of partial page 1 and partial page 2 into full page 1.
LogWriteIntegrity = SINGLE allows the safe writing of a partial page of data
for devices that will not accidentally overwrite the data at the start of the
page. Gives a good performance improvement for logging.
------------------------------------------------------- |
|
Back to top |
|
 |
csmith28 |
Posted: Sun May 15, 2005 6:31 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
@xxx et all
The reason I was asking is that I have recently inherited five MQManagers on w2003 Severs. The were created with only 10/1meg Circular Primary logs, with TripleWrites and the default LogBufferPages. The production instance of this MQManager is cycling through these logs in less than 60 seconds and the only reason I can figure that I am not getting Transaction role back is the messages on this MQManager are very small and the MQManager it self only services one Application.
In the near future I plan to route more traffice through this MQManager. I knew I could modify the LogPrimaryFile attribute but I wasn't sure about the other two attributes.
Thanks everyone. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon May 16, 2005 3:37 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Chris you can and should up LogBufferPages to 512 after a QM is built, especially of performance is a concern. As you already mentioned, upping the # of primary and secondary logs up to a combined 63 is also a good idea.
I would not mess with that LogWriteIntegrity. I remember reading about it and thinking its not worth it to change it. Can't find the quote though....I think it was in one of the performance seminars at last year's MQ conferance. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jul 01, 2005 6:53 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Chris, see this post.
http://www-1.ibm.com/support/docview.wss?rs=172&context=SW900&uid=swg21201935&loc=en_US&cs=utf-8&lang=en
Also, at the conferance, I was in a session for performance where they said if you have SCSI disks, keep it at Triple, but if you had SSA battery backed cached disks, then it is safe to go to Single. When IBM does their performance tests, if the hardware they have has these SSA disks, then they frequently opt for Single write, to safely eek out even better numbers. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Michael Dag |
Posted: Sat Jul 02, 2005 12:05 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
PeterPotkay wrote: |
When IBM does their performance tests, if the hardware they have has these SSA disks, then they frequently opt for Single write, to safely eek out even better numbers. |
if my memory serves me correctly TRIPLE write was introduced in WMQ 5.2, which was known as a "performance" release (not much new functionality introduced)
and TRIPLE in the end gave the same performance as 5.1.
If you moved back to DOUBLE you would see a performance boost in persistent message rates of 20%-30% and way up for SINGLE ...
so much for history...  _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Jul 11, 2005 1:34 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
csmith28 |
Posted: Mon Jul 11, 2005 1:56 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
Thanks Peter. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
|