NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/aix/12482

Text File | 1992-12-11 | 3.6 KB | 71 lines

Newsgroups: comp.unix.aix
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!chukran.austin.ibm.com!rudy
From: [e-mail] ()
Subject: Re: AIX 3.2.3 on RS/6000-560 - strange scheduler behavior
Sender: [e-mail] (News id)
Message-ID: <[e-mail]>
Date: Fri, 11 Dec 1992 17:24:44 GMT
Reply-To: [e-mail](Rudy Chukran)
References:  <[e-mail]>
Organization: IBM Advanced Workstation Division
Lines: 58

In article <[e-mail]>, [e-mail] (Valdis Kletnieks) writes:
|> b) I have a "gut feeling" that part of the problem is that under heavy
|> load (load average over 20 or so), the scheduling algorithm breaks down
|> and chooses "inappropriate" processes to schedule next.  Does anybody know
|> of a way to make the system "prefer" interactive processes under high load?
|> I looked at the 'schedtune' stuff but that isn't what is needed - I think
|> a knob to turn to bias proc.p_pri more for interactive I/O - hitting return
|> should make it get scheduled sooner...
|>
|> Anybody have any other undocumented hints/tricks/traps for tuning for
|> a multi-user environment, besides what's in SC23-2365 (Performance Monitoring
|> and Tuning)?  A good technical overview of the scheduler algorithms would
|> also be helpful...
First of all, do you have the most latest of SC23-2365-01 which is
now entitled "AIX 3.2 for Risc System/6000 Performance and Monitoring
Tuning Guide"?  Starting on page 2-2 is a description of the Virtual
Memory management page replacement scheme and accompanying load control
scheme.

Second of all, you are choosing to operate in a very "nonlinear" region
of system load known as "over committed memory".  AIX 3.1 had no
memory overcommitment accomodation.  AIX 3.2 has such a scheme.
The scheme is based on 2 key points:
    a) detection of overcommitment
    b)  choosing which process(es) to suspend

I wont describe the algorithm here. The book goes into 4 pages of
detail.  The schedtune program controls only part a.  The
administrator has no control over b.  The process selection is based
on the premise that to get the "load in control" , the system must
get rid of the culprits causing the load. The virtual memory manager
chooses the processes that exceed the crucial threshold of
repage to page fault ratio. Those that do are suspended. There is
no awareness of "interactivity".  The priorities are not changed either.
Suspension takes the process off the run queue. The scheduler only
schedules processes on the run queue.
Thus, a suspension overrides the priority scheduling determination.

Your only option is to play with schedtune.  If you try to raise the
priority of "favored processes", what will likely happen is that they
will get suspended sooner.

Try turning off loadcontrol with "schedtune -h0" and see if there is
an improvement. If there isnt, put it back with "schedtune -D"
and vary -p which controls the repage ratio threshold.

If that doesnt work, then turn off loadcontrol again, and start messing
with priorities.  Try kicking up the priorites of the favored processes
with either nice or setpri. You will have to be root to increase
priorities in this manner.
--
*********************************************************************
Rudy Chukran                |       EMAIL:
IBM AIX Technical Consulting| RSCS: CHUKRAN at AUSTIN
11400 Burnet Rd.            | AWDnet:[e-mail]
Internal ZIP 2830           | internet: [e-mail]
Austin, Texas 78758         |
*********************************************************************