[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

memory leaks, and the proper way to interpret memory usage



Hi,

I am tired of memory leaks, and the first step in solving them is figuring out 
what is causing them.

today is a typical example.  My box has been up for 5 days, running a single 
gdm gnome/nautilus session the entire time.  mozilla has been running pretty 
much the entire time, with lots of windows being opened and closed.

Over the course of 5 days, I notice my swap file slowly grow, but the number 
of apps/windows open stays the same.

When the swapfile gets near full, I usually start closing applications until I 
have nothing open anymore, and then cycle my swapfile off and on to flush it 
out.

However, today, as is usually the case, swapoff -a fails because it cannot 
allocate enough memory.  Mind you, I have 512MB ram and a 256MB swap file.  
The only applicatios open are a gnome2 gdm session (with nautilus, no windows 
open), and a single window of slashdot in mozilla.  Certainly, nothing which 
should even fill my RAM, let alone my swapfile.  But top begs to differ:

 19:38:02 up 5 days, 21:02,  5 users,  load average: 0.09, 0.24, 0.24
103 processes: 100 sleeping, 2 running, 1 zombie, 0 stopped
CPU states:   0.3% user,   1.9% system,   0.0% nice,  97.8% idle
Mem:    515388K total,   509860K used,     5528K free,        8K buffers
Swap:   262136K total,    84496K used,   177640K free,   145820K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1525 jason     17   0  177M 176M 10148 S     0.0 35.0  69:04 mozilla-bin
 1529 jason     17   0  177M 176M 10148 S     0.0 35.0   0:00 mozilla-bin
 1530 jason     17   0  177M 176M 10148 S     0.0 35.0   0:10 mozilla-bin
 1531 jason     17   0  177M 176M 10148 S     0.0 35.0   0:00 mozilla-bin
 1532 jason     17   0  177M 176M 10148 S     0.0 35.0   0:23 mozilla-bin
 6014 jason     17   0  177M 176M 10148 S     0.0 35.0   0:00 mozilla-bin
 1345 root       7 -10  359M  91M  1744 S <   0.0 18.1 234:15 XFree86
 1421 jason     17   0 80368  37M  4784 S     0.0  7.5   0:49 nautilus
 1426 jason     17   0 80368  37M  4784 S     0.0  7.5   0:00 nautilus
 1427 jason     17   0 80368  37M  4784 S     0.0  7.5   0:00 nautilus
 1428 jason     17   0 80368  37M  4784 S     0.0  7.5   0:01 nautilus
 1429 jason     18   0 80368  37M  4784 S     0.0  7.5   0:00 nautilus
 1432 jason     18   0 80368  37M  4784 S     0.0  7.5   0:00 nautilus
 1433 jason     17   0 80368  37M  4784 S     0.0  7.5   0:01 nautilus
 1434 jason     17   0 80368  37M  4784 S     0.0  7.5   0:01 nautilus
31728 jason     17   0 22304  21M 15276 S     0.0  4.3   0:06 kmail
31738 jason     17   0 13744  13M 12424 S     0.0  2.6   0:00 kdeinit
31736 jason     17   0 11320  11M 10944 S     0.0  2.1   0:00 kdeinit
31733 jason     17   0 10904  10M 10596 S     0.0  2.1   0:00 kdeinit
31730 jason     17   0 10704  10M 10428 S     0.0  2.0   0:00 kdeinit
 1419 jason     17   0  8152 8096  2164 S     0.0  1.5   2:26 gnome-panel
31711 jason     17   0  3408 3408  2480 S     0.0  0.6   0:00 irssi
 1413 jason     17   0  3320 3316   824 S     0.0  0.6   2:38 sawfish
31704 jason     17   0  3208 3208  2132 S     0.0  0.6   0:00 xterm

WTF?!?

I would really appreciate it if someone could tell me what is going on here.

The noteable details about my system which have remained constant while this 
problem has been going on are:
I have always been running either the testing or unstable version of X, Gnome, 
and Mozilla,
I have always been running the proprietary Nvidia X driver.  I am currently 
using an older one, as the newest version manages to somehow get borked 
everytime i reboot, forcing me to "make install" it again.  nice.

Sorry for the ranty tone of this email, its just that having 512M of RAM and 
constantly running out of it is getting really old.  Despite my bitchy 
attitude, I really am in search of enlightenment regarding memory allocation, 
ie, exactly how does one interpret all the different memory statistics, how 
does one nail down the source of a memory leak, etc.

thanks,
jason pepas



Reply to: