lkml.org 
[lkml]   [1996]   [May]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Bad 1.3.95 interactive performance (fwd)
DateWed, 1 May 1996 17:47:23 +0200 (MET DST)
FromMatthias Sattler <>
Hohi

> 
> 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. <--


\
 
 \ /
  Last update: 2005-03-22 12:37    [from the cache]
©2003-2008