|
Jay, Activity level is released when the job ends ... I'm 99.44% sure of that ... most of those server jobs don't end ... they go into long waits instead. As John Carr said in his post ... there are a lot of interrelated variables that have to be considered ... The main points are: - what goals are you trying to accomplish? - what is the specific situation on your server? Pete Hall's situation (cutting all timeslices in 1/10) might have been OK for a few jobs that misbehaved with a lot of "short code path" jobs (or else he didn't have a lot of contention for memory) ... every situation is different ... those that have one stock answer for tuning a '400 end up missing the point!!! BTW: The Orbb.org database must have scanned us just after our V5R1 update ... the anti-mail-relay mechanism seems to have changed from V4R5. The relay has since been closed (as per orbz.org) ! John At 10:00 AM 2/11/2002, you wrote: >X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for >spam. > >John, > >I liken the tuning of the timeslices to the high speed jet on a carburator. >Too rich (ie too large a time slice) and it bogs down on heavy load and >won't recover till the load is removed. Too lean (ie too small a time slice) >and the system really sputters. On the AS/400-iSeries that would equate to >Wait-to-Inel. So far that hasn't occured with the timeslices I have >currently set. I wonder if anyone has hit the point of too-lean. > >It is my understanding that the 400 will hold that memory until the >timeslice is complete, even if the job has long past completed. That is why >I keep trying smaller timeslices. > >The other classes I mentioned are for TCP and Spool services. If a TCP >service has a 2000 millisecond timeslice and the transaction only takes 20 >milliseconds, then given the heavy TCP load on today's 400's (iSeries), >there would be more memory that could be recovered for immediate processing. > >I think this is important on the 7XX boxes, cause IBM chooses to kill the >batch CPW when the interactive feature is maxed. > >Thanks for your feedback. > >Jay > >p.s. your email server has hit the ORDB database. >X-RBL-Warning: Blackholed by ORDB -- see ><http://ordb.org/lookup/?host=207.113.29.10> > > >----- Original Message ----- >From: "John Myers - MM" <jmyersmm@sbsusa.com> >To: <midrange-l@midrange.com> >Sent: Friday, February 08, 2002 3:20 PM >Subject: SPAM: Re: Timeslice recommendations > > > > Jay, > > > > If you don't know what they are (I don't recognize them either), don't > > touch them! You can back into what they do by matching up the routing >data > > on the routing step that uses the class with various system job >descriptions. > > > > Timeslice values should not be driven by the speed of the main processor >or > > the amount of Interactive CPW that you have purchased! > > > > The purpose for timeslices is to determine what is the maximum time a task > > has access to an activity level (being resident in memory) before you make > > it compete to keep it. > > > > It is generally a bad thing if a routine interactive task has to give up > > its activity level before it concludes. Someone running a "batch-like" > > task in Interactive is another story. Some application software packages > > have very long code paths that take awhile to complete. Others have very > > short code paths & will complete in a much shorter time. The times also > > vary with the number of tasks that are resident in memory at once! The > > correct timeslice values for Interactive can vary greatly between systems. > > > > Like any other performance tuning issue, the important issue is the goal > > that you are trying to reach & what you are willing to give up to reach > > that goal. > > > > Are you tuning because Interactive performance is slow? > > > > If CFINT has kicked in (& the you are unwilling to buy more processor), > > optimizing your interactive performance is probably the best step. CFINT > > slows down your entire machine. > > > > Do you have Interactive jobs that transition from active to > > ineligible? That is a sign that they are exceeding their timeslice at a > > time when your main memory is over committed. > > > > Sorry for the scattershot answer, but tuning is like seeing a doctor ... > > what do you say after saying AAAHHHHHHHHH???? > > > > Hope this helps! > > > > John Myers > > > >_______________________________________________ >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.