Re: [kde-linux] Konqueror and Dolphin using 100% CPU
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Date: Thu, 23 Feb 2012 16:49:16 +0000 (UTC)
Dale posted on Wed, 22 Feb 2012 21:47:18 -0600 as excerpted:
I am mostly curious right now. I used to use Konqueror as my file
manager. I noticed when I left it idle for a bit, it would start using
100% of one of my cores. It has been doing this for a while so I can't
say which upgrade it started on. Anyway, when it started doing this, I
switched to Dolphin for my manager. I thought maybe it would be more up
to date or something. Anyway, it does the same thing.
When I use top, or htop, to show what is using so much CPU, it is
kdeinit4 at the beginning but either Konqueror or Dolphin as the actual
process running. I'm not sure what triggers this issue right now. I
usually use it to watch videos or something. It doesn't do it in a way
that is reproducible yet but I am trying to figure out what triggers it.
When I close the file manager, the CPUs go back to normal.
I'm using Platform Version 4.8.0 but it was doing it on the last version
Has anyone else seen this? If so, any fix yet?
I'm not sure if this is what you're seeing, but see if it fits...
If previews are enabled in konqueror/dolphin, and you're in a directory
with a large number of images or even more so videos, they will use a lot
of CPU trying to generate thumbnails for all those image-files. Videos
take more cpu and will I believe only be thumbnailed if you have the
appropriate thumbnailers installed (mplayerthumbs and/or another similar
app the name of which IDR ATM).
Once all the thumbnails are generated, there will be a burst of cpu on
directory entry as it checks the hashes and loads the corresponding
thumbnails, but it will die down MUCH sooner. But until they're all
generated, there will be a pause to let the pre-generated thumbs load,
then if there's no activity, the background thumbnailing process will
startup again. If it doesn't finish before you close the window or go to
a different dir, it will start up again the next time where it left off,
so in a few-hundred-video-dir, it might get maybe 3-5 videos each time
during normal usage if you're in the dir only a little bit, and thus take
maybe a hundred visits to the dir before all the videos are thumbnailed.
As such, the pattern is much different before all the videos are indexed
(initial burst, wait, pick up again) compared to after (longer initial
burst as there's more thumbs to load, without the pickup again).
A possible snag in this is if the various components (mplayer, the
thumbnailer, dolphin/konqueror, various kde and other libs) get out of
sync with each other. That could stop the activity until they're back in
sync, or make it much worse as the thumbnailers repeatedly try to load,
and crash, without actually generating any new thumbnails.
As both you and I are gentooers, a revdep-rebuild can help here, but I'm
not sure it catches /all/ such issues. (It catches most library out-of-
syncs, but I'm not sure it catches plugins, which often only load on
specific actions and won't normally cause problems if they're not there,
like fully depended libs will. And there's multiple ways to load a
library and I'm not sure revdep-rebuild catches all the obscure ones.) I
do know that revdep-rebuild sometimes reports all clean, here, but still,
something doesn't work for a time, but then when all the updates happen
to be built in the correct order again, suddenly things work again.
There's two cases I've seen where this seems to happen, the thumbnailers,
and the gnash/lightspark flash replacement plugins. I simply don't have
the technical understanding to really grasp /why/, tho I believe I sort
of understand a bit of it (the different ways to load libs, and the case
of libs vs plugins, both of which are "shared objects", aka *.so.*).
The kdeinit4 thing is a trick kde uses to launch faster and be a bit more
efficient with resource usage. Instead of each kde infrastructure app
loading all its resources separately, kdeinit4 is used to load common
resources once for several apps, thus shortening the initial launch and
reducing memory usage. The following is rather simplified, but AFAIK,
it's reasonably accurate as the high level explanation it's intended to
In Linux as originally designed, "shared object" libraries can load once
and be shared by as many apps as need them, but that was back when
libraries loaded at predictable locations. Now days, various archs
(including amd64/x86_64) mandate and some distros use even on x86,
"randomized memory space object relocation", for security and other
reasons. (Security-wise, if a function's location can be predicted, it's
far easier to exploit a potential vulnerability to allow an attacker to
take over the machine.) Also, even when shared object libs try to load
at specific locations, they can only do so if other libs aren't already
at that location, in which case they must be loaded elsewhere anyway.
Unfortunately, libraries loaded at different locations in different apps
take longer to initialize and don't as effectively share memory. Thus,
kdeinit4, which allows the various kde4 "core" apps to all load together,
more effectively sharing resources and loading faster. Address space is
still randomized at load time for these apps so security isn't thrown out
the window, but it's randomized once for all of them together instead of
once for each one.
If one of the apps crashes, it can be rerun by itself, but of course the
benefits of the common init are lost that way. Since it's just one app
being reloaded, init time isn't as big an issue, but other things being
equal, memory usage will be slightly higher. And AFAIK, kdeinit4 can't
be used to just rerun the single app anyway. If a full rerun is desired,
you quit kde back to the *DM login or text console (depending on how you
launched it in the first place, I always use a text console launch and
never a *DM graphical login, but others prefer their graphical login),
That should address the kdeinit4 <app> angle. =:^)
Finally, FWIW, for file browsing, in kde4, konqueror loads the dolphin
kpart. The wrapper around the kpart is different between dolphin and
konqueror, but it's the same dolphin file browser kpart underneath. So
it's not surprising that behavior and bugs seen in one are often seen in
the other, as well. It simply depends on whether that aspect is part of
the wrapper UI, or an underlying behavior of the kpart.
Also, I had to disable previews on my Desktop. When I would hover the
mouse over a icon, it would kill the kicker at the bottom and my
wallpaper. It would kill processes to the point that I could not logout
normally. I could not right click on the desktop and since the kicker
was gone, no K menu either. I'm not sure if these could be related and
most likely are not but it is a odd thing. On this matter, I have mine
set to show the icons on my desktop. I think it is called "folder
FWIW, "kicker" was the kde3 panel app (kdesktop was separate). In kde4,
the entire desktop and panels are "plasma" (plasma-desktop normally,
plasma-netbook's used in some cases). KDE /does/ try to respawn plasma
if it crashes, but it doesn't always catch it, and of course if the
problem is bad enough it could crash repeatedly.
However, while in kde4 the desktop and panels are combined, krunner is
deliberately kept as a separate process even tho it uses many of the same
libs, precisely to keep either krunner OR plasma-desktop usable if the
other one crashes.
Thus, even with plasma crashed, you /should/ be able to still use the
krunner hotkey (alt-F2 by default, IIRC) to invoke it, and can type in
whatever you'd launch that way, including rerunning plasma-desktop from
If you have a konsole window open, you can of course run either one
(plasma-desktop, krunner) from there as well. And of course you can run
konsole from either plasma or krunner.
Similarly, the hotkey mechanism appears to be separate. (I've not
actually figured out what app is responsible for it as I no longer see
the khotkeys app running that kde3 had, but I've had both krunner and
plasma crash on me at various times, and the hotkeys still appear to
respond with either one down, so it's gotta be separate from either.)
Thus, it's possible to configure hotkey launchers for plasma-desktop,
krunner, kwin, and konsole, so you can always get them back as long as
the hotkeys component is still running, with just a press of the
appropriate hotkey combination.
FWIW (tl;dr: description of my setup follows)...
Here, to replace the missing multikey hotkey functionality in kde4 that
used to work so well in kde3 (FWIW, the relevant kde bug says it's due to
a qt4 defect, apparently unfixable in qt4 as it's an architecture
assumption, but I've read that it's already fixed in qt5), I've setup a
couple scripts and a whole set of launcher-config files, that allow a
three-key launch of pretty much anything I use regularly, including
launchers for the apps listed above, should they crash. The first key is
a khotkey that invokes my launcher with a list of categories (config=c,
filesystem=f, games=g, net=n, raid=r, terms=t, X=x, etc) and associated
hotkey, the second choses a category and invokes the launcher again with
a list of the apps/hotkeys for that category (for net, b=bank (browser
loading the bank's login page), z=bugZilla-gentoo (browser URL), F=firefox
(general launch, blank page), m=mail (claws-mail, mail instance), f=feeds
(claws-mail, feeds instance), n=news (pan, nntp news client), etc).
So if I want to launch a konsole window, it's simply <launcher-key>,t,t
(first t, terminals category, second, general terminal window), to launch
konsole directly sudoing to my admin user, it's <launcher>,t,z, to
relaunch kwin with the --replace parameter if it crashes, it's
<launcher>,x,w (x=X-category, w=kWin), to launch kpat it's <launcher>,g,p
(games, kPat), getting a browser open to the bank login page is
<launcher>,n,b (net, bank), to open kde settings s <launcher>,c,s
(config, kdeSettings), to relaunch a crashed krunner it's <launcher>,c,r
(config, kRunner), to activate and mount my media raid it's <launcher>r,m
(raid, media)... etc.
Just three keys to launch anything on the system I use enough to have
bothered setting up an entry for it in the launcher config! =:^) And
it's all nicely categorized and mnemonically arranged so I normally
remember it without prompts, but the category and individual apps lists
for that category popup, just in case. =:^)
And as can be seen from the examples, that includes restart launchers for
kwin, krunner, plasma-desktop, etc, along with such things as config
resets for mouse accel (sometimes that resets and the mouse moves like
molasses until I reset the accel), triggers to immediately turn off the
monitors, or conversely, to keep them on so they don't blank on their own
after X minutes of inactivity, triggers to run a script to assemble
various auxiliary md/raids and mount the filesystems they contain,
triggers to load the browser with specific pages... all the random misc
one-shot and app launcher stuff I might want to do on the system.
Of course, if there's an app I'm not familiar with or simply don't use
enough to have created a 3-key launcher, I can use the usual launch
methods, kickoff menu, typing it in krunner, launching konsole and using
tab-complete to launch it from there, etc, that an ordinary user might
use, as well.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.
- Prev by Date: [kde-linux] Konqueror and Dolphin using 100% CPU
- Next by Date: Re: [kde-linux] 'Fetch Error' on exit
- Previous by thread: [kde-linux] Konqueror and Dolphin using 100% CPU
- Next by thread: Re: [kde-linux] Konqueror and Dolphin using 100% CPU