A couple of weeks ago, I posted a question to the list about our storage pool
performance (the original note is attached to the bottom of this note.) I
want to thank the people who took the time to respond and provide suggestions
and comparisons to other devices.
We did some analysis, and came up with the realization that, in the words of
that comic strip icon Pogo "We have me the enemy, and he is Us!" (I
apologize to those of you not fluent in American Comics.) What we
hypothesized was that since we run our storage pools with caching enabled,
and since we have been doing this for a period of at least 4 years, there was
a good chance that the pool itself was extremely fragmented. We speculated
that even a small request for space was being spread across more than one
volume. The effect was that every data request was being scattered across
the 25 volumes in almost a random order.
The good news was that we were able to attempt to validate our idea very
easily. We turned off caching on the pool, and then let it drain out over
the weekend. On Monday we came in, and saw that there was now only about 4%
residual data that was still being cached (we only go down to 5% as a low
threshold). Stats for the devices have shown amazing improvement - device
disconnect time has dropped from 79ms to 2ms. At the same time, the IO rate
has increased accordingly. And more obviously, tasks such as migrations now
run in less than half the time - just this morning we did a migration of
approximately 32GB in less than an hour (running 4 concurrent processes.)
Thanks again to all of you who responded.
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: ADSM Storage Pool Performance
Author: Jerry Lawson at TEKPO
Date: 11/29/99 9:17 AM
Date: November 29, 1999 Time: 9:02 AM
From: Jerry Lawson
The Hartford Insurance Group
(860) 547-2960 jlawson AT thehartford DOT com
-----------------------------------------------------------------------------
The guy who handles MVS Performance came to me with the some concern over the
The guy who handles MVS Performance came to me with the some concern over the
DASD response that ADSM was getting - specifically with our storage pool
volumes. We did some analysis, and of course determined that the response
problems were mapping to the times when migrations or storage pool backups
were running. I asked him to write up what he saw as a question that we could
post to the list. Here is his observation:
Our ADSM server storage pool is spread over 25 separate DASD volumes across 5
different SVAs (Shared Virtual Array). During our backup and migration
processes, we appear to get very poor response time for these DASD volumes.
At sustained I/O rates of 1 to 1.5 I/Os per second spread across all of the
pool volumes, our DASD response times for these volumes consistently rides at
our above 150 milliseconds. Two thirds of this appears to be DISCONNECT with
the other portion attributable to CONNECT for the most part. Device
utilization for these volumes appears to ride around 15%. These DASD volumes
compare very poorly - performance-wise - to the rest of our DASD farm.
Do you have any thoughts or suggestions as to how we may address this or do
you believe that this is simply a by-product of the product's normal
workings. Any suggestions would be appreciated.
--------
I should probably add that the SVA is the latest and greatest STK DASD - the
I should probably add that the SVA is the latest and greatest STK DASD - the
next upgrade after the RVA vesrion that IBM marketed. We use 3380K images as
the device types, for a total of 34GB of DASD. I should note that during
this same time, the DB, which is also mapped over the same set of devices,
does not have a response problem.
-----------------------------------------------------------------------------
Jerry
Jerry
|
