Changing the nice() value of a running process.

[Paul De Bra]

In article <363 at lilink.UUCP> mikej at lilink.UUCP (Michael R. Johnston) writes:
}Today on a whim I did something on my system which quite interestingly
}enough improved performance measurably. Perhaps someone can explain in
}technical terms why this works. 
}...
}Before I made my change today, the system usually became just a tad sluggish
}after about 25 to 30 users were online. Not enough to complain about but just
}enough so the cursor would sometimes hesitate for a second or two. The system
}doesn't swap since we have 16 meg of ram and sar reports several hundred
}free block even on the heaviest of days.
}
}When I ran sar I usually came out with an "idle%" figure of less than 10 
}during mid-day loads. What I did was to change the invocation of the
}program from:
}
}program
}
}to:
}
}nice -10 program.
}
}By golly, suddenly the cursor stopped hesitating and when I re-ran sar I
}got figures that were in the 50 to 60 percent range. After some playing with
}the nice() value I  was able to get a final result in the range of 60 to 70
}percent most of the time. I was ecstatic! (as only a sysadmin can be...)
}
}I don't know the technical reasons behind this but I can surmise the following.
}By lowering the nice() value accross the board equally we devote less time
}to idle processes which are probably in the majority at any given moment. 
}Remember that this is an online database that is only queried on demand.
}Having done this, it then has more time to service the important requests 
}for work. Am I completely off base?

Yes.

If all processes run at the same lowered priority the scheduling should
remain the same. What you did however had 2 effects:
1) The database program runs at a lower priority than your user interface
   which means that the user interface will respond better. This explains
   why the cursor is no longer hesitating.
2) It looks like you are running the program from a shell script. The
   "nice" command is not build in (in the bourne shell), which means you
   are now invoking twice as many processes, which aren't doing much, but
   the nice process sits waiting for the database program to finish. The
   system may start thrashing more, resulting in more idle time because
   the system is waiting for page faults. On a heavily loaded system like
   yours the cpu-usage should be close to 100%, and the higher the better.
   Lower values mean you system is thrashing.

To find out whether your apparent improvement is real you should measure
the time needed to solve queries. Cursor response is deceiving.

Paul.
-- 
------------------------------------------------------
|debra at research.att.com   | uunet!research!debra     |
------------------------------------------------------