jwf@cs.utexas.edu (Jim Franklin) (02/01/90)
In a recent comp.sys.sun posting, I described a problem with SUN OS 4.0.x related to degradation of paging performance: > Under SUN OS 4.0.3 (probably all 4.0.x), it is possible for a user > process with non-sequential memory access to permanently scramble the > swap block free list, so that paging performance drops by a factor of 3 > to 4. The decrease in paging performance is due to increased seek > times on the swap device, and can only be fixed by a reboot. In the same post, I said > Although I have not tested it, I suspect that any 4.0.x machine that > actively pages will show decreasing paging performance the longer it > stays up, for the same reason. I have just confirmed this decrease in paging performance on an SS1 workstation, which has shown a 30% decrease in paging performance over a 14 day period, during which it was just used for normal software development (editing, cc, make, sccs, etc.). reboot ... (swap block free list is completely sequential now) jwf@judd #35 repeat 5 bzero_time 50000000 50000000 bytes cleared in 80.763 sec (bzero 50MB a few times) 50000000 bytes cleared in 75.466 sec 50000000 bytes cleared in 74.850 sec 50000000 bytes cleared in 70.372 sec 50000000 bytes cleared in 72.998 sec two weeks pass ... (swap block free list is partially scrambled now) jwf@judd #88 rup ... judd up 14 days, 52 mins, load average: 0.04, 0.00, 0.00 ... jwf@judd #89 repeat 5 bzero_time 50000000 50000000 bytes cleared in 98.488 sec (bzero 50MB a few times) 50000000 bytes cleared in 97.508 sec 50000000 bytes cleared in 94.812 sec 50000000 bytes cleared in 93.248 sec 50000000 bytes cleared in 95.814 sec reboot ... (swap block free list is completely sequential again) jwf@judd #34 repeat 5 bzero_time 50000000 50000000 bytes cleared in 72.659 sec (bzero 50MB a few times) 50000000 bytes cleared in 76.701 sec 50000000 bytes cleared in 73.030 sec 50000000 bytes cleared in 72.817 sec 50000000 bytes cleared in 75.236 sec jwf@judd #35 bc (72.659 + 76.701 + 73.030 + 72.817 + 75.236) / 5 74.088 ( 98.488 + 97.508 + 94.812 + 93.248 + 95.814 ) / 5 95.974 95.974/74.088 1.295 (so paging performance is down by 30% in 14 days). This data was gathered on a SPARCstation 1 with 8 MB memory and two internal 3" SCSI disks. The first disk is used for root, /usr, and swap. The second disk is used entirely for swap, giving a total of 120 MB for swap. It appears that regular reboots will be required to keep the paging rate from degrading with time. Systems that page heavily or run user processes with non-sequential memory access patterns (see previous post) may need frequent reboots.