plasma and memory usage
Some of the leaks turned out to be related to certain graphics drivers, but that wasn't the majority.
Some were bona fide leaks in the Plasma code base, such as one I found and fixed the other day that, when the job tracking was turned on in the system tray, would result in a small allocation for each and every job (e.g. file transfer) started. This one wasn't easy to find because the allocations weren't huge and they were all parented QObjects meaning valgrind wasn't being very helpful. We've found and fixed a number of leaks of various sizes and things are feeling pretty good ... but there was still problems.
There was a bug report about memory usage jumping when the digital clock was set to update every second. This is a great example of a report that describes both the problem as well as a very well defined way to reproduce it. Now, I don't personally use a clock that updates every second, and Plasma tries its best not to update too much .. but when I ran `plasmoidviewer digital-clock` with it set to show seconds I watched the memory usage skyrocket with great sadness. :)
After hunting around in the clock code, in libplasma and in libplasmaclock for a number of hours I finally thought, "Maybe this isn't my bug after all." So I whipped up a small Qt only test app and was able to trigger the same problem in just a handful of lines of code. It turns out it's a problem with the caching in QGraphicsScene: it inserts pixmaps but never removes them from QPixmapCache. That shouldn't be a problem, however, since the cache should delete pixmaps when it gets too big and delete pixmaps when inserting using the same key. Unfortunately, for some reason, that isn't happening. By inserting a QPixmapCache::remove before both of the calls to QPixmapCache::insert in QGraphicsScene, the pixmap leaking stopped immediately.
I'm not sure that's the right fix, however, but at least I have an idea now of where we need to be looking. That it isn't in Plasma is nice (yay! not my fault!) but also a bit frustrating since it's slightly easier for me to fix things in Plasma. ;)
In any case, with all these patches applied on my system, a full on Plasma session is currently taking up 17,832k in resident memory and using 302 pixmaps that total 5904k in size on the X server. That's a total of 23736k of app and pixmap memory for my desktop, panel, widgets and wallpapers running using a full debug build.
Earlier tonight my Plasma had well in excess of 1000 pixmaps after running for not a very long time at all. Glancing at xrestop Plasma now has 292 pixmaps, or 10 less than when I wrote that last paragraph, so it certainly seems to not be leaking now. ;)
Yes, definitely headed in the right direction ...
282 pixmaps.... whee.
KDE 4 memory leak
For the last month or so my Kubuntu Linux box has been plagued by a particular problem: after running for a little while it would gradually become more and more unresponsive, to the point of unusability. I'm running Jaunty Jackalope on a pretty quick Intel chip, with 2 GB of memory. I've got a 256 MB NVidia video card to boot -- one previously purchased by youngest son (the gamer).
I'd walk away from my desktop and find when I came back it was stuck in molasses. Clicking on a button would do .... nothing. I'd have to hold the mouse button down and wait. And wait. And wait.
Usually I've found this sort of weirdness can be explained by overheating, but that didn't seem to be the case here. Couple that with the fact that I didn't see the problem when running another window manager and signs pointed to an issue with KDE 4.
After suffering through this for a while, I discussed the situation with clever youngest son (now a freshman computer science / information technologymajor at George Mason University) and he said it sounded like a memory leak.
Lo and behold, after some intensive research on line, I ran across several posts that discussed the fact that indeed, if certain desktop effects are enabled, there is a nasty memory leak in Kwin. The following posts reference it here and here. It's not just Linux that's affected: apparently FreeBSD has the same problem with KDE 4.
I'm a simple man: I'm looking for a simple fix.
Finally, I found this thread over at the Fedora forum.
To summarize, the problem is with compositing in Kwin. The easy way of dealing with it it to disable it. Rather than going in and screwing with all of my settings on the GUI, I jumped down to the command line and edited my config file for Kwin.
Drop to a shell and, from your home directory, go to the following directory:
.kde/share/config/
Make a backup (always make a backup!) of kwinrc
Find the section that says:
- [Compositing]
Enabled=true
- [Compositing]
Enabled=false
Save your changes. For this to take effect, you'll need to log out and restart your session so that Kwin has restarted. It is not necessary to reboot.
I did this and have had no more problems with my machine becoming unresponsive. Of course, I probably gave up some bit of window manager eye candy, but to be honest, eye candy is the functional equivalent of junk food. The alternative would be to switch to Gnome (gasp) or some other window manager, and I have to admit, even with all it's flaws, I'm a KDE man (although IceWM is not a bad light weight window manager).
Presumably this will be corrected at some point, although to read the forums, there is not universal agreement over exactly who is responsible for the problem. Thanks to StoneDragon at the Fedora Forums for this straight forward fix.
As always, your mileage may vary.
----
KDE 4 Memory Leak -- A Follow Up
Okay -- a follow up on my previous post about KDE 4's apparent memory leak. Despite following the steps I listed I found I was still prone to creeping molasses.
Here's what I ended up doing, which seems to have helped.
First, uninstalled all of the widget libraries I could locate (relax -- I reinstalled them). Then I went in and basically re-installed KDE 4, using Synaptic. I'll note for the record I don't have a lot of love for the newest release of Adept; it's a sorry downgrade of the version that came with KDE 3.
Next I installed OpenBox, which is an alternative window manager.
Once completed, I had the option, when logging in, of starting my session with KDE / OpenBox. This substitutes the OpenBox window manager forKwin, the default KDE window manager, while retaining the KDE look and feel.
Compared to Kwin, OpenBox is a light weight. I confess, I can see no discernible difference between the two once I've logged in -- other than the fact that OpenBox doesn't seem to eat up almost every remaining byte of memory over a 6 hour period (we are talking 98% of my 2 GB of physical RAM and 75% of my 2 GB swap file).
I've been using this configuration for about a week, checking memory usage with both System Monitor and top. So far, this seems to have corrected the problem.
Again, your mileage may vary.
No hay comentarios:
Publicar un comentario