| Author |
Message
|
| itsmaveric |
 Posted: Tue Mar 05, 2013 8:47 am Post subject: MQ Log striping on zOS |
 |
|
Novice
Joined: 24 May 2007
Posts: 18
Location: Singapore
|
We are planing to implement stripe active log data set for MQ . As IBM suggested we can have upto 16 Stripes .
Has IBM bench-marked logging rates with various stripe counts ? I have been trying to find this information in IBM site , Info Center and MP16 . But could not find the logging rates vs stripe counts details .
Please let me know if any one has any info related to the same .
Many Thanks ,
Sam |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Tue Mar 05, 2013 8:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Why do you want to implement data striping? Do you have real 3390 dasd devices?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 05, 2013 11:16 am Post subject: Re: MQ Log striping on zOS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| itsmaveric wrote: |
| We are planing to implement stripe active log data set for MQ . |
Why? What's led you to decide this is something you need to do?
| itsmaveric wrote: |
| As IBM suggested we can have upto 16 Stripes |
Under what circumstances did IBM suggest this to you?
| itsmaveric wrote: |
| Please let me know if any one has any info related to the same . |
I would imagine the same source as the advice to stripe your logs would be the best place to source this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 05, 2013 11:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Data striping made sense for large datasets that are read sequentially from real 3390 DASD devices.
Logs are rarely, if ever, read from beginning to end. Logs are not large datasets in this context. Few shops have real 3390 DASD devices.
Did someone from IBM recommend this for a specific purpose? Or did you discover data striping in documentation?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Tue Mar 05, 2013 12:23 pm; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 05, 2013 12:18 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to mainframe forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Wed Mar 06, 2013 3:51 am Post subject: We recommend striping across 4 volumes |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
| We have seen customers improve their throughput by more than 15% by striping across 4 volumes when the log was the major bottleneck. More that that has not been any more effective. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 06, 2013 4:11 am Post subject: Re: We recommend striping across 4 volumes |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| elkinsc wrote: |
| We have seen customers improve their throughput by more than 15% by striping across 4 volumes when the log was the major bottleneck. More that that has not been any more effective. |
15% improvement in throughput of what exactly?
How was the decision made to stripe? What rmf data supported the decision? How was the 15% measured?
What type of dasd hardware? DS8000? Other?
Was the log dataset the actual bottleneck? Or was it the dasd device or control unit that was the bottleneck?
What other tuning efforts preceded data striping?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Wed Mar 06, 2013 4:41 am Post subject: |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
How was the decision made to stripe?
This has long been known and documented to improve throughput on the sequentially written log files. Please see SupportPac MP16.
What rmf data supported the decision?
I primarily look at the MQ SMF, and observe extended elapsed times and MQ internal latching on log requests. Often the DASD management people are swearing there are no bottlenecks, because they are only looking at overall averages.
How was the 15% measured?
Strictly on the volume of messages averaging 8900 bytes that could be processed in a specified period of time. I typically recommend at least an hour of steady state processing.
What type of dasd hardware? DS8000? Other?
I have seen this on various hardware types.
Was the log dataset the actual bottleneck?
Or was it the dasd device or control unit that was the bottleneck?
Seen problems in all areas. If they are having control unit contentions, while MQ might be a leading indicator their DASD people should catch that (she said hopefully!).
What other tuning efforts preceded data striping?
The traditional evaluation of the bufferpool, CF, etc. However the SMF116 class 3 data clearly showed significant ET and latching on log requests (as above). While not definitive without the RMF, it is a good key indicator. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 06, 2013 6:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If RMF confirms device contention, then striping might offer relief.
But, with smf data confirming internal software contention (latching), and NO rmf data confirming device contention, you implemented a hardware solution?
This is often described as 'shotgunning' a solution.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 06, 2013 6:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Bruce - Perhaps you should assume that Lynn knows what she's talking about. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 06, 2013 7:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| Bruce - Perhaps you should assume that Lynn knows what she's talking about. |
I do. I meant no offense.
What I'm trying to understand is the rationale behind the decision to stripe. Her responses were surprisingly general for such a technical solution.
RMF offers precise data on hardware utilization, contention and delay. Contention and delays that affect I/O throughput would be easy to identify.
SMF offers precise statistical and accounting data on software utilization..
When I was doing performance tuning, I had to demonstrate to management that actions I was taking were appropriate to the problem/symptom I was addressing.
In this case, latch contention is precisely an MVS and/or WMQ internal software issue. Data striping alone would not relieve latch contention.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
