Description of problem: gnome-software high memory consumption (constant) and CPU spikes (occasional) After a clean install of Fedora 28 on my Lenovo X1 Carbon (gen 5) I noticed the system would become unusable over time. To the point I would have to use the power button to recycle the system. I happen to run Conky with a LUA gauge for CPU and memory and noticed the Mem consumption for gnome-software seemingly just continues to climb. CPU appears to cycle up and down every second or so. Version-Release number of selected component (if applicable): gnome-software-3.28.2-1.fc28.x86_64 How reproducible: Seems to happen with every reboot. Steps to Reproduce: 1. reboot system 2. wait (and watch conky) 3. Actual results: # free -m total used free shared buff/cache available Mem: 15787 3674 10185 364 1927 11632 Swap: 4097 0 4097 # ps aux | awk '{print $2, $4, $11}' | sort -k2rn | head -n 10 3340 8.0 /usr/bin/gnome-software 7849 1.9 /opt/google/chrome/chrome 8609 1.9 /usr/lib64/firefox/firefox 8753 1.9 /usr/lib64/firefox/firefox 2536 1.8 /usr/libexec/packagekitd 2903 1.7 /usr/bin/gnome-shell 6364 1.2 /opt/google/chrome/chrome 8835 1.2 /usr/lib64/firefox/firefox 2246 0.7 /usr/bin/gnome-shell 1413 0.6 /usr/lib/systemd/systemd-journald # ps aux | awk '{ print $3, $11 }' | sort -k1rn | head -n 5 54.1 /usr/libexec/tracker-extract 18.6 /usr/bin/gnome-software 7.9 /usr/libexec/packagekitd 5.9 /opt/google/chrome/chrome 5.7 /usr/lib64/firefox/firefox # free -m total used free shared buff/cache available Mem: 15787 3562 10296 364 1928 11744 Swap: 4097 0 4097 # ps aux | awk '{print $2, $4, $11}' | sort -k2rn | head -n 10 7849 1.9 /opt/google/chrome/chrome 8609 1.9 /usr/lib64/firefox/firefox 8753 1.9 /usr/lib64/firefox/firefox 2536 1.8 /usr/libexec/packagekitd 2903 1.7 /usr/bin/gnome-shell 6364 1.2 /opt/google/chrome/chrome 8835 1.2 /usr/lib64/firefox/firefox 2246 0.7 /usr/bin/gnome-shell 1413 0.6 /usr/lib/systemd/systemd-journald 7891 0.6 /opt/google/chrome/chrome # ps aux | awk '{ print $3, $11 }' | sort -k1rn | head -n 5 50.0 /usr/libexec/tracker-extract 18.6 [gnome-software] 7.9 /usr/libexec/packagekitd 5.9 /opt/google/chrome/chrome 5.7 /usr/lib64/firefox/firefox # uptime 21:45:32 up 24 min, 1 user, load average: 0.87, 1.36, 1.15 # date Mon Jul 9 21:45:32 CDT 2018 # sar | tail -n 12 08:40:00 PM all 18.79 9.50 4.86 0.20 0.00 66.65 08:50:00 PM all 20.91 9.57 5.07 0.20 0.00 64.26 09:00:00 PM all 17.50 9.42 4.05 0.20 0.00 68.82 09:10:00 PM all 22.88 9.42 5.35 0.16 0.00 62.19 09:20:00 PM all 5.32 8.84 3.07 0.15 0.00 82.62 Average: all 17.33 9.40 4.76 0.20 0.00 68.30 09:22:31 PM LINUX RESTART (4 CPU) 09:30:00 PM CPU %user %nice %system %iowait %steal %idle 09:40:00 PM all 14.87 8.98 4.64 0.25 0.00 71.25 Average: all 14.87 8.98 4.64 0.25 0.00 71.25 # rpm -qa gnome-software gnome-software-3.28.2-1.fc28.x86_64 # journalctl | grep gnome-software | tail -n 4 Jul 09 21:45:20 slippy.evil.corp gnome-software[3340]: Failed to find one package for conky.desktop, /usr/share/applications/conky.desktop, [0] Jul 09 21:45:27 slippy.evil.corp gnome-software[3340]: Failed to find one package for bluejeans.desktop, /usr/share/applications/bluejeans.desktop, [0] Jul 09 21:45:27 slippy.evil.corp gnome-software[3340]: Failed to find one package for conky.desktop, /usr/share/applications/conky.desktop, [0] Jul 09 21:45:32 slippy.evil.corp sudo[10667]: jradtke : TTY=pts/0 ; PWD=/home/jradtke ; USER=root ; COMMAND=/usr/bin/pkill gnome-software Expected results: Additional info: Memory consumption occurs regardless if I started any other apps, or not. I am going to try removing bluejeans (and test) and then the conky.desktop entry.
I have the same issue and I am also running Lenovo (T430). I notice the memory drain when I return from standby or sleep modes. It makes returning from these states slower than forcing a power down and restarting. It doesn't seem like this program should ever need more than 150MB when running in the background. That being the case, maybe an easier fix would be to monitor memory allocation every 5 minutes or so and when it gets to 150, auto-end the program and re-start it.
This looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1583300
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I have been checking these issues In this comment: https://gitlab.gnome.org/GNOME/gnome-software/issues/194#note_472798 Kalev Lember @klember says: "Part of the problem is that right now gnome-software never unloads its UI when closing the window. We have a plan to start doing that in the future and that should help with the memory usage." Today I see on my system gnome-software uses 377 MB, probably due to this current bug. Potentially related too: https://bugzilla.redhat.com/show_bug.cgi?id=1668808 https://bugzilla.redhat.com/show_bug.cgi?id=1583300 https://gitlab.gnome.org/GNOME/gnome-software/issues/486 https://gitlab.gnome.org/GNOME/gnome-software/issues/453 https://gitlab.gnome.org/GNOME/gnome-software/issues/269 https://gitlab.gnome.org/GNOME/gnome-software/issues/191 Maybe not all of them are related, but at least looks like the bug is recognized by Kalev, as a background program is running but not closing an UI! This has a bad impact in the overall performance of low-memory systems, also makes not sense to have all the time around 300 or 400Mb (less or more depending what it is doing) on a process that is only used to install software or updates.
This is still valid in fedora 32, gnome-software uses around 500MB in background even when GUI is not in use. I think this is main reason why I can't recommend Fedora for every device, as Fedora is perfect for most of the use cases and is my main distro but for specific cases where I use to install linux on old wks, 500MB in use all the time is too much just to get updates in background once a day or a week.
Its becoming a problem in Fedora32 (I dont have a lot of ram), gnome-system-monitor shows "/usr/bin/gnome-software --gapplication-service" eating up to 1GB of memory even when closed, and it stays up. I'm investigating what "--gapplication-service" is, and maybe if disabling that is a good idea or not. What I tried: When ending or killing gnome-software, and then reopening, it consumes only around 50Mb which is normal (even when installing apps, or doing some updates, apparently just stays around that consumption), but nothing like the 900mb it uses even if its not opened, after system boot.- Pseudo work-around: Killing gnome-software after boot so it doesn't start to eat up memory after some time. *It might be healthy to make sure its not doing important things before closing it* What I will try: Disabling it as a "service" if that is possible so it opens only when I open it and not in the background, I do all the updates daily and manually so Im not concerned about auto-updates. *Sorry for bad English*
Looks like this was resolved now in latest releases.