very high CPU usage on Linux

[kris-watts-gravwell]

I confirm (by marking "x" in the [ ] below: [x]):

• [X] This is not a troubleshooting question. Troubleshooting questions go here: https://docs.mattermost.com/install/troubleshooting.html.
• [X] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• [X] I have read contributing guidelines.

---

Summary 100% CPU usage in Linux Desktop App

Environment

• Operating System: Debian Linux 11.0 AMD64
• Mattermost Desktop App version: Version 5.1.1 commit: 7eef060
• Mattermost Server version:

Mattermost Version: 7.0.0
Database Schema Version: 85
Database: postgres

Steps to reproduce

1. Run desktop app for a few minutes with desktop notifications on
2. Interact with desktop app while other activity is happening that would cause a notification, like private DMs

Expected behavior 1.

Observed behavior

1. A single thread on the machine is pinned to 100%
2. CPU stays pinned until notification is done
3. Interacting with the UI is EXTREMELY slow while notification is shown
4. CPU winds down over a second or two until the notification finishes

I upgraded my libnotify libs due to the original libnotify shipped by Debian causing segmentation faults. I grabbed the current libnotify debs from Ubuntu 22.04. Here are their verisons:

libnotify-bin/stable,now 0.7.9-3 amd64 [installed]
libnotify-dev/stable 0.7.9-3 amd64
libnotify-doc/stable 0.7.9-3 all
libnotify4/stable,now 0.7.9-3 amd64 [installed,automatic]

Possible fixes

Unknown

[devinbinnie]

@kris-watts-gravwell Sounds like it could be an issue with libnotify and Electron. Could you try downgrading both libnotify and the Desktop App and see if downgrading either fixes the issue? It would help to isolate which library is causing it. Thanks!

[kris-watts-gravwell]

I do not see the same issues with any of my other chat apps that use electron and link against the same libnotify versions.

The older versions of libnotify segfault so often in the mattermost-desktop client that I struggle to express this state.

Is it possible to control the electron version independently of the mattermost-desktop deployment version? I am seeing the same behavior in 5.1.1 and 5.1.0.

[devinbinnie]

I do not see the same issues with any of my other chat apps that use electron and link against the same libnotify versions.

The older versions of libnotify segfault so often in the mattermost-desktop client that I struggle to express this state.

Is it possible to control the electron version independently of the mattermost-desktop deployment version? I am seeing the same behavior in 5.1.1 and 5.1.0.

The reason I ask is because v5.1 is using Electron v18. If we downgrade to v5.0 that would be Electron v16. I'm curious which version of Electron causes this issue and if it can be fixed with an Electron upgrade/downgrade.

[kris-watts-gravwell]

updating to add some context.

Other members of my team that are using the Mac client do not see the excessive CPU usage, nor do people running on a browser.

After some more measured digging, I am seeing this any time I switch contexts.

For example:

1. Going from one direct message to another
2. Going from one team to another
3. Opening a playbook
4. Any action that causes a desktop notification to fire

The easiest way to cause this is just switching back and forth between teams.

When i switch contexts the process with args: mattermost-desktop --enable-crashpad goes to 100% CPU usage for about 3-5s. Memory usage on that process does not climb appreciably.

Once the mattermost-desktop --enable-crashpad process lets go of the CPU I see the process with args mattermost-desktop --type=renderer --enable-crashpad --enable-crashreporter ... exhibit what looks like a pretty standard GC sweep (significant CPU usage across all cores and a dramatic drop in resident memory), this lasts less than a second.

When the first process has the CPU and is pinning it, the mattermost UI becomes extremely sluggish or outright non-responsive. To the point that if I can type, there is a delay of a few seconds between when I press a key and when it is rendered.

I tried to open up the dev tools to try and get a profile, but the entire window becomes non-responsive when the behavior starts.

All of our Debian based users are seeing this on the desktop client. My two machines (i7-10th gen and ryzen 3700x) both exhibit similar behavior.

If there is anything else I can do to try and get more info let me know, happy to help.

[klojang4j]

Just to note that I have the same issue - my laptop seeming to prepare for takeoff while mattermost is running, either as standalone app, or in browser. It have a hunch that it's some rendering issue. If my office Dell laptop (I7 + 32GB RAM!!) is connected to my office Dell monitor (27") it seems to be much less of a problem, but if is connected to my Asus monitor at home (also 27"), it is steaming like hell when mattermost is running.

[devinbinnie]

@kris-watts-gravwell Is this still an issue for you on v5.2?

[devinbinnie]

Closing as inactive.