mikej@lilink.UUCP (Michael R. Johnston) (01/20/89)
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. One of the systems I administer at work is an Altos 386/2000 running SVR3 Unix. This system is a 64 port box. Typically, we have about 30 to 35 users on simultaneously running our database applications software. 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? Now that I have discovered this I have had another thought. Could I automatically alter the nice() value of one of these running processes based upon the time it has been sitting idle via a daemon? I.E. could I check the idle time for the tty every minute or so and adjust nice() for it lower and lower until it finally came back into use? This sounds like the perfect performance tuning tool. It could also have a preset threshold that would just kill the user altogther once idle time had been exceeded. Anyone? --- Michael R. Johnston System Administrator {..!philabs!mergvax! | ..!uunet!ispi!} lilink!mikej LILINK - Public Access Xenix (516) 872-2137 1200/2400 8N1 Login: new
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (01/22/89)
In article <363@lilink.UUCP> mikej@lilink.UUCP (Michael R.
Johnston) writes: about using nice to change process priorities
and make things work.
In a job a long time ago in a place far far away ....
I set the nice value of login to be 2: I.e. just before login
does the setuid stuff it does nice(2).
Hence the default level of all users was 2. Then the cc system
and nroff/troff had a nice of 3 set (actually one should nice to
max(3, current nice). And all editors had a nice of 1. Ps ran
with a nice of -10.
The result was that interactive users got good response and
nobody suffered. Even with the new UNIX schedulers this scheme
ought to be adopted by all.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
debra@alice.UUCP (Paul De Bra) (01/23/89)
In article <363@lilink.UUCP> mikej@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@research.att.com | uunet!research!debra | ------------------------------------------------------
dwc@homxc.ATT.COM (Malaclypse the Elder) (01/24/89)
In article <8818@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > > To find out whether your apparent improvement is real you should measure > the time needed to solve queries. Cursor response is deceiving. > it is arguable that cursor response is the most important measure since it is EXPECTED to be almost instantaneous while database queries are EXPECTED to take a while. but i agree that the original poster is probably penalizing the database backend process in favor of the interactive front end processes. the problem will come if/when the cpu requirements of the terminal processes ALONE start to saturate the cpu. the nice value will have a tendency to lock out the database process. THAT IS, THE EFFECT OF NICE IS STATE DEPENDENT. on lightly loaded systems, the recent cpu used will dominate in differentiating between processes. on heavily loaded systems, the nice value will tend to dominate (because of the fast rate at which the recent cpu measure is decayed). danny chen att!homxc!dwc
leo@philmds.UUCP (Leo de Wit) (01/26/89)
In article <8818@alice.UUCP> debra@alice.UUCP () writes: [] |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. If nice was implemented to wait for a child to terminate, this would be the case. But this wouldn't be a nice implementation of nice (8-), since all it has to do is lower the priority, then execve() its own (shifted) arguments. On Ultrix: $ nice -10 ps gx PID TT STAT TIME COMMAND 4766 ia TW 0:43 rn 5914 ia R N 0:01 ps gx 17932 ia S 0:18 esh $ No sign of a waiting nice process... Leo.