Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High Memory usage #1867

Open
miasinterestinglife opened this issue Sep 23, 2024 · 1 comment
Open

High Memory usage #1867

miasinterestinglife opened this issue Sep 23, 2024 · 1 comment
Labels
needs info An issue that needs more information

Comments

@miasinterestinglife
Copy link

Describe the bug

On Ubuntu 24.04 LTS Wayland I get memory usages in the Gigabytes (currently 1.4GB after just restarting) for no apparent reason. I saw this was previously an issue with this extension a few years ago but seemed to be fixed.

Steps to reproduce

  1. Install GSConnect
  2. Go to System Monitor (gnome-shell using 1.4GB)

Expected behavior

Not that much memory usage lmao

GSConnect version

57

Installed from

GNOME Extensions website

GNOME Shell version

No response

Linux distribution/release

Ubuntu 24.04 LTS

Paired device(s)

Motorola moto g(60)s

KDE Connect app version

No response

Plugin(s)

No response

Support log

No response

Screenshots

No response

Notes

No response

@github-actions github-actions bot added the triage An issue that needs confirmation and labeling label Sep 23, 2024
@ferdnyc
Copy link
Member

ferdnyc commented Sep 30, 2024

  • Install GSConnect
  • Go to System Monitor (gnome-shell using 1.4GB)

Hmm. This happens immediately after starting GSConnect?

That's not something we've seen. I'm on Fedora 40, not Ubuntu, but as you can see gnome-shell has been running on my system for a week, with GSConnect loaded, and while the process size is 1.2GB, its resident size (RSS) is only 400MB. The GSConnect daemon.js is only 120MB.

(Process size is effectively meaningless, as it includes all of the shared libraries and memory-mapped files loaded into the process. The RSS number is the amount of actual memory being consumed.)

$ ps -eF | grep -E '(gnome-shell|gjs|RSS)' 
UID          PID    PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
earlyoom    1322       1  0   674  1816   2 Sep19 ?        00:00:52 /usr/bin/earlyoom -r 0 -m 4 -M 409600 --prefer ^(Web Content|Isolated Web Co)$ --avoid ^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|sway|i3|xfce4-session|mate-session|marco|lxqt-session|openbox|cryptsetup)$
ferd     1026425    3986  5 1254360 402184 1 Sep23 ?       09:24:51 /usr/bin/gnome-shell
ferd     1026574    3986  0 235709 14256  1 Sep23 ?        00:00:02 /usr/libexec/gnome-shell-calendar-server
ferd     1026597    3986  0 723334 15180  3 Sep23 ?        00:00:00 /usr/bin/gjs -m /usr/share/gnome-shell/org.gnome.Shell.Notifications
ferd     1026823    3986  0 723357 16128  2 Sep23 ?        00:00:00 /usr/bin/gjs -m /usr/share/gnome-shell/org.gnome.ScreenSaver
ferd     1027634    3986  0 848034 117792 1 Sep23 ?        00:03:33 gjs -m /home/ferd/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/daemon.js
ferd     1295112 1294769  0 723139 17636  1 Sep26 pts/4    00:00:09 gjs -m /home/ferd/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/nativeMessagingHost.js chrome-extension://jfnifeihccihocjbfcfhicmmgpjicaec/
ferd     2615685 2614797  0 868156 106504 1 05:38 pts/22   00:00:06 gjs -m ./gsconnect-preferences
ferd     2630260 2614797  0 56982  2112   0 06:22 pts/22   00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox -E (gnome-shell|gjs|RSS)

system-monitor is even more forgiving, showing the memory consumption of gnome-shell at under 300MB:

image

...You might try running journalctl --user -b from a terminal, and scrolling down through the messages to see if there are any errors logged that might point to why the Shell's memory is growing so out of control.

Also, if you haven't tried logging out and logging in again, just to see whether it was a one-time thing, that's definitely worth doing. If the memory usage grows the same way in a new session, it'd be interesting to know how fast it grows — and to confirm that if GSConnect is disabled, the growth definitely stops (after another log-out/log-in cycle).

@ferdnyc ferdnyc added needs info An issue that needs more information and removed triage An issue that needs confirmation and labeling labels Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs info An issue that needs more information
Projects
None yet
Development

No branches or pull requests

2 participants