Reza, What does it matter if the slot count grows the way you described> the slot count does not affect performance, nor does writing those slots. Apart from keeping slot allocation efficient you should not be concerned with a slot usage less than 30%.
So what you are saying is that when the large sorts run there are a lot of DB2 pages with a high UIC, and they are stolen when any jobs using a lot of memory run. That could be DFSORT, but it could also be Hiperbatch, or even LSR VSAM buffer pools. This is exactly the problem I described. So what sort of page-in rate is experienced by DB2, and what is the workload that is affected. If it is batch workload that runs after the sorts then knobbling the sorts may increase the batch critical path more than the page-in delays. I'm not actually hearing a problem. Is transaction response time unacceptable when the page-ins occur? Are the DB2 batch jobs taking 20% longer to complete? It sounds like the DB Admin has an unsavory statistic and not an actual problem. If you slow down the sorts to make his statistic go away are you going to face a new problem with additional IO load, more SORTWK Space, Sort intermediate merge and elongated Sort run times? Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > R Hey > Sent: Monday, January 18, 2010 8:49 PM > To: [email protected] > Subject: Re: [IBM-MAIN] DFSORT memory used & paging > > Ron, > > Originally DBA complained about paging, & how it reduced workflow (in our > monitor). > > I had a look to find that when the big sort jobs, some also use DB2 > after/before the sort, run at the the same time, the demand paging goes up. > > The chart was just a rough drawing to show how the demand paging looks > like, fairly flat, with a few big spikes a month. > > 60+K track is the size of some of the DS being sorted. > > These jobs run regularly, but the paging issue seems to happen when some of > the big sort ones run at the same time. > > After IPL, the slot% is 0, 2 days later is 1.5%, then a few days later may > jump > to 10% at 2230 when the sorts get to run at the same time, remain roughly > the same, then a week later jump to 16%, ...., then a few days later jump to > 25% (at 2345 due to sorts). > > Rez > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
