Reza, You should not be concerned about Page Out rates. Page out does not interrupt the flow of a program - it's being paged out because it has not been referenced recently.
If there is a page fault for that page very soon after the page out and it is still unchanged then there is no actual page-in. In terms of actual juice (MIPS) used for page-out, you would have to be generating a sustained page-out rate of several thousand pages a second to use any substantial "juice." ASM is very efficient. The usual problem with pages being pushed out by SORT is that OLTP regions that are relatively inactive during the batch run have their pages stolen, and then suffer page delays when the business opens its doors several hours later. While these pages remain unchanged on AUX they become cannon fodder for page stealing when the SORTS run the following night. In the note below you talk about page out and page in as if they produce a common delay, but they do note. You then show what appears to be some sort daily plot that shows a high DPR six times a month. Then I'm lost again because you give a Demand Paging "unit" of 60,000 tracks, and I don't know how to correlate that to anything. Do you mean that is 60Kx12x4KB blocks over a day (8.3/sec) or, an hour (200/sec), or a 15 minute RMF interval (800/sec). I think it's the reference to tracks that is throwing me. Page stealing rarely affects batch jobs themselves, as their pages usually have a low UIC while there running, and will not be used again when the job ends. Jobs that start after the sorts are unaffected because they weren't in the system when the pages were stolen. That simple logic - maybe over simple - is why I believe I have not run across DFSORT delaying batch runs. It is usually OLTP regions and long running STC that are affected by the ensuing page-ins. If you think Page-ins are causing some delay then I suggest looking at the ASID level page-in rates in the SMF type 30 interval records and see what Service Classes or Workload types are experiencing a page-in problem after the sorts are finished, and how long that rate is sustained. If your SMF interval is too long, start an RMF II Background session at 5 second intervals and look at the PIN rates for each ASID using "ASD A,A" This will give a very detailed profile of where your Page-in rate is going, and whether it is hurting one of the loved ones. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > R Hey > Sent: Monday, January 18, 2010 4:20 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] DFSORT memory used & paging > > By %USE I meant page slots used, meaning increase in page out. > > > Why does workflow drop from %use? > > too much juice wasted on paging out/in. > > The issue is not page config, but increase in paging out/in & drop in > workflow. > > So when we look at demand paging for the month, we roughly see: > > ......|...........|..............|........... > ......|...........|..............|........... > ......|...........|..............|............ > ----|--------|----------|-------- > > the spikes are when a few big sort jobs end up running at the same time. > > data involved is bigger than 60K tracks. > > Rgds, > Rez > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
