Same problem with 2 screens and the Intel card with xf86-video-intel.

Plasma version: 5.8.2
qt5: 5.7.0
Intel driver: 2.99.917.722.g714052f (-02, march=ivybridge)

$ qtdiag

Qt 5.7.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 6.2.1 20160830) on "xcb" 
OS: Manjaro Linux [linux version 4.7.6-1-lqx]

Architecture: x86_64; features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2

Environment:
  QT_LINUX_ACCESSIBILITY_ALWAYS_ON="1"
  QT_QPA_PLATFORM="xcb"
  QT_AUTO_SCREEN_SCALE_FACTOR="0"

Features: QT_NO_EXCEPTIONS QT_NO_ZLIB

Library info:
  PrefixPath: /usr
  DocumentationPath: /usr/share/doc/qt
  HeadersPath: /usr/include/qt
  LibrariesPath: /usr/lib
  LibraryExecutablesPath: /usr/lib/qt/libexec
  BinariesPath: /usr/bin
  PluginsPath: /usr/lib/qt/plugins
  ImportsPath: /usr/lib/qt/imports
  Qml2ImportsPath: /usr/lib/qt/qml
  ArchDataPath: /usr/lib/qt
  DataPath: /usr/share/qt
  TranslationsPath: /usr/share/qt/translations
  ExamplesPath: /usr/share/doc/qt/examples
  TestsPath: /usr/tests
  SettingsPath: /etc/xdg

Standard paths [*...* denote writable entry]:
  DesktopLocation: "Desktop" */home/moon/Desktop*
  DocumentsLocation: "Documents" */home/moon/Documents*
  FontsLocation: "Fonts" */home/moon/.fonts*
  ApplicationsLocation: "Applications" */home/moon/.local/share/applications* /usr/share/applications /usr/local/share/applications
  MusicLocation: "Music" */home/moon/Music*
  MoviesLocation: "Movies" */home/moon/Videos*
  PicturesLocation: "Pictures" */home/moon/Pictures*
  TempLocation: "Temporary Directory" */tmp*
  HomeLocation: "Home" */home/moon*
  AppLocalDataLocation: "Application Data" */home/moon/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag /usr/local/share/QtProject/qtdiag
  CacheLocation: "Cache" */home/moon/.cache/QtProject/qtdiag*
  GenericDataLocation: "Shared Data" */home/moon/.local/share* /usr/share /usr/local/share
  RuntimeLocation: "Runtime" */run/user/1000*
  ConfigLocation: "Configuration" */home/moon/.config* /etc/xdg
  DownloadLocation: "Download" */home/moon/Downloads*
  GenericCacheLocation: "Shared Cache" */home/moon/.cache*
  GenericConfigLocation: "Shared Configuration" */home/moon/.config* /etc/xdg
  AppDataLocation: "Application Data" */home/moon/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag /usr/local/share/QtProject/qtdiag
  AppConfigLocation: "Application Configuration" */home/moon/.config/QtProject/qtdiag* /etc/xdg/QtProject/qtdiag

File selectors (increasing order of precedence):
  en_US unix linux manjaro

Network:
  Using "OpenSSL 1.0.2j  26 Sep 2016", version: 0x100020af

Platform capabilities: ThreadedPixmaps OpenGL WindowMasks MultipleWindows ForeignWindows NonFullScreenWindows NativeWidgets WindowManagement SyncState RasterGLSurface SwitchableWidgetComposition

Style hints:
  mouseDoubleClickInterval: 400
  mousePressAndHoldInterval: 800
  startDragDistance: 4
  startDragTime: 500
  startDragVelocity: 0
  keyboardInputInterval: 400
  keyboardAutoRepeatRate: 30
  cursorFlashTime: 1000
  showIsFullScreen: 0
  showIsMaximized: 0
  passwordMaskDelay: 0
  passwordMaskCharacter: U+25CF
  fontSmoothingGamma: 1
  useRtlExtensions: 0
  setFocusOnTouchRelease: 0
  tabFocusBehavior: Qt::TabFocusBehavior(TabFocusAllControls) 
  singleClickActivation: 1

Additional style hints (QPlatformIntegration):
  ReplayMousePressOutsidePopup: 0

Theme:
  Available    : kde,/usr/share/xsessions/plasma,generic
  Styles       : Breeze,breeze,oxygen,fusion,windows
  Icon theme   : breeze-dark, hicolor from /usr/share/icons,/usr/share/icons,/usr/local/share/icons

  System font  : "Noto Sans" 10
  Native file dialog

Fonts:
  General font : "Noto Sans" 10
  Fixed font   : "Noto Mono" 9
  Title font   : "Noto Sans" 10
  Smallest font: "Noto Sans" 8

Palette:
  WindowText: #ffeff0f1
  Button: #ff31363b
  Light: #ff454c54
  Midlight: #ff3c4248
  Dark: #ff1c1f22
  Mid: #ff2b2f34
  Text: #ffeff0f1
  BrightText: #ffffffff
  ButtonText: #ffeff0f1
  Base: #ff232629
  Window: #ff31363b
  Shadow: #ff141719
  Highlight: #ff3daee9
  HighlightedText: #ffeff0f1
  Link: #ff2980b9
  LinkVisited: #ff7f8c8d
  AlternateBase: #ff31363b
  NoRole: #ff000000
  ToolTipBase: #ff31363b
  ToolTipText: #ffeff0f1

Screens: 2, High DPI scaling: inactive
# 0 "HDMI1" Depth: 24 Primary: yes
  Geometry: 1920x1080+0+0 Available: 1920x1044+0+36
  Virtual geometry: 3840x1080+0+0 Available: 3840x1044+0+36
  2 virtual siblings
  Physical size: 480x270 mm  Refresh: 50 Hz Power state: 0
  Physical DPI: 101.6,101.6 Logical DPI: 96.2843,96.2526 Subpixel_None
  DevicePixelRatio: 1 Pixel density: 1
  Primary orientation: 2 Orientation: 2 Native orientation: 0 OrientationUpdateMask: 0

# 1 "VGA1" Depth: 24 Primary: no
  Geometry: 1920x1080+1920+0 Available: 1920x1044+1920+36
  Virtual geometry: 3840x1080+0+0 Available: 3840x1044+0+36
  2 virtual siblings
  Physical size: 480x270 mm  Refresh: 60 Hz Power state: 0
  Physical DPI: 101.6,101.6 Logical DPI: 96.2843,96.2526 Subpixel_None
  DevicePixelRatio: 1 Pixel density: 1
  Primary orientation: 2 Orientation: 2 Native orientation: 0 OrientationUpdateMask: 0

LibGL Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Ivybridge Mobile 
Version: 3.0 Mesa 13.0.0-rc2
Shading language: 1.30
Format: Version: 3.0 Profile: 0 Swap behavior: 0 Buffer size (RGB): 8,8,8

Same for me on Fedora 24

After multi hours usage on a laptop with external monitor attached, powered by Skylake CPU and GPU (i7-6700HQ), Plasma becomes slower and slower, even the mouse pointer slows down. I observed the plasmashell process using more and more CPU and RAM over time. Restarting plasmashell fixes the issue temporarily, it reappears after enough time.

I just found another user on IRC (Lipsum) having the exact same problem. He also has multi monitor and Skylake.

I tried both modesetting DDX and intel DDX, it happens with both. With modesetting it's worst though, probably because glamor is slower than SNA.

Version-Release number of selected component (if applicable):
root@enrico-dell ~ # rpm -qa | grep 'plasma-workspace-5\|mesa-dri\|modset\|xorg-x11-server-Xorg'
xorg-x11-server-Xorg-1.18.4-4.fc24.x86_64
plasma-workspace-5.7.5-2.fc24.x86_64
mesa-dri-drivers-12.0.3-2.fc24.x86_64

Steps to Reproduce:
1. Multi monitor setup is required
2. Start a plasma session and use it normally
3. Monitor plasmashell CPU and RAM usage over time
4. Notice the performance of plasma, especially on the external monitor, become sluggish

Actual results:
Plasma uses more and more RAM and CPU, performance is degraded and user experience is affected (sluggish interaction, slow response from the plasma shell)


Expected results:
CPU and RAM usage should be faily constant over time. Responsiveness of the shell should be constant in time and not sluggish.


Additional info:
I'm not sure if a better than full HD monitor is required. I have the following configration:

taglenri@enrico-dell ~ $ xrandr
Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767
eDP1 connected primary 1920x1080+2560+0 (normal left inverted right x axis y axis) 350mm x 190mm
   1920x1080     59.93*+
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
   2560x1440     59.95*+
   2048x1152     60.00  
   1920x1200     59.95  
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1200x960      59.99  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94                                                                                                                                                                                                                                              
   720x400       70.08                                                                                                                                                                                                                                                                
HDMI2 disconnected (normal left inverted right x axis y axis)                                                                                                                                                                                                                         
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


It is quite easy to notice the issue earlier if enabling the "Slide back" effect for Kwin compositing.

marking confirmed for multiple reporters

As suggested by Rex I tried the Plasma 5.8.3 packages from the Fedora KDE unstable copr repository (which is what will become the official Fedora packages) https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/

Problem still exists unfortunately. I have the impression using programs like virt-manager and krdc makes the problem easier to reproduce. I frequently have a CentOS 7 VM running and open in virt-manager and I use a desktop on it. I also use krdc quite frequently to connect to remote Windows systems right after closing KRDC I noticed plasmashell process eating between 50 and 100% of one core (it started before I closed KRDC I noticed the environment to become less and less responsive).

To be clear: I think krdc and virt-manager are making the issue appear faster, they are not the only trigger

If there's high CPU usage we need some sort of log of what it's doing when using high CPU otherwise we can't do anything.

Options are either:

perf record -g -p `pidof plasmashell`

or

callgrind 

You can use callgrind remote to profile only part of a process:
http://zariko.taba.free.fr/c++/callgrind_profile_only_a_part.html


Both will need relevant permissions and debug symbols.
Please reopen when you have something.

Created attachment 102089 [details]
perf record of plasma shell (still working good)

I thought about giving you a comparison, hoping it's useful, between a fresh boot of the system (when plasma is still working as expected and there is no issue exposed yet), and when the issue is very visible.

In this capture I have all my applications open (firefox, kmail, quassel, konsole, yakuake, virt-manager) and doing my normal work (answering emails and the like). This is a fresh boot and plasma performance is still good and there is no issue.

I've installed the debug symbols for plasma-workspace dependencies. However debug info RPMs for the copr repo with plasma 5.8.3 are not available to my best knowledge.

Color repos do provide -debuginfo pkgs, fyi

Make that *copr* repos (sorry for bad phone autocorrect)

Created attachment 102102 [details]
perf record of plasma shell (slow performance)

Sorry epic fail on my side. I had a typo in the command to install the debuginfo packages (I used dnf debuginfo-install --enable-repo instead of --enablerepo, dnf doesn't complain the option doesn't exist when using the debuginfo-install plugin... sorry!).

I've the debuginfo installed! Here is the perf data collected as root. I have all my applications open (as in previous comment + okular + KRDC). Here I'm constantly jumping between windows to trigger the high CPU utilization (to make number higher let's say). It's using 100% of one core. When I just don't move from a window the CPU utilization is near zero. Also changing window without involving any animation triggers the CPU utilization.

Note I had to compress it due to the size exceeding 4 MB limitation of this bugzilla.

Created attachment 102103 [details]
perf record of plasma shell (systray animation when in slow performance condition)

I've done an additional capture (which actually happened right before the previous one I posted). Here I'm just doing my usual work, I'm not heavily triggering the Windows change on purpose. However I have the telepathy little message systray icon animation happening. I actually left it there quite a while before doing this capture. I thought about adding it since it might be related... better safe than sorry.

Also I think this might actually have accelerated the performance degeneration as well. I've had KRDC and virt-manager open the whole day, but it was not as bad. Performance was going down, but not too fast. So the systray animation might actually be a heavy contributor.

So I think I've added enough information for the time being. Please put the bug in OPEN status again (I can't I'm not the original reporter).

Tomorrow I'll also take the perf statistic after a fresh boot, as the one I posted is with the debugging symbol not installed.

Thank you Rex for pointing out the copr provides debuginfos... I couldn't find them myself and got fooled by a stupid typo :)

Created attachment 102105 [details]
perf record of plasma shell (still working good)

Well, since 'kquitapp5 plasmashell ; plasmashell --shut-up' temporarily fixes the issue I just restarted plasmashell and recorded it again.

In this record I constantly switch window to have a similar situation when high CPU usage is triggered. In this case plasmashell doesn't even reach 50% (it's between 40 and 50%) of a single core and the system feels perfectly responsive and smooth. Still a pretty significant CPU usage just for switching window. This again without any effect triggering, the two windows are not overlapping, the only visible change is the status bar color change. Also, for what I understand, the animation is done by kwin process.

reopening since Enrico provided info

I'm currently running plasmashell under callgrind, so will have that trace too if I reproduce it today

Interesting new discovery. Yesterday and today the CPU usage of plasma was quite more tame than usual.

I have to digress a bit here, sorry: it's quite a long time I have two identical panels in my desktop, one per monitor. The reason is the infamous problematic multi screen support. If I was booting the laptop without an external monitor attached there was quite an high chance (around 50%) that my panel was not displayed. So I added a second one and this worked the problem around, I was getting one of the two. [end of digression].

With 5.8 multi screen situation improved, and I'm hopeful I can actually remove the second panel and live with only one. So I removed the second panel yesteday morning. Today I was a bit surprised because, while the plasma CPU usage increased over time it increased at a slower peace. So I added a second (default) panel. Plasmashell exhausted the system memory in a matter of second (for a total of 10 GB, the rest was already in use by other stuff)

[23477.201126] Out of memory: Kill process 2358 (plasmashell) score 535 or sacrifice child
[23477.201134] Killed process 2358 (plasmashell) total-vm:19426516kB, anon-rss:10795480kB, file-rss:0kB, shmem-rss:28452kB
[23477.682638] oom_reaper: reaped process 2358 (plasmashell), now anon-rss:0kB, file-rss:0kB, shmem-rss:28452kB

I started a new one, the second panel was there. I sent myself a message to trigger the telepathy icon in the systray (I had two of them now), issue appeared quite quickly. I removed the telepathy notification and also the second panel. CPU usage of plasma is still very high.

So I think this is quite an important condition to reproduce the issue: have more than one panel. I'm not sure if some of the widgets are more involved than others, but I guess the systray could be a good start. That however is not involved at all in the window switching, which would point to the task manager instead. In my testing I had two of both.

yes, I think the Kopete blinking icon does make the issue more pronounced, but I had it happen also when I forgot to log in to Kopete, so I obviously couldn't get any messages triggering the blinking...

Issue with how the panel is handled in general sounds likely though

Created attachment 102146 [details]
perf top annotate of handleSignal method

what's a bit weird, that even with fresh plasmashell process, `perf top` reports a lot of time being spent in QDBusConnectionPrivate::handleSignal from libQt5DBus.so

Here is another report that seems related to the virtualization mentioned in comment #4, this time with VMWare:

https://bugs.kde.org/show_bug.cgi?id=361497

Created attachment 102168 [details]
callgrind record of plasma shell (slow performance)

I've run a profiling run with callgrind. I started it with

valgrind --tool=callgrind --instr-atstart=no --callgrind-out-file=plasmashell-callgrind.out -- plasmashell --shut-up

so the instrumentation was not on during the whole startup. I waited a couple of hours with two panels and something animating in the systray. Once the CPU usage was maximized I started the instrumentation and also started switching active window as fast I could by using the mouse between two. Then I stopped instrumentation and stopped valgrind.

Oddly enough, while plasma uses a lot of CPU and is quite slower compared to a fresh start, the system performance was not dragged down as much. Usually the whole system feels slower when plasma starts using more resources, for example kwin animations are much slower. Firefox feels slower. Probably everything related to rendering feels slower. Likely valgrind just shuffling the conditions, but I thought I should mention it.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
kolorafa 27275 15.5 37.8 282921676 6176060 ?   Sl   sty03 1879:08  \_ /usr/bin/plasmashell --shut-up


I have the exact same thing (100% cpu when tray icon change/blinks).

If you have any blinking icon in systray over a time it uses more and more cpu and after few hours it is like 100% cpu for every icon switch.


And aditionally after 23 days of system uptime with blinking icons i opened huge page in crome, normally only chrome would freeze for some time because of cpu, but the whole plasma did freeze and started to behave crazy ... 
I opened the shell and saw 100% MEM (16G) and swap (4G)
I did kill chrome and now i see that plasmashell still uses 6GB of ram (RSS).

If that would help i could try some profiling because on my 8G laptop that i use the same way i need to reboot my box just to get plasmashell use less memory after 24h.

Tolong diperbaiki bug tolol selalu crash juga memakan memory dan cpu yang sangat tinggi ketika dioperasikan.thank

Please do not repoen bugs randomly.

*** This bug has been marked as a duplicate of bug 378010 ***