Re: [opensuse] Kded4, Xorg, plasma-desktop Memory Leaks
On 04/17/2014 08:07 PM, Lars Kruczynski wrote:
Here is what is showing for plasma-desktop. I switched activities a few times and opened and closed a bunch of widgets, and now KSysGuard shows plasma-desktop taking 452,816 MB of memory and it's eating 25% of the CPU for no reason, and it's stuck there. I upgraded the Xorg packages, so we will see if that helps the memory usage.
pmap $(pidof plasma-desktop)|tail -n 3 Total: 7285496K 574224K 512179K 470216K 0K
3874008K writable-private, 3089568K readonly-private, 321920K shared, and 562712K referenced
And how much physical memory do you have and how much swap/page activity do you have? What widgets do you have? Try using vmstat to see how much memory is free and what your paging activity is when the system is, nominally, quiescent. -- What makes the universe so hard to comprehend is that there's nothing to compare it with. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have 8 GB. I only have the desktop folder widget and the standard ones on the bottom panel like software updater, networking, clipper, clock, etc. The way I got plasma-desktop to take almost 450 MB of memory was by opening and closing widgets. Here is what vmstat shows: vmstat procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 12928 601804 156324 5295712 0 0 927 968 18 13 38 1 58 3 0 On Thu, Apr 17, 2014 at 5:25 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/17/2014 08:07 PM, Lars Kruczynski wrote:
Here is what is showing for plasma-desktop. I switched activities a few times and opened and closed a bunch of widgets, and now KSysGuard shows plasma-desktop taking 452,816 MB of memory and it's eating 25% of the CPU for no reason, and it's stuck there. I upgraded the Xorg packages, so we will see if that helps the memory usage.
pmap $(pidof plasma-desktop)|tail -n 3 Total: 7285496K 574224K 512179K 470216K 0K
3874008K writable-private, 3089568K readonly-private, 321920K shared, and 562712K referenced
And how much physical memory do you have and how much swap/page activity do you have? What widgets do you have?
Try using vmstat to see how much memory is free and what your paging activity is when the system is, nominally, quiescent.
-- What makes the universe so hard to comprehend is that there's nothing to compare it with. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2014 08:50 PM, Lars Kruczynski wrote:
I have 8 GB. I only have the desktop folder widget and the standard ones on the bottom panel like software updater, networking, clipper, clock, etc. The way I got plasma-desktop to take almost 450 MB of memory was by opening and closing widgets. Here is what vmstat shows:
vmstat procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 12928 601804 156324 5295712 0 0 927 968 18 13 38 1 58 3 0
Please don't cc me if you are posting to the list. Try vmstat -a -S m 10 10 for something a bit more meaningful. Watch for changes. -- "Education must precede motivation." Jim Rohn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
So is it normal behavior for plasma-desktop to balloon in size to 500 MB after opening up and closing multiple widgets and closing them, switching activities, etc? Can someone else test this and see if they get the same result? On Thu, Apr 17, 2014 at 5:57 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/17/2014 08:50 PM, Lars Kruczynski wrote:
I have 8 GB. I only have the desktop folder widget and the standard ones on the bottom panel like software updater, networking, clipper, clock, etc. The way I got plasma-desktop to take almost 450 MB of memory was by opening and closing widgets. Here is what vmstat shows:
vmstat procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 12928 601804 156324 5295712 0 0 927 968 18 13 38 1 58 3 0
Please don't cc me if you are posting to the list.
Try
vmstat -a -S m 10 10
for something a bit more meaningful. Watch for changes.
-- "Education must precede motivation." Jim Rohn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 18/04/14 14:46, Lars Kruczynski escribió:
So is it normal behavior for plasma-desktop to balloon in size to 500 MB after opening up and closing multiple widgets and closing them, switching activities, etc?
Yes, closing widgets does not mean memory will be returned to the kernel. not even glibc operates that way. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/18/2014 02:07 PM, Cristian Rodríguez wrote:
El 18/04/14 14:46, Lars Kruczynski escribió:
So is it normal behavior for plasma-desktop to balloon in size to 500 MB after opening up and closing multiple widgets and closing them, switching activities, etc?
Yes, closing widgets does not mean memory will be returned to the kernel. not even glibc operates that way.
True, but then the code in glibc is highly shared. Look at it this way: the page holding code for a closed program stay in memory even after the program exits. They are added to the 'dirty page queue' but being code rather than data never get re-written to disk. If something else needs a page it gets pulled of that queue. In fact the pages in use are on a LRU queue and even active but dormant programs might have code pages reclaimed. That's why we talk of the "resident set" and of the "working set" of pages. Quite obviously any start-up code and initialization code that is used one and once only can be paged out. There have been papers written about how to get the complier-linker-loader to put one-only and least-used code in its own pages that have no overlap with the working set. It is the working set that really matters. That has to be present. I suspect that if your process has a memory leak and keeps growing, resident set will eventually stop growing -- because for every new page you use, the kernel will evict one page from your process. In the extreme case there is a top end on how much virtual memory a process can have. Repeated plugins and repeated un-freed malloc()s (aka memory leaks) might eventually reach that point. Run ulimit -a to find out. You should also look at the settings in /etc/security/limits.conf run man 5 limits.conf man 1 prlimit man 8 pam_limits -- The United States is a nation of laws: badly written and randomly enforced. Frank Zappa -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/04/14 19:46, Lars Kruczynski wrote:
So is it normal behavior for plasma-desktop to balloon in size to 500 MB after opening up and closing multiple widgets and closing them, switching activities, etc? Can someone else test this and see if they get the same result?
When you switch activities, are you actively 'stopping' the previous activity? I haven't played with them in the most recent couple of KDE releases so I don't know if anything has changed, but previously by default switching to another activity didn't stop the previous ones running in the background, you have to do that manually by calling up the Activity list either via the regular panel or a relevant plasmoid / shortcut, and pressing the 'Stop' button. I recall reading that stopped activities resulted in memory being freed up, so if you haven't done this perhaps they rest in memory ready for you to switch back at any moment. Ideally there should be an option to automatically stop all but the current Activity when switching, but I can see why this might not be desirable as default for people who switch constantly and don't want to experience lag each time as each process is reloaded into memory. Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
It doesn't matter if the activity is stopped or not, it doesn't free the ram. I can get plasma-desktop to take 500 MB of ram even without switching activities just by opening up a host of plasmoids and after days of the system being up. That combined with kwin, kded4, and Xorg really start eating into available memory, and since "free -m" shows all my ram just about taken upon boot, I am guessing the problem I am writing about has nothing to do with how the kernel does disk caching like I earlier wrote about but is related to pixmaps and leaks. Like I said, if it were by design, devs would have closed those bugs out and said something about how KDE functions that way, but they didn't. I can't be the only one here who's having this issue besides me and a friend who has the same problem... On Fri, Apr 18, 2014 at 2:38 PM, Peter <gumb@linuxmail.org> wrote:
On 18/04/14 19:46, Lars Kruczynski wrote:
So is it normal behavior for plasma-desktop to balloon in size to 500 MB after opening up and closing multiple widgets and closing them, switching activities, etc? Can someone else test this and see if they get the same result?
When you switch activities, are you actively 'stopping' the previous activity? I haven't played with them in the most recent couple of KDE releases so I don't know if anything has changed, but previously by default switching to another activity didn't stop the previous ones running in the background, you have to do that manually by calling up the Activity list either via the regular panel or a relevant plasmoid / shortcut, and pressing the 'Stop' button. I recall reading that stopped activities resulted in memory being freed up, so if you haven't done this perhaps they rest in memory ready for you to switch back at any moment.
Ideally there should be an option to automatically stop all but the current Activity when switching, but I can see why this might not be desirable as default for people who switch constantly and don't want to experience lag each time as each process is reloaded into memory.
Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/18/2014 08:24 PM, Lars Kruczynski wrote:
It doesn't matter if the activity is stopped or not, it doesn't free the ram. I can get plasma-desktop to take 500 MB of ram even without switching activities just by opening up a host of plasmoids and after days of the system being up. That combined with kwin, kded4, and Xorg really start eating into available memory, and since "free -m" shows all my ram just about taken upon boot, I am guessing the problem I am writing about has nothing to do with how the kernel does disk caching like I earlier wrote about but is related to pixmaps and leaks. Like I said, if it were by design, devs would have closed those bugs out and said something about how KDE functions that way, but they didn't. I can't be the only one here who's having this issue besides me and a friend who has the same problem...
You seem to have a problem with the difference between what (virtual) memory is allocated to a process and what it is actually using. As I mentioned in another post, code pages that aren't being used are LRU'd out. The way the memory-file allocation works if a code page is needed and isn't resident it gets paged in -- "on demand". That is what virtual memory is about. Pages that aren't being used can be re-used. As has already been said, Linux considers unused memory to be wasted. So of course 'free' _should_ show all your memory to be taken. If it didn't them something would be wrong! Perhaps the developers said nothing because they assumed you knew or could google for how virtual memory works. Its not as if it is new; it was developed at Manchester University back in the 1950s when memory, even 'core' memory, was fantastically expensive. -- Never tell people how to do things. Tell them what you want them to achieve, and they will surprise you with their ingenuity. --George Patton -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Anton Aylward
-
Cristian Rodríguez
-
Lars Kruczynski
-
Peter