Subject: 1.3.3 and a siezed 'dump | restore'
To: None <port-sparc@netbsd.org>
From: Rob Windsor <windsor@warthog.com>
List: port-sparc
Date: 01/30/1999 10:49:23
This is really wierd.
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
windsor 881 0.0 0.0 84 8 p3 D+ 10:33AM 0:00.05 egrep
PID|dump|restore
root 854 0.0 0.0 600 76 ?? IW 10:16AM 0:03.55 dump 0f - /usr
root 855 0.0 0.0 4196 48 ?? I 10:16AM 2:39.19 (restore)
root 856 0.0 0.1 656 88 ?? I 10:16AM 0:12.62 dump 0f - /usr
root 857 0.0 0.0 600 32 ?? I 10:16AM 0:29.05 dump 0f - /usr
root 858 0.0 0.0 600 32 ?? I 10:16AM 0:28.65 dump 0f - /usr
root 859 0.0 0.0 600 32 ?? I 10:16AM 0:28.42 dump 0f - /usr
systat vmstat shows:
[...]
Discs sd0 sd1 fd0 daefr
seeks prcfr
xfers react
Kbyte scan
sec hdrev
intrn
Top shows:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
857 root 18 -5 600K 32K sleep 0:29 0.00% 0.00% dump
859 root 18 -5 600K 32K sleep 0:28 0.00% 0.00% dump
858 root 18 -5 600K 32K sleep 0:28 0.00% 0.00% dump
856 root 2 -5 656K 88K sleep 0:12 0.00% 0.00% dump
855 root 2 0 4196K 48K sleep 2:39 0.00% 0.00% restore
854 root 10 -5 600K 76K sleep 0:03 0.00% 0.00% <dump>
And it has officially gone 'nighty night' on me.
My ss2 rebooted on me this morning when running my weekly "dump from one
drive and restore to another", so I thought I'd test it again. I changed
the crontab to run it now so that I could tail the output and watch various
stats (what you see above).
While the dump was happening, I ran another app to chew up the memory
specifically to force the OS to hit swap. The other app was completed
a few minutes before this happened.
I'm going to let this simmer for a while, I have a few errands to run today.
Does anyone have an idea on what might be causing this? I might have to grab
the changes made to kern_exec.c and kern_fork.c to see if that fixes the
problem.
-- Rob
----------------------------------------
Internet: windsor@warthog.com
Life: Rob@Carrollton.Texas.USA.Earth
The weather is here, wish you were beautiful.