more on slow paging
Jim Franklin
munsell!jwf at cs.utexas.edu
Fri Feb 2 00:05:06 AEST 1990
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 at 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 at judd #88 rup
...
judd up 14 days, 52 mins, load average: 0.04, 0.00, 0.00
...
jwf at 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 at 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 at 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.
More information about the Comp.sys.sun
mailing list