Unsolved
This post is more than 5 years old
18 Posts
0
1201
November 8th, 2006 07:00
Perma-Cache and PAV
Greetings.
One of our IMS Database-volumes turns out to be very busy with about 90-95% of the IO-load directed at one single database. This volume also displays high IOSQ-time: about 95% of the Responsetime is IOSQTime.
It has been suggested (by EMC) that this volume might be a good candidate for PAV. However, we don't have PAV yet and I understand that PAV is expensive! A colleague suggested that instead of PAV we might use Perma-Cache. Does anybody have any experience with Perma-Cache? Would it be a good way to combat high IOSQTime?
Willem Vermeer
ING Bank
Amsterdam, the Netherlands
One of our IMS Database-volumes turns out to be very busy with about 90-95% of the IO-load directed at one single database. This volume also displays high IOSQ-time: about 95% of the Responsetime is IOSQTime.
It has been suggested (by EMC) that this volume might be a good candidate for PAV. However, we don't have PAV yet and I understand that PAV is expensive! A colleague suggested that instead of PAV we might use Perma-Cache. Does anybody have any experience with Perma-Cache? Would it be a good way to combat high IOSQTime?
Willem Vermeer
ING Bank
Amsterdam, the Netherlands
No Events found!
GlenH
141 Posts
0
November 15th, 2006 13:00
As no-one's had a go at this one I thought i'd try and help out...
Firstly, I'm not a MF guy, and there could be a zillion reasons for your problem... I can talk a little on permacache though...
Permacache will only help you if you have a high %read and a low read hit rate on those volumes. Take a look at the statistics for those devices in performance manager... A low read hit rate is usually due to a very random workload, and as the symmetrix is unable to predict the track that is being requested you get a longer service time while you wait for the DA to fetch the track from disk. (ie: a read miss)
So if that is the case for you, then permacache may help as it pins all of the tracks for that volume in cache so you are guaranteed a 100% read hit rate..
If you have a low read% and/or a high read hit% already, then using permacache will just take resources un-necessarily and slow the performance down for everyone else on the array.
Permacache does not improve the write performance in any way, so if you think writes are your problem, then enabling it won't change anything.
If you suspect writes are the problem, then look at the device write pending counts - are you hitting the limit for any of the devices ?? If so, then you really need to spread the workload across more or faster drives...
If you do want to enable permacache then i would recommend that you first speak to your local EMC person to ensure that it won't effect negatively impact everyone else - depending on your configuration, you may find you need to purchase additional cache to make it work successfully in your environment.
Glen.
WillemV1
18 Posts
0
November 17th, 2006 02:00
Here's my reply. I hope it will get you my email-address, but just to be sure: willem.vermeer@mail.ing.nl.
Now, about the WADS. I'm not sure how the load on the WADS could result in high IOSQTime for this particular database (which is very Write-intensive). We don't seem to have any problems with the WADS itself and there don't seem to be any problems with just about any other database.
Would striping the database be an option? Does IMS support striped databases? I couldn't find antyhing that says it doesn't, but neither could I find anything that says it does.
Willem.
WillemV1
18 Posts
0
May 3rd, 2010 04:00
This issue isn't relevant anymore, since we've gone over to another supplier for our mainframe-storage. Thanks.