>
> Hi,
>
> On Mon, 29 Apr 1996 10:26:43 +0200 (MET DST), Matthias Sattler
> <m_sattle@informatik.uni-kl.de> said:
>
> >> As long as the working set does not change everything is normal, but even
> >> the smallest change results in heavy swapping (while the output of free
> >> looks normal).
>
> > In fact I don't see the problems with the original ncr driver, so it is
> > very likely that the bug is somewhere in the ncrBsd2Linux driver. Is
> > there something I can do to find out more about the nature of this problem ?
>
> This looks odd. I'd have said it was a sign of a memory leak in the
> driver if it wasn't for the fact that you are sure things are OK if
> the working set remains constant. Does this apply even if you keep
> working for many hours? Is it really the working set or simply the
> uptime which triggers the problem?
My time is very limited at the moment, so I can't work for many hours with
my computer at the moment, but I've got the impression that working with
it speeds up the performance degradation (it's still a slow continuous
process though). I'll do some kernel compiles with make -j3 (this should fit
into my virtual memory and make things noticeably slower because much swapping
will take place) tomorrow and compare the times to get some numbers about
the degradation.
And here comes some further information:
Just compare the output of free and ps in both cases (unpatched
procps-0.99a with kernel 1.3.97):
(The system status is compareable, on the (nearly) dead system just some
additional inactive xterms explain the extra swap usage.)
Here comes the free output when everything is ok:
total used free shared buffers cached
Mem: 14964 13800 1164 10400 324 5336
-/+ buffers: 8140 6824
Swap: 33724 6312 27412
and now when the system is nearly dead:
total used free shared buffers cached
Mem: 14964 14808 156 2244 208 1480
-/+ buffers: 13120 1844
Swap: 33724 13236 20488
The output of ps -aux looks much more interesting:
ps -aux when everything is ok:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 169 0.0 0.4 920 64 ? S 16:09 0:00 (rpc.portmap)
root 1 0.3 0.4 896 68 ? S 16:07 0:01 (init)
root 2 0.0 0.0 0 0 ? SW 16:07 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 16:07 0:00 (kswapd)
root 21 0.0 0.2 864 44 ? S 16:07 0:00 (kerneld)
root 138 0.0 0.6 920 96 ? S 16:09 0:00 syslogd
root 147 0.0 0.2 884 36 ? S 16:09 0:00 (klogd)
root 158 0.0 0.8 924 124 ? S 16:09 0:00 crond
root 178 0.0 0.3 916 48 ? S 16:09 0:00 (inetd)
root 189 0.0 0.8 956 132 ? S 16:09 0:00 rpc.mountd
root 198 0.0 0.8 984 132 ? S 16:09 0:00 rpc.nfsd
......
-----------
59860 16036
and now compare with this...
ps -aux when the system response is bad:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 169 0.0 0.0 920 4 ? S 20:32 0:00 (rpc.portmap)
root 1 0.0 0.0 896 0 ? SW 20:30 0:01 (init)
root 2 0.0 0.0 0 0 ? SW 20:30 0:01 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 20:30 0:03 (kswapd)
root 21 0.0 0.0 864 0 ? SW 20:30 0:00 (kerneld)
root 138 0.0 0.0 920 0 ? SW 20:32 0:00 (syslogd)
root 147 0.0 0.0 884 0 ? SW 20:32 0:00 (klogd)
root 158 0.0 0.0 924 0 ? SW 20:32 0:00 (crond)
root 178 0.0 0.0 916 0 ? SW 20:32 0:00 (inetd)
root 189 0.0 0.3 956 56 ? S 20:32 0:01 rpc.mountd
root 198 0.0 0.2 984 44 ? S 20:32 0:01 rpc.nfsd
......
----------
71280 3864!!!!
The resident set size looks much too low for me here. Hmmmm... what can be
the cause of this? A memory leak somewhere in the kernel?
Matthias
O .---------------. .___________. O
/\/ . `. m_sattle@ ,' / \ +FAX . \/\
__..--- ' /\/ | `._________,' | (___)/ * * \(___) \/ \ ` ---..__
""---__ \/`. | informatik. | / | \ +49 (0)6333 ,'\/ __---""
`.. / | .uni-kl.de | | `...' | -65079 \ ...'
`---------------' `._____.'
--> Don't take life too seriously -- you'll never get out of it alive. <--