Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site ittvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!pesnta!qumix!ittvax!long From: long@ittvax.UUCP (H. Morrow Long [Systems Center]) Newsgroups: net.unix-wizards Subject: Re: UNIX 4.2 thrashing - the cause? Message-ID: <1608@ittvax.UUCP> Date: Mon, 21-Jan-85 10:21:45 EST Article-I.D.: ittvax.1608 Posted: Mon Jan 21 10:21:45 1985 Date-Received: Wed, 23-Jan-85 04:59:42 EST References: <1282@kaist.UUCP> Organization: ITT-ATC, Stratford Ct. Lines: 80 > 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