Now on Monday morning (09:00 PST) page usage for this system looks as below. Per SOP, the system was IPLed about 31 hours earlier. I don't know when usage began climbing above zero, but I fully expect that by the end of the week, it will look similar to my earlier posting. Yes, we run health check ASM_LOCAL_SLOT_USAGE. And yes, it begins to complain when any local grows above 30%.
Note that this paging configuration is quite static. It hasn't changed for many months. Certainly last week (previous post) there were no PAGE ADDs or DELETEs. What I do notice now (missed completely before!) is that for each even/odd numbered pair, both on the same unit address on the same DS8* subsystem, usage of the first (even) data set is higher than the odd data set. In *all* cases I created each pair at more or less the same time using the same IDCAMS job. This usage skew, seen here with minor differences, increases through the week (previous post). BTW every IPL is CLPA. Some time last year I added several GB of memory to this LPAR. That reduced paging activity, e.g. fewer alerts from Omegamon, but did not have much effect on page data set usage. LOCAL 18% OK 1208 SYS1.PAGELOC0 LOCAL 10% OK 1208 SYS1.PAGELOC1 LOCAL 16% OK 1308 SYS1.PAGELOC2 LOCAL 10% OK 1308 SYS1.PAGELOC3 LOCAL 18% OK 1207 SYS1.PAGELOC4 LOCAL 11% OK 1207 SYS1.PAGELOC5 LOCAL 17% OK 1218 SYS1.PAGELOC6 LOCAL 10% OK 1218 SYS1.PAGELOC7 . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: "[email protected]" <[email protected]> To: [email protected], Date: 03/03/2013 10:27 PM Subject: Paging Behaviour; was: Re: DFSORT Weirdness Sent by: IBM Mainframe Discussion List <[email protected]> > All data sets are the same size at 5,008 cylinders, half of a 3390-9. > > LOCAL 55% OK 1208 SYS1.PAGELOC0 > LOCAL 34% OK 1208 SYS1.PAGELOC1 > LOCAL 51% OK 1308 SYS1.PAGELOC2 > LOCAL 32% OK 1308 SYS1.PAGELOC3 > LOCAL 53% OK 1207 SYS1.PAGELOC4 > LOCAL 37% OK 1207 SYS1.PAGELOC5 > LOCAL 53% OK 1218 SYS1.PAGELOC6 > LOCAL 35% OK 1218 SYS1.PAGELOC7 > I can remember (but not pinpoint) when usage stayed > very low all week long. Two things come to my mind on this: I have only ever seen wildly different numbers like yours in page data set percentage usage (when they are all the same size) when page data sets were added later, when the rest already had a certain usage. It seemed that adding a page ds doesn't favour that page ds so it reaches the same threshold as the others, but instead it gets pages in round-robin fashion, slowly building up percentage usage, but never reaching the usage of the previous page ds's. In our case, all page ds were the same size, too, and were all behind the same controller. It took an IPL to even out usage. Do you have that CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE) health check active on that system? I once used the exception thrown via the hardcopy log messages to pinpoint that usage increased way before I thought it had increased. It was a gradual creep. I had also seen similar (in my opinion strange) behaviour, and in essence I established a reporting network for storage usage, including total amount of slots and paging rates. By now, that is quite a trend grafic. Some of the behaviour visible in those grafics was also quite unexpected. Mostly, I used the numbers to get those lpars a bit more real storage when we migrated to 1.12 and had several RSM problems that never were found. They went away with just a bit more real storage. But I had to fight tooth and nail for it. One would think that that real storage was intended for my personal enjoyment, the way my management kept withholding it for z/OS while throwing it at z/Linux.... Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
