Created attachment 53178 [details] This seems to be the main config for all the plasma stuff Version: unspecified (using KDE 4.5.2) OS: Linux Since I upgraded from KDE 4.5.1 to 4.5.2, the plasma desktop takes 3-4 minutes to start up. Windows are displayed fine, I can watch the plasma-desktop process with top. It runs at 100%. Its memory usage grows up to 1.3G, then the desktop appears, and all is fine, except for the high memory usage. Which sometimes drops down below 1G. And sometimes, like at the moment, it is at 1.4G. Same happens after a plasma crash, or when I kill the process. Reproducible: Always Steps to Reproduce: This will probably be hard to reproduce for others. I will add my plasma-desktop-appletsrc, maybe someone will spot a problem in there. For me it happens whenever plasma-desktop is started, be it right after login or after a crash. Actual Results: plasma-desktop eats memory until it reaches 1.3G. Then the desktop appears, and CPU usage goes down. Expected Results: I do not remember exactly how the COPU usage was before 4.5.2, but it was a lot less (otherwise I would have noted this), and startup did not take that long. http://www.wonkology.org/comp/desktop/2010-06-19/ has screenshots of my 8 desktops, each is an activity. The current setup still looks similar. I am experiencing probelms with the comic plasmoid (it crashes rather often), but this is another problem, disabling it does not help wih the memory problem. I will try to remove the plasma-desktop-appletsrc file and recreate the desktos from scratch, hoping this will help. I have a backup of the current .kde directory, so if someone wants me to try something out, I can still do this.
4.5.3 was just released, could you try to upgrade to that? there were some fixes with the shared memory cache in kdelibs that might be related. if the problem persists, it would be quite valuable to know if the problem occurs with a "stock" configuration on your machine. if it doesn't, then tracking down what triggers it in your configuration (per-virtual-desktop views? a specific plasmoid? etc) would be very interesting information to have.
Okay, I'm running 4.5.3 now. Some X.org stuff was also upgraded (but not xorg-server itself), so I guess the crash right after the first login came due to this (I had not restarted X/kdm yet). Another observation is that a nasty problem with graphics distortion when scrolling in all applications (kmail, konqueror, chromium, ...) is now gone, which is great. I had this since I moved from the closed-source fglrx ATI drivers to radeon. There _is_ some change in plasma behaviour, it comsumes nearly no CPU time now - top shows it a 0% often. CPU usage was not really high before, around 5-10%. That's really cool, actually some KDE things DO improve. No change in memory consumption, though. Except that it's now at 1.4G after startup instead of 1.3G. Now I will try to remove plasmoids until hopefully the memory problem is gone. If not, I will try a fresh start, which should work. When I log in with a test user that has no ~/.kde4 yet, plasma does not use that much memory. So I assume it must be something with my configuration.
great news about the improvements! please do keep us posted with your search for what triggers the memory consumption. once identified, we can figure out what to do about it. thanks in advance ...
I will. I just removed the plasma-desktop-appletsrc file and logged into KDE. plasma-desktop uses 215M now. Is this okay, or still somewhat large? Before, I removed all plasmoids from the desktop (except for the logging one on my first desktop which I forgot), but kept those in the panel. Memory usage was somewhat reduced, but still took around 800M. BTW, I'm using Gentoo Linux with kernel 2.6.36 on an AMD Athlon(tm) Dual Core Processor 4850e with 6G RAM, in 64bit mode.
how are you measuring memory consumption?
I'm looking at top's RES column. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6266 root 20 0 1303m 471m 108m S 1 8.2 1:04.80 X 8236 wonko 20 0 1887m 257m 15m S 0 4.5 0:02.65 java 8048 wonko 20 0 953m 228m 95m S 0 4.0 0:02.02 plasma-desktop 8235 wonko 20 0 713m 140m 38m S 0 2.4 0:03.40 kontact
top is notoriously bad at these things. it's useful for relative, rough numbers but not very useful for determining "is that normal / reasonable?" the system monitor (Ctrl+Esc, or the "graph" icon in the run command interface (Atl+F2)) does a better job, though it isn't perfect either. can you pop that up, enter "plasma-desktop" in the search bar and post those numbers? (228MB is not a normal #, though it depends on your set up. here, plasma is taking a little over 20MB, and that's a full debug build with all possible dependencies satisfied at build time. still, it's hard to tell if you are experiencing a real, fixable problem there due to the relatively unhelpfulness of top.)
Thanks! The system monitor gives 136892K in the "memory" column, and 97900K in the Common memory" column. Or whatever the exact names are in English. And this is what ps thinks about it: wonko@weird ~ $ ps aux | head -n 1; ps aux | grep [p]lasma-desktop USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND wonko 8048 0.0 4.0 977968 234792 ? Sl 19:00 0:02 kdeinit4: plasma-desktop [kdeinit] Do you have each desktop as a single activity? I still do. I'll remove plasma* and activitymanagerrc (not only plasma-desktop-appletsrc), maybe this gives an even fresher start, with a single activity on all desktops. I'll rather not remove my whole .kde4, I'd hate to configure all of that again. But I'll try this once, let's see how much memory I need then.
Here am again. I removed plasma* and activitymanagerrc, now the system monitor shows 53M right after login, and 68M now (44M of common memory). Without a .kde4, I got a similar value 56M. top gives 109M. Okay, this still looks a little large, but hey, it's been 1.4G a while ago :) Now I will add activities/plasmoids and monitor memory usage.
Some figures. I'm using the system monitor now. When I enable 'different mini programs per desktop' in the virtual desktop settings, memory jumps from 61M to 112M. With another, unconfigured activity, I have 181M, and a little later (without major changes) it's 223M. Um, did the activity handling change from 4.5.2 to 4.5.3? I think the virtual desktop setting was 'different activities for each desktop', while now I can enable different mini programs per desktop. I'm not sure if I even need another activity now, while I had eight before. If something did change here, could this be responsible for my memory problems? Just for fun, I added another 7 activities of mixed type, memory is at 572M now. So these activities for sure use lots of memory. Now I will have to think a little about my desktop philosophy, and what different acitivities I need.
Okay, here's the final update I think. The current setup has only one activity (instead of eight), but different mini-programs for each of my now six desktops. The other setup is quite similar as before. Memory for plasma-desktop is at 240M / 102M, CPU usage is 1%. KDE feels real fast now, and I'm happy. Oh, and be careful when playing around with activities or plasmoids... I had about five X crashes, and 2-3 plasma crashes. No big probelm while configuring stuff, but I'll be careful to save my important stuff when adding plasmoids again. BTW, I have LOTS (100M) of these liens in kdm.log: __glXDRIbindTexImage: Failed to register texture offset override Just in case this might somehow be related.
So I re-arranged my desktops a little, backed up my .kde4 directory, made screenshots of the desktop (http://www.wonkology.org/comp/desktop/2010-11-11/), and suddenly the problem happened again. I backed out the plasma config and tried to reproduce the problem, and finally I did. So, the problem was the logging plasmoid (file monitor, 'Dateiüberwachung' in German). It's on desktop2.png, at the top. When I changed the file to log from /var/log/hdstate to /var/state/hdstate, plasma-desktop started eating RAM until it was at 1.5G. It turned out that I had an error in the script that creates /var/state/hdstate. I have this in my /etc/conf.d/local.start: ( while : do hdstate >> /var/state/hdstate sleep 10 done ) & At system start, a loop is sent to the background, updating this file every ten seconds, in order to show the state of my hard drives. Well, the '>>' was a silly mistake, this file had grown to 45 MB. I replaced it by a '>', and it's fine now, with plasma-desktop useing 250 MB. So, while this was sort of my own fault, the plasmoid still should not use 1 GB to read a file of 45 MB... and it probably should not read it as a whole, a tail -n 500 or so would be enough in any case. Happy fixing!
first, as to usage of memory by activities: activity handling has changed somewhat. now when you have "per virtual desktop" turned on, have M virtual desktops and N plasma activities, then N*M Plasma::Contaiments are created. that means with 6 desktops and 8 activities, you'd have 48 Containments on your system. it still looks like your system is using excessive amounts of memory, but it's growing and shrinking in ratio to the components (e.g. containments) that are being created, so i'm just going to chalk that up to differences in build environments and build-time options rather than it being an actual bug or something we can do something about here. one thing you can do that helps _alot_ with memory is to stop the activities you aren't actively using. all but the current activity has a "stop" button on the activity icon that you can press: that actually unloads the activity from memory. this allows one to have as many activities as you want defined without having them all in memory at once. as for the real problem here, thanks for doing the detective work to figure out the culprit: the watch file plasmoid! great work on tracking it down, now we know what needs to be done. i'm going to change the title of this bug and the component to reflect this and we'll eventually fix it. cheers and thanks for your cooperation in helping figure this one out.
Aaron, thanks for the tip. I had up to eight acitivities, but only for testing. And indeed memory rose up. Now that I can have different plasmoids on different desktops, the main need for other activities is gone, so I already use only one. Maybe I will add another one, to quickly change the pasmoids to different ones, not sure yet if I need this. BTW, are the plasmoids also called 'mini-programs', or is this only in my German locale? Another BTW: I now remember why I used >> instead of >. It's because > creates a new file, but the original file is still in place while it's opened by the file watch plasmoid, despite being already deleted. It's the inode that counts here. But I found a workaround, I simple delete the file once in a while and give the plasmoid some seconds to detect this - somehow this works, I guess it does perodical checks for the file's existance, using the file name here, not the inode. I found bug #203956 that deals with this, and suggested this to be changed, similar to tail which has the --follow=name option for this.
KDE SC 4.6.2 and the same. It's almost impossible to watch my /var/log/messages (40Mb) because plasma-desktop consumes 300Mb of RAM. Furthermore, it doesn't free (or heap become very fragmented) and it still wasting 250Mb of RAM.
*** Bug 262415 has been marked as a duplicate of this bug. ***
Bump... Just mentioning that this still happens in 4.8.3. You can verify this by watching a large file, I just tried with /var/log/emerge.log which is 20 M in size. Memory for the plasma-desktop process increases by 40 M then. Looking into the source code (kdeplasma-addons-4.8.3/applets/fileWatcher/fileWatcher.cpp), around line 178, it seems the whole file is being read into memory. I guess the duplication of memory happens four lines later when a QStringList is created from that. My workaround is to mirror large files locally using tail --follow=name (with a script in .kde/env/), and watch them instead.
I have to use the STDIN Plasmoid (http://kde-look.org/content/show.php/?content=92309) for now to watch /var/log/messages but I like the instant update of the File Watcher plasmoid much more than the 1 second refresh of "tail -n 10 /var/log/messages |cut -c 1-114". Fedora 17 KDE 4.8.4
I patched the fileWather to fix this, see reviewboard at: https://git.reviewboard.kde.org/r/105940/ Just waiting for review now.
This is fixed in version 4.9.1, by commit: e0dd48232daa0478a53c5be31aa0ba13768183cf I used the wrong email when submitting, so the automatic bug closer didn't work properly. Could please close the bug manually? Thanks.