Martin Steigerwald wrote: > schrieb Bob Proulx: > > Then press F6 to change the sort function. Use the up and down cursor > > keys to select VIRT for sorting by size of virtual memory usage. What > > programs are the top virtual memory consumers on your system? (On > > mine it is usually firefox.) Based upon what those memory hogs are on > > your system we can advise what action might be taken. > > No! > > Virtual memory size does not say a single thing about real physical memory > usage.
:-) Note that I was crafting my answer so as to be most useful to the original poster trying to understand the problem. It may not have been the right answer for 100% of all situations. But I think in this situation it was still very useful. And it did appear to have been a successful way to diagnose the 14G problem. :-) > An application can happily allocate 1 GiB or more of virtual memory > without every having the Linux kernel allocating physical memory at all > except for the management of the memory allocation at all. Yes. Depending upon the setting of vm.overcommit_memory. But with the default value of memory overcommit being enabled that is true. Of course the default value isn't enterprise quality reliable and so I always disable it. But I know that unless you have hit this problem before and have researched it and made the decision to change it that the default value of overcommit is what is in effect. > Virtual memory is just address space. Unless the application writes to it, > the kernel does nothing, repeat, nothing in physical memory. Yes. I completely agree with what you are saying. I understand it very well. :-) > So its resident set size. And even that is not accurate, cause it usually > collects libary memory usage as well. Right. Neither virtual memory size nor resident set size is the 100% correct way to tell what is happening. But I didn't think it was efficient to give a long lecture on memory hierarchy at that point in time in the email message. Instead I simply tried to give a way to diagnose the problem in a way that was useful to the original poster. This is just a general problem of phone/email support. If I am trapped on a research station in the antarctic and am required to perform an emergency appendectomy while in communication with a real surgeon then I am really hoping that the doctor who is guiding me through it will take into consideration the situation and will give me practical instructions for that moment and won't require teaching me a multiple year medical residency. The appendectomy patient may not survive that long otherwise. :-) So I understand that you are appalled by how inaccurate my advice was from a pedantically correct point of view. (How could I have possibly said such a thing!) Believe me that I was fully aware of it. Just the same I think it was the most efficient way to find the problem. Sometimes life isn't always about being 100% correct. Sometimes one must be practical about things. > So when you have 100 processes using libc6 the library is still in memory > just once. So an approach is account to the process the resident set size > of the library divided by the amount of processes that use it. > > In newer KDE versions the process monitor has a detailed memory statistics > page that does just that. I never have seen that in a shell command up to > know. It would be awesome if there were a script or other tool that could help automate this debugging for the user. Perhaps you might write one? Because I am pretty sure that if you were to try to describe the steps needed to 9 out of 10 typical random users they wouldn't be motivated to actually do it. Instead they would rather reboot. The KDE process monitor sounds interesting. But I dread the idea of installing all of the KDE environment to play with it. Perhaps if I remember the next time I already have a need for KDE otherwise I will give it a try. Bob
signature.asc
Description: Digital signature
