Version: (using KDE 4.2.98) OS: Linux Installed from: Ubuntu Packages Since kde4.3 RC3 there is a severe performance loss in my environment. I'm running my laptop's kde via xdmcp on a desktop computer. This worked fine up to now. I updated to kde3 RC3 and now there is a visible response time if I do for instance the following: *) make some window the active window and press right mouse button on desktop --- the context popup comes 2-3 sec. later *) make some window active and type the kickoff shortcut key --- kickoff comes 2-3 sec later *) right-mouse in firefox ... context menu comes 2-3 sec. later The dektop popup delay seems to be correlated with the state-changes in the panel... once the panel reflects the change in window activity the popup appears. These are the most pronounced performance losses. However, the overall window switching speed seems to have decreased. I know I am running it over the network ... but it worked better before in the same environment.... very enoying!
> once the panel reflects the change in window activity the popup appears. the panel updates when the window management information changes. so both the panel and the popup activation could be (probably are) waiting on the same thing. to experiment: make sure firefox is running and visible; in the run command window do "kquitapp plasma-desktop"; once plasma has quit, try right clicking in firefox and see if the problem persists. also, what were you running prior to 4.3rc3?
Thanks for the comment, > to experiment: make sure firefox is running and visible; in the run command > window do "kquitapp plasma-desktop"; once plasma has quit, try right clicking > in firefox and see if the problem persists. OK, did that ... the behaviour of the popup in firefox did not improve. Anyway, the other delays are independent on whether firefox is running or not. But, I guess, plasma is out of the game now. There is another observation I made just now. The desktop machine which is basically serving as my X-terminal has an Xorg process which runs on more than 30% CPU, sometimes even up to 80%. Gets very active when switching windows. It also eats more than 80% of the memory. I don't know, if this is new, though. > also, what were you running prior to 4.3rc3? 4.1, 4.2 + updates, ... latest was 4.3rc2 ... I am not sure whether I had 4.3rc1. (All from kubuntu 9.04 using the kde4.3 backports) Both the laptop and the desktop computer run the same software.
> But, I guess, plasma is out of the game now. and Qt/KDE based applications, since if it's popups in firefox. most likely candidates are x.org and/or KWin. if you have desktop effects turned on, please turn them off and see if that helps any. before i re-assign this to KWin, however, can you start a different window manager after you are logged in (e.g. sth like: `blackbox --replace` or `metacity --replace` should do the tricks) and see if the problem persists? any other data you can provide on your set up would likely be helpful to the kwin people as well.
(In reply to comment #3) > and Qt/KDE based applications, since if it's popups in firefox. > I am not so sure because the popups on the desktop background and the startmenu/ kickoff have the delay too. I am pretty sure now that firefox is a seperate issue and we can focus on the kde-related delays only. I did the following: Firts of all, I never use compositing.... On the desktop computer which runs the remote X-session I removed kdm and installed gdm instead. So no kde-related software on the X-terminal (is that the correct term?). On the laptop, whose X-session I run remotely on the desktop computer I replaced the window-manager with metacity. However, this does not cure the long delays of the kde-related popups nor the firefox-popup delays. If I now remotely run gnome instead of kde all popups (which would be the equivalent of the kde-ones) come fast and the Xorg process on the desktop computer (X-terminal) has a reasonable CPU usage 1-4%. The only guy having still a problem in this setup is firefox, so I assume firefox is another story. I guess the main issue is the heavy CPU and memory usage in the case I run kde. Actually, the desktop computer seems to swap quite often. To sharpen the problem: I make a window active, I right-click on the plasma/dekstop ... after some delay in the order of several seconds the popup comes. If I now right-click again it pops up imediately. It looks like it only pops up, if the panel shows the window in-active. So my guess is that the de-activation and panel refresh is the reason for the delay.. the plasma-popup-delay is merly a symptom. My system is: the laptop from which the X-session comes is a thinkpad T61 64-bit with on board intel graphics (which is not used in my setup, I suppose). the desktop computer running the X-session remotely is some older 32-bit box with some radeon card
"I am not so sure because the popups on the desktop background and the startmenu/ kickoff have the delay too." of course; if all applications have the delay then it isn't the apps. plasma has precisely zero code in common with firefox above the x11 layer. " I replaced the window-manager with metacity. However, this does not cure the long delays of the kde-related popups nor the firefox-popup delays." ok, so it's not kwin either. at least we're eliminating suspects ;) "The only guy having still a problem in this setup is firefox, so I assume firefox is another story." well, no. it simply means that there's a difference between firefox and the gnome desktop shell somewhere, and whatever it is in firefox is triggering this issue in your setup (ditto for kde apps) "I guess the main issue is the heavy CPU and memory usage in the case I run kde." it could be. what is the memory / cpu usage when in a kde session? and in the case of a gnome session when firefox is having troubles? "So my guess is that the de-activation and panel refresh is the reason for the delay" the experiment with quitting plasma and duplicating the problem with firefox shows that this is not the case. given that firefox continues to exhibit issues when run in gnome would seem to indicate something is not right at a lower level, e.g. x.org or perhaps in the system resources available on the remote machine. those are the only commonalities left when it's kde+firefox vs gnome+firefox
(In reply to comment #5) OK, the Xorg process (measured with top) behaves roughly the following way when kde is running idle desktop: 18-25% CPU 40-80% MEM, increasing with time average busy situation: ~30-50% CPU peek: 80-90% CPU when gnome desktop is running idle: 0.1-4% CPU 2-3% MEM average busy situation: ~10% CPU peek: 50% CPU 3%MEM busy situation is for instance opening a new application or loading a web page. In summary it looks like the memory consumed under kde conditions is growing with time. Actually, after some time it uses around 90% of the 500Mbyte RAM on the desktop machine and starts allocating swap memory ... increasing with time to values around 500MByte or higher. And this does not happen in the gnome case ... or at least there it is so slow that I could not really detect it. I see that the problem might be in non-kde components. It just happend to deteriorate after the latest update. Maybe it solves itself after the next update. Anyway, thanks a lot for your efforts in solving my problem and for all your efforts in general.
"In summary it looks like the memory consumed under kde conditions is growing with time." ok, that would explain what you're seeing. the question is: what application is doing this? you said that even without plasma running you get this problem, correct? and with plasma + a different window manager? (e.g. if you log into kde and then do: metacity --replace) x.org using a lot of CPU usually means something is repainting and/or sending a lot of x events over and over again. so tracking down _which_ process is doing that will be critical to fixing this issue.
(In reply to comment #7) > ok, that would explain what you're seeing. the question is: what application is doing this? So ... I started two different kde X-sessions, one on the desktop and one on the laptop to take out the middle-man (network). While the 32bit desktop run fine in CPU and MEM usage, the laptop started gobbling up the memory, only now since that thing has more memory and no network was in between it did not feel so terrible. Then I removed the .kde directory and started over again with fresh default settings... just running directly on the laptop. The memory problem was gone. I then added step by step all the plasmoids I had before and the background image. This results in a moderate increase of Xorg MEM consumption, however no disastrous steady increase any more. Now, I went back to the network situation pulling laptops's X to the desktop computer and the overall speed feels like before the software update. I suppose it is some incompatibility with the settings I had accumulated since (I guess) 4.2 or 4.1. The Xorg process on the X-terminal machine has now normal CPU-usage below 1% when idle and goes up when busy ... I think in a normal amount. What remains, though, is the popup-delays of plasma-context and firefox-context menus. Kicker comes faster now. When the plasma-context is called the CPU-usage spikes up to 50% for a short time. (In case that helps) In summary, I can work again :-) but we didn't learn much. > x.org using a lot of CPU usually means something is repainting and/or sending a > lot of x events over and over again. so tracking down _which_ process is doing > that will be critical to fixing this issue. I do not really know how to monitor the X-events. Thank you again for your help.
"I suppose it is some incompatibility with the settings I had accumulated since (I guess) 4.2 or 4.1." did you keep the old .kde directory, so that you can perhaps find out what was in it that was causing the problem, exactly?
(In reply to comment #9) > did you keep the old .kde directory, so that you can perhaps find out what was > in it that was causing the problem, exactly? Off course .... I need some guidance to do so, though.
ok, so let's start with the assumption that it's either kwin or plasma that's causing problems. for kwin: copy share/config/kwin* from your backup of .kde into ~/.kde/share/config; then from a command line do: `qdbus org.kde.kwin /KWin reconfigure` see what happens. for plasma: from a command line: `kquitapp plasma-desktop`; copy share/config/plasma-desktop-* from your backup of .kde into ~/.kde/share/config; from a command line: `plasma-desktop` see what happens if it's neither of those, then perhaps the next candidate would be knotify, though i don't think knotify would cause x to increase in usage? hm. let's start with those two first.
(In reply to comment #11) Thanks for the tips, it helped figuring it out ... ... The winner is ... the bubblemon-plasmoid. I am now running on the "problematic" .kde but without the bubblmon and it seems to be fine. The other settings seem ok... I will have an eye on it, see if something else causes trouble. If I put back the bubblemon the MEM starts being gobbled up and CPU on the X-terminal-machine goes up. Running on the laptop directly also shows the effect, but less pronounced. I had bubblemon set to CPU-frequency and it was in the panel. It seems not to matter whether the animate checkbox is set or not. Such a little booger can cause such a mess ;-)
we have a winner! or.. a loser. whichever. ;) the bubblemon plasmoid can be pretty cpu intensive depending on a few factors (mostly around graphics performance) as it pushes pretty hard on those things. it shouldn't be gobbling memory, however, so i'll look into that. thanks for sticking with it through the process of working out what the problem was. i wish all bug reporters were as thorough, calm and committed. it makes dealing with reports a lot easier, even when it take days to get to the bottom of it. :)
I liked to confirm this bug. I'm running KDE 4.3RC3 via Kubuntu 9.04-64bit. With 4gigs of memory Xorg would fill up it up within a few hours. I tried upgrading to the latest Xorg and switched to foss ATI video drivers with no luck. After quiting plasma-desktop I was able to stop the Xorg's memory size from growing. So I did a search on bugs.kde.org and came across this bug report. After removing bubblemon plasmoid the memory leak stopped. If I re-add the plasmoid the memory leak comes back.
@James: with what settings, or just the defaults? i'm not able to reproduce this problem here ... :/ either something changes between rc3 and now in svn (possible) or it's something settings or system specific.
Created attachment 35802 [details] bubblemon setting screenshot
Aaron, I'm using the "Number of physical CPUs" option along with "Animated" checked and "Show Text" unchecked. Also I'm placing the widget in a panel along with these other widgets: system monitor cpu, system monitor network, and system load viewer. I created a screencast to show the steps I'm doing along with the Xorg memory usage. You can grab the file ogv here: http://www.fileqube.com/shared/eeqywb1508270
I committed a change to Bubblemon which uses a constant-size QVector instead of a dynamically-changing QList. This /should/ remove the memory problems, since no memory is being swapped around on every repaint. I'm not sure why the previous setup was causing such a problem. I've noticed the same thing on my desktop machine though, and I plan on testing this with it being on for a few days straight this week. If this doesn't fix it, some more in-depth debugging is needed :)
*** Bug 217104 has been marked as a duplicate of this bug. ***
After some research and profiling, it seems to have fixed things.