> If you want ... Ingo Molnar has written a memory leak detector.
> Do you want to do this sort of experiments on one of your systems?
Well, if it does'nt break something more. Remember that this is a
running production system. I have mucked around with these machines a bit
too much latley, but this problem drives me nuts, since I can not
reproduce it on my own test machine. And I don't have the recources to
exactly clone one of these machines so I can play around with it.
> The problem is: rss of a task is the sum and non-shared + shared pages of
> that task. And the value of shared pages shoed by free are counted more than
> once ... therefore the values of shared pages in the output of free are
> ... ahhh ... unusable.
It feels like I'm banging my head to the wall. *Arghh* *thud*
> Try out the new xosview (1.5) with its new memstat.o
> modul and you will get a new /proc entry:
Ok, I'll will see if I can get some time to test that.
> > Ok, I have tried that now but it did not solve the memory leak.
>
> crash or not crash is the question :-)
It would have crashed if I had'nt rebooted it, beleve me. I very much
disslike the idea of not nicely reboot a running production system.
But I let it go to that point that if I don't reboot it now I won't have
enough memory to press ctrl-alt delete.
> ... I know its nasty what I'm
> repeating ... but in the last few months there where a lot reports of
> memory leaks ... IMHO the most of them haven't exist. One of the
> real leaks was caused due an expire of an highly used news server ...
> this leak is closed. Today the busmaster dma for trition causes a lot
> of problems .. therefore it's save to let this optimisation off.
I can understand that you get alot of invalid leak reports, but I have
worked far too long using Linux to consider myself a newbie. I have even
successfully written my own device driver for a project here, not that
writing a device driver is difficult or so, but I know atleast some of
the kernel internals.
It annoys me extreamly much that there is no practical way of detemine the
amount of used kernel-memory. This is... Gnnnnh... F...... wrong!
This would have saved you and all the other kernel folks lots of
brainpain if people were able to report usable values. Then even newbies
could say: Gee! my kernel consumes 30Mb of my 32Mb of RAM, is that ok?
And suddenly that would be valuable information.
So here are the values I would like to see:
1. Total amount of RAM.
2. Total amount of "free" RAM, splitted up in three parts:
* Free RAM.
* Transfarable i-node cache.
* Transferable buffers.
Group these together to avoid silly newbie questions.
3. Total memory used by running jobs, splitted up in three parts:
* Total not shared part.
* Total shared part (maby also a sharefactor).
* Total library part (maby also a sharefactor).
The sum of these must be the physically used amount of RAM + SWAP
memory for all the running jobs together.
4. Total memory used by kernel, splitted up in two parts:
* Total kernel allocated data size.
* Total kernel code+constants size.
The sum of these would be the total non swapable amount of used RAM.
So, if I for example insert a module the code size should increase.
5. Total amount of swap.
6. Total amount of used swap.
And then ofcource for debugging an more extensive allocation map or so
would be nice to spotting the kernel memory leaks. I have discussed this a
bit with Roiger Wolff, but I feel that I'm not ready for this myself, and
unfortunatley I have to leave all this for a while becouse of heaps of
work is pressing me down. And I will have to reboot these production
machines once a day or so until someone is able to solve it. Not good! Not
good at all.
I don't require that you or anyone else must solve it, as the linux
community don't work that way. But I do really pleed for help.
Best Regards
Daniel Ryde, System Administrator
__________________________________________________________________________
Tripnet AB Visit Address: Telephone: +46 31 7252500
Box 5071 Avagen 42 Facsimile: +46 31 7252501
S-402 22 GOTEBORG GOTEBORG Email: ryde@tripnet.se
Sweden Sweden