I'm installed Kde Neon right now but i noticed cpu usage still high, plasmashell deamon is taking it.
I'm came from KaOSx but I need an Ubuntu based system because I need specific software that isn't available on KaOSx.

Another issue is Application launcher at applications section, it reload each 3 seconds.

With KaOSx performance is great, cpu usage keep at 1~2%, 10~20% max. And ram KaOSx use 310 MB, Neon uses 400.

I'm using same configuration on Neon and KaOSx, both. I use start new session on login option.

What could it be?

I took some screenshots: http://imgur.com/sB0vy5Y

alekzxd wrote:I'm installed Kde Neon right now but i noticed cpu usage still high, plasmashell deamon is taking it.
I'm came from KaOSx but I need an Ubuntu based system because I need specific software that isn't available on KaOSx.

Another issue is Application launcher at applications section, it reload each 3 seconds.

With KaOSx performance is great, cpu usage keep at 1~2%, 10~20% max. And ram KaOSx use 310 MB, Neon uses 400.

I'm using same configuration on Neon and KaOSx, both. I use start new session on login option.

What could it be?

I took some screenshots: http://imgur.com/sB0vy5Y

install htop to view real procces usages.
whats your graphic card? run "lspci" in terminal or go to info center.

Isn't just KDE Neon, KaOSx too. Yesterday I updated my system and same happened.

This is a HTOP screenshot of KaOSx, look the same that Neon.

http://i.imgur.com/uHUzZRI.png

This is lcpci output:

http://i.imgur.com/MHnqPBq.png

(I can't embed images here, doesn't allow me).

I'm afraid I'm not sure what your problem is and have never used Neon but am interested which particular software makes you use an Ubuntu based (really Debian based) system.

I'm thinking it's not Neon, but Plasma, because I'm having same problem as Neon as KaOSx.

Talking about software (for me) is easier find documentation to solve problems on Ubuntu, because this is the most used distribution. For example, I'm working with MEAN, at my office was really easy install and configure mongo as a service, also nodejs. Then I had to work with Heroku and Postgresql, at Ubuntu I just copied some commands and it works, at KaOSx took me more time to configure postgres. So far I had been unable to start postgres service, It took me three times as long. Now, I need install Vagrant, at official page are just instruction and official installer as well for most common operative system, install it from source is really confusing for me. Most of time I solve my problems, but it take me longer time than normal. I'm just know the linux basics, I'm not an expert. Also I miss Viewnior, isn't available at KaOSx.

me too

Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from plasmashell...(no debugging symbols found)...done.
Attaching to program: /usr/bin/plasmashell, process 3692
[New LWP 3707]
[New LWP 3841]
[New LWP 3859]
[New LWP 3886]
[New LWP 3888]
[New LWP 3943]
[New LWP 4445]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
_int_malloc (av=av@entry=0xb4ec8780 <main_arena>, bytes=bytes@entry=0x8) at malloc.c:3419
3419 malloc.c: No such file or directory.
(gdb) bt
#0 _int_malloc (av=av@entry=0xb4ec8780 <main_arena>, bytes=bytes@entry=0x8) at malloc.c:3419
#1 0xb4d86e45 in __GI___libc_malloc (bytes=0x8) at malloc.c:2911
#2 0xb716d04e in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#3 0xb716a609 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#4 0xb716c1fb in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#5 0xb716c359 in xcb_wait_for_reply () from /usr/lib/i386-linux-gnu/libxcb.so.1
#6 0xb71bf092 in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6
#7 0xb71ba9af in XSync () from /usr/lib/i386-linux-gnu/libX11.so.6
#8 0xb4316170 in ?? () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#9 0xb42ec0b3 in glXSwapBuffers () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#10 0xb1b45fc0 in ?? () from /usr/lib/i386-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#11 0xb5610d09 in QOpenGLContext::swapBuffers(QSurface*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
#12 0xb6d8f535 in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#13 0xb6d90708 in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
#14 0xb5c3515a in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#15 0xb5c3a81c in QApplication::notify(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#16 0xb52a766f in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#17 0xb52fe68c in QTimerInfoList::activateTimers() () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#18 0xb52fec39 in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#19 0xb4491ed9 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#20 0xb4492179 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#21 0xb4492244 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#22 0xb52ff943 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#23 0xb1a7da81 in ?? () from /usr/lib/i386-linux-gnu/libQt5XcbQpa.so.5
#24 0xb52a47a3 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#25 0xb52a4bfa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#26 0xb52ad1d5 in QCoreApplication::exec() () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
#27 0xb55cc931 in QGuiApplication::exec() () from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
#28 0xb5c31024 in QApplication::exec() () from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
#29 0x08071eee in main ()
(gdb)

3692 kees 20 0 1503640 892880 54820 R 106.6 10.9 7421:10 plasmashell
21668 kees 20 0 517456 118364 5344 S 55.3 1.4 4665:53 mysqld
3829 kees 20 0 744232 19992 4616 S 38.7 0.2 1398:40 akonadiserver
5586 kees 20 0 2160288 151336 49044 S 27.5 1.8 2829:40 vmware-vmx
3210 root 20 0 257756 144188 98236 S 24.8 1.8 3074:59 Xorg
4908 kees 20 0 1112960 907328 23128 R 9.6 11.0 3:57.09 akonadi_notes_a
18024 kees 20 0 242088 25680 2128 S 9.6 0.3 1015:31 gauge.pl
4018 kees 20 0 129768 7484 5340 S 7.6 0.1 224:56.21 akonadi_akonote
3672 kees 20 0 296452 25436 15016 S 7.0 0.3 231:23.67 kwin_x11
4017 kees 20 0 129784 7496 5328 S 5.6 0.1 154:16.18 akonadi_akonote
1345 root 20 0 47652 1436 888 S 5.0 0.0 363:10.66 smbd
4016 kees 20 0 129516 6952 5168 S 5.0 0.1 220:37.75 akonadi_akonote
4013 kees 20 0 129724 7440 5340 S 4.0 0.1 184:06.40 akonadi_akonote

Switching Desktops and switching activities is _slow_

kees@SEPC002:~$ cat /proc/meminfo
MemTotal: 8212796 kB
MemFree: 510892 kB
Buffers: 86044 kB
Cached: 4489584 kB
SwapCached: 95424 kB
Active: 6133668 kB
Inactive: 1312224 kB
Active(anon): 5566920 kB
Inactive(anon): 809396 kB
Active(file): 566748 kB
Inactive(file): 502828 kB
Unevictable: 96 kB
Mlocked: 96 kB
HighTotal: 7391116 kB
HighFree: 192604 kB
LowTotal: 821680 kB
LowFree: 318288 kB
SwapTotal: 4200992 kB
SwapFree: 3068048 kB
Dirty: 6332 kB
Writeback: 0 kB
AnonPages: 2807728 kB
Mapped: 373156 kB
Shmem: 3506044 kB
Slab: 167840 kB
SReclaimable: 119260 kB
SUnreclaim: 48580 kB
KernelStack: 6944 kB
PageTables: 30624 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8307388 kB
Committed_AS: 12250384 kB
VmallocTotal: 122880 kB
VmallocUsed: 21280 kB
VmallocChunk: 96492 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 24568 kB
DirectMap2M: 886784 kB

I am able and willing to provide more detailed (debugging) info is requested.
I keep my Desktop running for many days, (it is a server also) and use screenlock
between my sessions.

After logging out and back in the performance is initially quite nice but after some hours/days
it start to hog the system. All 8 CPU's are very busy with doing not much

regards

Kees

Same problem here. After the latest update it just takes a ridiculous amount of time in rendering a window, opening firefox or a simple KTerminal. The system even blocks sometimes when typing. It is strange because was running fast and smoothly before the update. I have also compiz and all effects disabled so it must be related to some of the latests plasma updates.

Again, what software is only available on Ubuntu which makes you use it?

But to get to the point, have you ever run top? Is it really plasmashell?

After running top several times, checking the logs and looking at past forums, I realized the problem has to do with baloo_file_extractor

This is an old KDE bug which has been around for years!! It doesn't seem to have got a lot of attention from developers. The same error seems to happen for many distros running KDE: Arch, KDE Mint, Ubuntu, Fedora, KDE neon... for me it has started happening right after the latest updates on KDE neon.

These are some links to other posts about the same issue:

https://www.google.co.uk/url?sa=t&rct=j ... 41d8FmI9Qw

https://www.google.co.uk/url?sa=t&rct=j ... cbnEJ0bx1g

https://ubuntuforums.org/showthread.php?t=2217434

It results that baloo_file_extractor is frenetically duping logs because of some internal errors of the desktop environment and this collapses the CPU. Some other users suggested that one solution is to find the file where the logs are dumped, for instance ~/.xsession-errors file, and re-direct it to /dev/null. I have tried this same solution but it didn't work for me. It could be also related to some of the newer feature of Xapian that corrupts some database and that is causing the errors to be triggered. I have not explored this later possibility but it could be a hint towards the real issue behind this.

Some other users suggested to restart the balooctl daemon with:
$ balooctl disable
$ balooctl enable
and restart the database but this hasn't worked for me.

Finally, as no other possible option, I decided to disable the dammed baloo_file_extractor by doing:
$ kate ~/.config/baloofilerc

and disable the indexing by setting it to false:
[Basic Settings]
Indexing-Enabled=false

Now I am not experiencing CPU issues anymore and everything is running smoothly again. This solution is simply a workaround. I am not sure about the role that baloo_file_extractor has on the desktop environment but for the time being this is the only fix until a proper solution to this bug is finally found.

All the best!
Luke

Sorry but this Baloofilerc trick isn't working for me.

I had the same issue with User on 5.9 but now I'm on UserLTS Plasma 5.8.5 and after recent updates this is happening now on LTS, even after trying to stop indexing with your suggestion. This is in a fresh install on the weekend, and clean install of all apps (I have a list of apps I install and all data is on my second drive so a clean install takes about 30mins and I'm back where I was on previous setup).

I've tested removing widgets one at a time, no change. In fact slowly closed everything till I was back at the desktop and still it's hogging resources. A reboot with no widgets or apps running other than services needed at boot, and within 30mins Plasmashell slowly starts hogging again.

Current usage is:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1342 neon 20 0 3733556 325344 114676 S 41.0 1.0 37:16.89 plasmashell
^^^^ - wow 41% and 1.0% memory (320mb) after being up for 2 hours 56 minutes.

I have dual monitors and my second display has always had several informational widgets and apps running, but only recently has Plasmashell starting hogging CPU and memory resources after an update. Until about a while ago when we were updated to plasma 5.9 it seemed to be ok here. No issues and no changes to configuration here.

Four minutes later:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1342 neon 20 0 3733540 325340 114724 S 41.3 1.0 40:56.19 plasmashell
^^^^ up to 41.3% now.

Once it gets above a certain point Plasma starts to get sluggish and I have to reboot as it starts to drive me nuts...about 15+ hours or so. I'd do a fresh install and test, but this is my daily computer and can't be without my programs that long...

Hi all

I've the same issue here, sometimes plasmashell process go with high CPU usage. No need to reboot only logout/login for return to normal state.

I find that some GTK apps increase this behaviour for exemple VMware Worstation.

Don't know why

Regards

Found on Google that this bug was supposed to be fixed in Plasma 5.8.6 yet it's back in 5.9. It must be a recent update that broke it again...

Well 5.8.6 is not yet out, it's due next week-ish, see https://community.kde.org/Schedules/Plasma_5 maybe the fix will show up in both 5.8.6 LTS and 5.9.3 when they get released?

vishalrao wrote:Well 5.8.6 is not yet out, it's due next week-ish, see https://community.kde.org/Schedules/Plasma_5 maybe the fix will show up in both 5.8.6 LTS and 5.9.3 when they get released?

Thanks for pointing out Schedules for Neon...didn't know they had one. From what I can tell this bug has been around a LONG time in relation to KDE and still not fixed. I can not continue to use KDE based OS if they can't fix this. I've been using widgets for technical info for a long time and only had this issue creep up recently - after an update from what I can figure out. Why would the bug rear its ugly head now after I was happy with Neon's great "vanilla" OS? UGH...hopefully it can be resolved...this must be annoying to all widget uses...or maybe it's a combination thing that hasn't been resolved and only affects some users.

Found a possible solution:

workaround here: https://bugs.kde.org/show_bug.cgi?id=311799.
Open file /usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationIcon.qml
Search for line "running: visible" in "PlasmaComponents.BusyIndicator" section and change it in "running: false".

Several people claim it works to stop Plasmashell from gobbling resources....I just set it to false and rebooted. Will know in 10-15 minutes if it's working or not....stand by....

Ok it's been 34 minutes and usage seems to be staying 1-2% although copying a large file still causes 1 core of the CPU to max out at 100%. Never used to do that either. Will check tomorrow morning to see if Plasmashell is still gobbling or not.