Messages in this thread |  | | Date | Thu, 15 May 2003 10:45:47 -0500 | From | Bob McElrath <> | Subject | Re: alpha kernel memory leak |
| |
mcompengr@earthlink.net [mcompengr@earthlink.net] wrote: > > (Please correct me where I'm wrong.) > > Generally, a memory leak is where an often called piece of code > dynamically allocates itself some memory for temporary usage, and > then fails to release that memory before being called again. > > This situation might be indicated by running out of swap space, at > which point the machine should grind to a halt (all processes), but > the memory usage reflected by the "top" or "free" commands won't show > it. Swap space should be twice the size of physical memory.
The machine does, in fact grind to a halt. When I first boot the memory usage is ~250MB and I have no problems using or starting any program.
After a few days the memory usage is ~500MB and I cannot start programs (they are killed immediatly with OOM). Note that in both cases the SAME programs are running. Just sitting here and watching 'top' shortly after bootup, the memory usage goes up by ~2k/s. This is with the network down, so the machine should be quiescent and hopefully no memory allocations taking place. I just checked again with all services stopped and the network down, at the console (no X), only init, tcsh and my little perl memory logging script running. It still leaks by 1.8k/s, according to my calculations.
If I turn swap back on, most operations cause a massive amount of swapping (switching desktops in X).
Are there any tools to examine how memory is being used, that report sensible numbers? As I mentioned 'ps' no longer reports any memory numbers (procps 3.1.8, debian unstable). And using top, the sum of VIRT is never equal to 'used'. If there is a memory leak, how do I determine that definitively?
Cheers, Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]
"You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists." -- Abbie Hoffman
[unhandled content-type:application/pgp-signature] |  |