SUMMARY: strange thrashing of disks plus sun sticky bits

From: Brett Lymn (blymn@awadi.com.AU)
Date: Thu Aug 27 1992 - 09:17:07 CDT


Previously I wrote:

>
>I have two problems:
>
>1) I have a Sun ELC running SunOS 4.1.2 with local 1.3 Gbyte disk that
>is acting as a server for seven clients and a couple of labtam
>Xterminals. For most of the time this arrangement works ok but the
>users have complained that there are times when the system slows to a
>crawl for anywhere between 20 seconds to 10 minutes. When this slow
>down happens the disk i/o has gone sky-high but nothing else, no
>ethernet traffic, no swapping, no errors, no collisions (well a slight
>exaggeration but there is no corresponding increase in any of these
>numbers to point at a culprit). We are talking major thrashing here,
>up to 25 times the normal rate, what could cause such an increase in
>disk activity?
>
>2) The sticky bit! TFM claims that the sticky bit behaves differently
>under SunOS and goes into great detail about how this affects the
>behaviour of directories, I am not interested in this. I want to know
>what will happen when I apply the sticky bit to an executable. Under
>sysVile I remember that the sticky bit meant that the binary, if it
>was swapped, would be swapped out to contiguous swap space. Apart
>from a single throw away line in the chmod FM I cannot find out what
>effect (if any) the sticky bit would have. What we want is to apply
>the sticky bit to a program to improve response etc on a machine, is
>this correct?
>

Firstly, thanks to all that responded. The solutions to the problems
are:

for 1) the machine happened to be running the NeWSprint filters
(driving a Dataproducts lzr1260) and the culprit is the "postreverse"
part of the filter chain which goes and reverses the order of the
postscript pages to have them print out correctly on the printer.
This was accessing the disk to perform this function bringing the
system to a crawl. The solution would be to diddle the .param file
for the printer to tell NeWSprint to not reverse the order but my
users, being perverse beasties, have decided that they can live with
the slow down now that they know what causes it. A big thank-you goes
to Hal Stern for helping locate the problem.

The consensys on 2) is that the sticky bit does not do much in SunOS.
In old unix kernels the sticky bit was used to keep the executable in
swap after it had been exited thereby making startup for the next time
faster, the sticky bit was usually set on things like /bin/sh which
get used a fair bit. Since SunOS does not load the program text
section into swap, but pages it directly from disk there is no
advantage to setting the sticky bit.

Thanks to the following for responding:

From: Mike Raffety <miker@sbcoc.com>
From: kalli!pauline@fourx.Aus.Sun.COM (Pauline van Winsen)
From: trdlnk!mike@uunet.uu.net (Michael Sullivan)
From: Aydin Edguer <edguer@alpha.CES.CWRU.Edu>
From: poul@nilu.no

And Hal Stern. My apologies if I missed anyone.

--
Brett Lymn
Computer Systems Administrator
AWA Defence Industries



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:48 CDT