|
Steve, I'm not sure that it would cause thrashing, (where the OS is spending more energy paging stuff in and out of memory than it is running jobs). But you have a very valid point about mixing classes. If half of your activity levels are allocated to jobs running under the QBATCH class (default timeslice of 5 seconds), then jobs running under the QINTER class (default timeslice of 2 seconds) will need to wait longer for an activity level. Thus your interactive jobs will suffer a greater lag when it needs to page into memory. If I recall correctly, the run priority level will only have an impact when it comes time to get an activity level, once the a job has an activity level, it will keep it until the end of it's timeslice. Regards, Andy Nolen-Parkhouse > On Behalf Of Steve Landess > Subject: Re: Why not *SHRPOOL1? > > Yes. You are right. > > If you have different subsystems sharing a memory pool, the jobs > running > within the shared memory pool can have different time slice/run > priority, > based on the class that was used to start a given job. Interactive > jobs > typically use a short time slice with a low run priority {say > timeslice(500), runpty(20)}, and batch jobs typically use a longer time > slice with a higher run priority {say timeslice(5000), runpty(50)}. > > Based on this fact, the point I was trying to make is that it is not a > good > practice to have batch jobs _and_ interactive jobs running in the same > memory pool. You need to balance the working being performed in a > given > memory pool to have jobs that are alike in timeslice/run priority > running in > that pool. This helps prevent system thrashing. > > This goes back to the early days of performance tuning on the > S/38...I'm > sure that if you read more about this in the Work Management Guide, > you'll > see what I am talking about. As a matter of fact, I'll go look there > and > see if I can't find a reference to forward to you. > > Al - please correct me if I am wrong... > > Steve Landess > Austin, Texas > (512) 423-0935
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.