On Wed, 1 Feb 2012 23:12:48 -0600, Barbara Nitz <nitz-...@gmx.net> wrote:
>>So if I have 5 3390-27 locals and they are all equally used at 50%, the >>algorithms (CPU usage, not I/O) are going to pick one of them, then do the >>page outs. That paging will find contiguous slots and should be efficient. >> >>BTW, this is just an example, we still try to keep our 3390-27 local usage >>at 30% just like we always did with smaller local page datasets in >>the past. >> >>I wonder what if any studies on this have been done in the lab. >>It would be nice if an IBM performance expert like Kathy Walsh >>could weigh in. > >I had the 'honour' of deleting and adding several local page data sets on >several lpars. They were a mixture of 1.10 and 1.12, I think. What I did >observe (and that clashed with what I thought I knew about ASM) is the >following: > >1) Adding one or more locals, I expected them to first fill up to about the >same percentage as the ones that were already in use (same size page ds, much >faster -new- controller). No such luck. It looked to me like *all* of them >were filling up (percentage wise) in about the same manner. Meaning that the >'old' locals had about 27%, the new ones right after add 0%. A day later the >old ones had 35%, the new ones 8%. About the same behaviour when adding locals >of the same size on the same controller - we only have one DASD controller per >sysplex, and having two was the time when we migrated from one to the other. > Sounds like they all had contiguous slots and were used evenly based on that. >2) A pagedel finishes MUCH faster than it ever did. It looked like ASM is >actively shifting slots away from the to-be-deleted page data set. A pagedel >finishes in under a minute. This used to be a really slow process because >nothing was actively done. > >3) In one case, I had two locals and pagedel'd one of them. Usage of the >remaining one went up to 46%, pagedel was extremely fast. I then added a new >local (on a new, different, much faster controller). Usage of that one stayed >at 0% for a long time, which also surprised me. *WARNING* If you are going to be replacing page datasets, better to use the REPLACE option of PAGEDEL as opposed to DELETE then doing a PAGEADD. Not doing so can lead to ESQA shortages. See the MVS commands manual for more detail. <snip> > > >6) I bemoan IBMs failure to give us a good means of figuring out who is using >HVSHARE or HVCOMMON storage and how much storage-above-the-bar is actually >*used*, i.e. backed. As far as I know, there still isn't any tracking done for >HVCOMMON storage, no means of reporting about it. No way to know who is >excessively using common storage above the bar. Same for HVSHARE. Unless >you're named Jim Mulder and know where to look in a dump, us lowly customers >cannot even check that in a dump. Am I mistaken in the reporting capabilities? >Has that been fixed by now? Or is it another means of IBM trying to sell $$$$ >software service contracts to get that done only by IBM? Not to mention the >frustration until you find someone who can actually *do* it. > Not sure how much info you are looking for, but there is RMF III and my RXSTOR64 exec on my web site / CBT file 434. If you want to see what the sample output looks like, here is a screen shot - http://www.mzelden.com/rxstor64.html Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
