Queue Depth Buckets.docx
2
Queue Depth Buckets STP collects data at a pre-determined pace which is usually around 5, 10 or 15 minutes. As such, its reported values represent the average value for the collection time period. It was often requested that queue depth also be reported. The traditional way of reporting queue depths has been a sampling technique (although there are other methods) which presented the queue depth at the time of the data collection. Another method was to accumulate all of the queue depths seen by each IO and then present an average queue depth for the time interval (the CLARiiON technique). The problem has always been as to how to establish or show that bursts of IO occurred during the time interval. A new set of metrics has been implemented for Front- end directors in order to explore the possibility of using a new technique (built on an old method) to be able to identify if activity bursts occurred during the past time interval. 1 A set of buckets was established for the director IO queue. The number of buckets, although fixed for now as follows: Open Systems Mainfram e 0 0 5 7 10 15 20 23 40 31 80 39 160 47 320 55 640 63 >640 >63 2 Each bucket represents a range of queue depths seen when an item is added to the queue.
-
Upload
montecito1 -
Category
Documents
-
view
212 -
download
0
Transcript of Queue Depth Buckets.docx
Queue Depth Buckets
STP collects data at a pre-determined pace which is usually around 5, 10 or 15 minutes. As such, its reported values represent the average value for the collection time period. It was often requested that queue depth also be reported. The traditional way of reporting queue depths has been a sampling technique (although there are other methods) which presented the queue depth at the time of the data collection. Another method was to accumulate all of the queue depths seen by each IO and then present an average queue depth for the time interval (the CLARiiON technique). The problem has always been as to how to establish or show that bursts of IO occurred during the time interval.
A new set of metrics has been implemented for Front-enddirectors in order to explore the possibility of using a new technique (built on an old method) to be able to identify if activity bursts occurred during the past time interval.
1 A set of buckets was established for the director IO queue. The number of buckets, although fixed for now as follows:
Open SystemsMainframe
00
57
1015
2023
4031
8039
16047
32055
64063
>640>63
2 Each bucket represents a range of queue depths seen when an item is added to the queue.
3 Two counters are maintained for each bucket
queue depth count Number of events when the queue is within this buckets range
accumulated queue depth The Sum of the Queue Depths when an event enters this bucket
So, when an IO enters the queue (comes from a host to the director) the first thing checked is the depth of the queue at that moment. Two things happen:
A The appropriate accumulated queue depth bucket is incremented by the queue depth value observed.
B The queue depth count is incremented by 1 (one more IO for this bucket)
For each of the buckets an average queue depth is calculated by dividing the accumulated queue depth by queue depth count.
When viewing the queue depth bucket metrics one needs to view the Average Queue Depth Range graph along with the queue depth count graph. The reason for that is that the Average queue depth range alone may raise eyebrows due to its existence but the queue depth count associated with that bucket will tell you whether there were a significant number of IOs that encountered that queue depth and thus may indicate a burst of IOs and thus longer queues.
