UNIX 4.2 thrashing - the cause?

[H. Morrow Long [Systems Center]]

> Somewhile ago, our VAX 780 showed a disastrous performance.
> It couldn't even echo the keystrokes from the terminal not to say of
> any works. 'uptime' reported 14 users, load average about 4.5.
> I only had to halt the cpu (^P) followed by a reboot.
> As far as I can guess, it surely is a thrashing, a rarely occurence.
> If you have any experience, please send me relevent information.
> Like the cause you found, the remedy, etc.
> Here is the disk usage for reference ( any hint? ).
> 
> Filesystem    kbytes    used   avail capacity  Mounted on
> /dev/hp0a       7421    6519     159    98%    /
> /dev/hp1h     137616  120835    3019    98%    /usr
> /dev/hp1g      74691   65354    1868    97%    /usr/spool
> /dev/hp2h     137616  120775    3079    98%    /va <- user area
> /dev/hp0g      38639   34747      28   100%    /vb <- user area
> /dev/hp2a       7429      30    6656     0%    /tmp
> /dev/hp2g      74691   62096    5126    92%    /UDS <- utilities
> -- 

We have also experienced the problem described above.  Here is what I found
out:

	From "A Fast File System for UNIX*", Revised July 27, 1983,
	by Marshall Kirk McKusick, William N. Joy, Samuel J, Leffler,
	Robert S. Fabry. CSRG UCB.  Unix Pgmrs Manual Vol 2c.


	"In order for the layout policies to be effective, the disk cannot be
	kept completely full.  Each file system maintains a parameter that
	gives the minimum acceptable percentage of file system blocks that can
	be free.  If the the number of free blocks drops below this level only
	the system administrator can continue to allocate blocks.  The value of
	this parameter can be changed at any time, even when the file system is
	mounted and active.  The transfer rates to be given in section 4 were
	measured on file systems kept less than 90% full.  If the reserve of
	free blocks is set to zero, the file system throughput rate tends to be
	cut in half, because of the inability of the file system to localize
	the blocks in a file.  If the performance is impaired because of
	overfilling, it may be restored by removing enough files to obtain 10%
	free space.  Access speed for files created during periods of little
	free space can be restored by recreating them once enough space is
	available............"


I believe there is a lesson here.  4.2bsd sites should try to keep all
filesystems below 90% full (especially those where a great amount of creation
and deletion take place daily - /usr, /usr/spool) or suffer degradation.

This is our configuration before and after heeding this advice:

Filesystem    kbytes    used   avail capacity  Mounted on
/dev/hp0a       7421    6449     229    97%    /
/dev/hp2a       7415     308    6365     5%    /tmp
/dev/hp2g     208595  124922   62813    67%    /u
/dev/hp2h     140564  108384   18124    86%    /ittvax
/dev/hp3g     208595  181990    5745    97%    /usr
/dev/hp3h     140564  115800   10707    92%    /psc
/dev/hp0e      26223   24036       0   102%    /usr/src


Filesystem    kbytes    used   avail capacity  Mounted on
/dev/hp0a       7421    5660    1018    85%    /
/dev/hp2a       7415     425    6248     6%    /tmp
/dev/hp2g     208595  124922   62813    67%    /u
/dev/hp2h     140564  108397   18111    86%    /ittvax
/dev/hp3g     208595  137287   50448    73%    /usr
/dev/hp3h     140564  115808   10700    92%    /psc
/dev/hp0d       7421    4605    2073    69%    /sys
/dev/hp0e      26223   24036       0   102%    /usr/src
/dev/hp0f     102899   42003   50606    45%    /usr/local


-- 

				H. Morrow Long
				ITT-ATC Systems Center, Shelton, CT
	
path = {allegra bunker ctcgrafx dcdvaxb dcdwest ucbvax!decvax duke eosp1
	ittral lbl-csam milford mit-eddie psuvax1 purdue qubix qumix 
	research sii supai tmmnet twg uf-cgrl wxlvax yale}!ittvax!long