It appears that plasmashell's notification history does not have an upper limit, which means that buggy applications may accidentally OOM the system through plasmashell by creating a lot of notifications. In my case, qBittorrent spams a notification for every IOError it encounters (happens quite often when you accidentally disconnect the external drive), which quickly leads to plasmashell's memory usage ballooning in size to several gigabytes. plasmashell could enforce a per-PID maximum number of notifications that it keeps in its history to prevent this from happening, discarding old notifications as new ones come in if the limit is reached.
In addition, please file a bug report on QBittorrent; spamming the shell with notifications on every error isn't good practice.
I don't think we need a fancy limit, we just need to change the code to not keep UI delegates around. This is something that's already on the TODO list as it's a big memory hog.
>In addition, please file a bug report on QBittorrent; spamming the shell with notifications on every error isn't good practice. I've already done this a while ago[1], turns out plasmashell isn't the only environment that has issues with notification spam (Windows doesn't seem to like it either). Thanks for the quick response. [1] https://github.com/qbittorrent/qBittorrent/issues/7586
I made a, rather ugly, patch: https://phabricator.kde.org/D9979 If you could give it a try?
Wrong link: https://phabricator.kde.org/D9978 that's the correct one
Git commit e8f76cc5386d7bc2878f4b72dc6e177164b3ad85 by Kai Uwe Broulik. Committed on 19/01/2018 at 09:55. Pushed by broulik into branch 'master'. [Notifications] Put history into a ListView Notification uses Repeaters for everything. While this is acceptable for jobs and notifications, of which there are few, the history can turn into a very long list of items. Using a ListView solves memory consumption by creating delegates only as needed. Since regular notifications and notification history are quite entangled with each other, I had to configure the ListView from within the Notifications loader. To keep code changes as little as possible, the rest of the UI is just moved into the ListView header item. While this is quite an invasive patch for a feature frozen version it's the least invasive approach I could find and is quite an important memory leak fix for an LTS. FIXED-IN: 5.12.0 CHANGELOG: Fixed memory leak when there are a lot of items in notification history Differential Revision: https://phabricator.kde.org/D9978 M +1 -1 applets/notifications/package/contents/ui/NotificationDelegate.qml M +24 -7 applets/notifications/package/contents/ui/Notifications.qml M +17 -40 applets/notifications/package/contents/ui/main.qml https://commits.kde.org/plasma-workspace/e8f76cc5386d7bc2878f4b72dc6e177164b3ad85
Git commit 59d66e30a6483096dd05525000f2e34713dfba5c by Kai Uwe Broulik. Committed on 19/01/2018 at 13:43. Pushed by broulik into branch 'Plasma/5.12'. [Notifications] Put history into a ListView Notification uses Repeaters for everything. While this is acceptable for jobs and notifications, of which there are few, the history can turn into a very long list of items. Using a ListView solves memory consumption by creating delegates only as needed. Since regular notifications and notification history are quite entangled with each other, I had to configure the ListView from within the Notifications loader. To keep code changes as little as possible, the rest of the UI is just moved into the ListView header item. While this is quite an invasive patch for a feature frozen version it's the least invasive approach I could find and is quite an important memory leak fix for an LTS. FIXED-IN: 5.12.0 CHANGELOG: Fixed memory leak when there are a lot of items in notification history Differential Revision: https://phabricator.kde.org/D9978 (cherry picked from commit e8f76cc5386d7bc2878f4b72dc6e177164b3ad85) M +1 -1 applets/notifications/package/contents/ui/NotificationDelegate.qml M +24 -7 applets/notifications/package/contents/ui/Notifications.qml M +17 -40 applets/notifications/package/contents/ui/main.qml https://commits.kde.org/plasma-workspace/59d66e30a6483096dd05525000f2e34713dfba5c
I've applied the patch to plasmashell 5.11.5, and tested it. The good news is that it drastically reduced the memory usage from the notification spam. Even after minutes of waiting, plasmashell only climbed up to about 400 MiB used memory. I could even open the notifications area this time, which previously would immediately OOM the system. The bad news is that when dismissing the notifications (which I previously couldn't do, because the system was very busy), the memory usage actually increases by about 300K per dismissed notification. It doesn't seem to decrease again after waiting a while either. (The lack of a "dismiss all" button for the notification applet also means that a user has to do a solid 10 minutes of clicking to get their notifications back in order) Seems good enough for now though, the memory leak is much much smaller now.
> The lack of a "dismiss all" button for the notification applet also means that a user has to do a solid 10 minutes of clicking to get their notifications back in order You can use the "Clear notifications" in notification applet context menu. I'll see if I can add a visible clear button next to the history header.
*** Bug 387128 has been marked as a duplicate of this bug. ***
A "Clear Notifications" buttons just went in today, FWIW: Bug 386068