OC.CAR@CU20B.COLUMBIA.EDU (Claire Russell) (12/05/85)
Why does VMS 4.2 give memory to idle terminal jobs?? Has anyone noticed this ? On our system, idle terminal jobs hold onto their memory (up to WSDEFAULT) and are not trimmed or swapped out even though they have been idle for hours and memory is in demand. We are using the default system parameters, LONGWAIT and DORMANTWAIT are 30 and 10 seconds.... Claire Russell -------
iglesias@UCI.EDU (Mike Iglesias) (12/06/85)
You might try setting PFRATL and PFRATH to something other than the defaults. Setting PFRATL causes VMS to start swiping pages away from jobs that have a low page rate. We had horrible response on our 4mb 780 until we changed PFRATL (and PFRATH), because jobs would expand up to WSQUOTA and stay there. Now they fluctuate up to WSQUOTA. See the explaination in the VMS guide to performance. Mike Iglesias University of California, Irvine
garry@LASSPVAX.TN.CORNELL.EDU (Garry Wiegand) (12/10/85)
In article <mumble> OC.CAR@CU20B.COLUMBIA.EDU (Claire Russell) writes: > > Why does VMS 4.2 give memory to idle terminal jobs?? Has anyone > noticed this ? On our system, idle terminal jobs hold onto their > memory (up to WSDEFAULT) and are not trimmed or swapped out even > though they have been idle for hours and memory is in demand. We > are using the default system parameters, LONGWAIT and DORMANTWAIT > are 30 and 10 seconds.... > I noticed this a good while ago. My best guess is that working sets may only be adjusted below WSDEFAULT via the WSINC and WSDEC mechanism, and that this only happens at quantum end. An idle process, of course, isn't having any. So it sits on its physical memory till swap do it part. You might (if you're brave) try making WSDEF and WSQUO both very small, and relying on the WSEXTENT mechanism instead to give memory to people... Another scheduling/adjusting problem I'd like to hear comment on: I've noticed several times recently that some batch jobs can drastically afflict interactive job performance, despite the batch jobs running at at much lower priorities (1 vs 6 around here). The offenders are usually heavy page faulters. My only guess so far is that if the batch job can get even a sliver of CPU time, and faults instantly, the paging I/O requests can saturate the disk, priorities-or- no-priorities. The only fix I've found is STOP/QUEUE (which conveniently suspends all the active batch jobs) until everybody (ie, me) goes home. Needless to say, it's annoying to see idle CPU time and the batch queues turned off. Comments? garry wiegand