gnome-shell CPU usage high

[halifax]

My gnome-shell process is taking up 25% CPU usage in Ubuntu GNOME 15.10, even while idling.

On my i5 CPU, that's basically 100% of a single core.

I can close everything down and just have a few terminals up, and gnome-shell continues to take 25% CPU usage.

Sucks for me, I like Gnome 3 as a DE, but I know for a fact there are several posters on this forum that downright hate Gnome 3 - so they might get a boost hearing how it's flaking out, more reasons to hate it.

About the only non-standard thing I did was use the video driver PPA to upgrade to the latest nVidia driver 364, vs. the official current 352 (as of the time of this post).

Anyone else have this problem?

To SteamOS's credit, it does not seem to have this gnome-shell runaway CPU usage issue.

[halifax]

I had some energy tonight to do some troubleshooting.

Step-by-step, after a clean boot, gnome-shell stays at almost no CPU usage until I launch a game from Steam and then exit that game. And only some games, not all of them cause this.

For example:
Saint Row IV does not cause this bug
Talos Principle does

But once I have the bug, then say, launching a game that does not start the bug, like Saint Row IV also doesn't fix the bug. Once gnome-shell is caused to go to permanent 25% CPU usage, it does not get fixed by closing all open apps or re-launching apps that don't cause it.

But I did find a fix action:

gnome-shell -r &

100% fixed if you run this. It kills the last gnome-shell that was hung at 25% CPU usage and starts a new gnome-shell that's fine. And it retains all your current open apps in your gnome session - so I guess that's all stored in the gnome-session process that's also in memory.

@ HwKiller:

The gnome-shell memory for me never seems to get too bad, starts <100MB and creeps from there, but not too high, 250MB is the highest I've seen yet, but if you ever try Gnome again, you might not have to reboot once a day, just try the 'gnome-shell -r' above, it appears to reset RAM usage too.

[Drako Frost]

Originally posted by halifax:

I had some energy tonight to do some troubleshooting.

Step-by-step, after a clean boot, gnome-shell stays at almost no CPU usage until I launch a game from Steam and then exit that game. And only some games, not all of them cause this.

For example:
Saint Row IV does not cause this bug
Talos Principle does

But once I have the bug, then say, launching a game that does not start the bug, like Saint Row IV also doesn't fix the bug. Once gnome-shell is caused to go to permanent 25% CPU usage, it does not get fixed by closing all open apps or re-launching apps that don't cause it.

But I did find a fix action:

gnome-shell -r &

100% fixed if you run this. It kills the last gnome-shell that was hung at 25% CPU usage and starts a new gnome-shell that's fine. And it retains all your current open apps in your gnome session - so I guess that's all stored in the gnome-session process that's also in memory.

@ HwKiller:

The gnome-shell memory for me never seems to get too bad, starts <100MB and creeps from there, but not too high, 250MB is the highest I've seen yet, but if you ever try Gnome again, you might not have to reboot once a day, just try the 'gnome-shell -r' above, it appears to reset RAM usage too.

The Talos Principle is one of the games (and I think is the only one) that supports Vulkan, and you are using the Nvidia 364.xx driver, which supports Vulkan, which leads me to think that your issue lies with Vulkan drivers/games. If that's the case, using the 352.xx drivers would avoid the issue.

[halifax]

Originally posted by Drako Frost:

The Talos Principle is one of the games (and I think is the only one) that supports Vulkan, and you are using the Nvidia 364.xx driver, which supports Vulkan, which leads me to think that your issue lies with Vulkan drivers/games. If that's the case, using the 352.xx drivers would avoid the issue.

Uhm... Yeah, hard to say... I dropped back to 355.11 and the bug was still there - but that driver still has Vulkan in it. But I also dropped out of the publicbeta of Talos Principle, so probably Vulkan has nothing to do with it.

On one hand, I find it kind of amazing gnome-shell -r works as well as it does. The first time I tried it after seeing that option in the man page - it was a total "Hail Marry" pass. I was fully expecting to go to black screen and need to manually init 6 from there...

On the other hand, it's still a kludge and a bug that's inconvenient.

Discussions of Arch vs more user friendly distros: my problem is I always tend to see everyone's point of view, heheh. Maleko says Drako's attitude towards Arch is very similar to a Windows user to Linux, that's true - I can see that.

But I can also definitely see Drako's point of view. Arch is looking hardcore after reading it's wiki page on install steps. Hardcore in relation to a more GUI/Wizard based install modern casual PC users are dumbed down to / used to.

Maybe Arch is easy and straightforward after you've "paid the entrance price" of getting up to speed on it's particular job flow for installing via the command line? Fair enough.

Once you get good at using the command line for a job flow that can also be done from various GUIs, it generally is faster and more efficient from the command line. But, there is also kinda the prereq that you more or less need to be a badass alpha geek to get really good at the command line in UNIX/Linux :-)

I am planning to try to install Arch w/ KDE maybe this weekend or next weekend, just to see if its particular command line cookbook makes sense to me. I like the idea behind Arch, a minimalist distro with just the components you want in it, faithful to upstream, etc. I am curious how high a price you pay in convenience for that desired minimalism.

[thetargos]

TLDR all the responses, but rather than GNOME, I'm pretty sure the OP is experiencing an issue with rygel, the DLNA server that GNOME uses for sharing files over the network in a DLNA fashion, it sucks!!! I' suggest you to check the culprit in top rather than in gnome-system-monitor, as the former will show you exactly the amount of CPU cycles used by rygel and the latter will show the reported usage... always bellow 50%, so 100% in top is one core is fully being used and 400% will mean all cores in a four core CPU (or threads) are in use.

My suggestion, kill rygel, and if inclined to, disable sharing and add a kill -9 rygel line in your .bashrc so when you login to GNOME you'll make sure it stays dead :D

This should really be fixed in the upstream rygel, is ridiculous it eats as much CPU idle... and seems to be indexing all the time (talk about ineficacy)

[Cybertao]

Originally posted by halifax:

Maybe Arch is easy and straightforward after you've "paid the entrance price" of getting up to speed on it's particular job flow for installing via the command line? Fair enough.

Once you get good at using the command line for a job flow that can also be done from various GUIs, it generally is faster and more efficient from the command line. But, there is also kinda the prereq that you more or less need to be a badass alpha geek to get really good at the command line in UNIX/Linux :-)

The impression some Arch users give me is they just copy and paste commands from the wiki, or type them if they can't work out a way to do that. You don't have to be a shell wizard or understand what a regular expression is to use it.

[SRH]

Originally posted by Cybertao:

Originally posted by halifax:

Maybe Arch is easy and straightforward after you've "paid the entrance price" of getting up to speed on it's particular job flow for installing via the command line? Fair enough.

Once you get good at using the command line for a job flow that can also be done from various GUIs, it generally is faster and more efficient from the command line. But, there is also kinda the prereq that you more or less need to be a badass alpha geek to get really good at the command line in UNIX/Linux :-)

The impression some Arch users give me is they just copy and paste commands from the wiki, or type them if they can't work out a way to do that. You don't have to be a shell wizard or understand what a regular expression is to use it.

The same can be said of Ubuntu, Fedora, and any Linux user. It really don't matter what distro it is, people will look for the easy way out most of the time.

[halifax]

Originally posted by thetargos:

TLDR all the responses, but rather than GNOME, I'm pretty sure the OP is experiencing an issue with rygel, the DLNA server that GNOME uses for sharing files over the network in a DLNA fashion, it sucks!!! I' suggest you to check the culprit in top rather than in gnome-system-monitor, as the former will show you exactly the amount of CPU cycles used by rygel and the latter will show the reported usage... always bellow 50%, so 100% in top is one core is fully being used and 400% will mean all cores in a four core CPU (or threads) are in use.

My suggestion, kill rygel, and if inclined to, disable sharing and add a kill -9 rygel line in your .bashrc so when you login to GNOME you'll make sure it stays dead :D

This should really be fixed in the upstream rygel, is ridiculous it eats as much CPU idle... and seems to be indexing all the time (talk about ineficacy)

I looked into rygel/DLNA, but I don't see it in memory as a process on my system when I'm having the bug happen, here is my top report when I the bug is happening:

PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                     
20   0 1604324 222692  85100 R  99.5  1.4  69:26.17 gnome-shell                 
20   0  175452  54296  32340 S   5.3  0.3  19:59.84 Xorg                        
20   0  455184  38248  25928 S   3.0  0.2   0:04.94 gnome-terminal-             
20   0  426892 172416 103576 S   2.7  1.1   2:21.10 steam                       
20   0  543412  62452  33564 S   1.7  0.4  17:53.65 gnome-system-mo             
20   0       0      0      0 S   0.3  0.0   0:41.10 rcu_sched                   
20   0       0      0      0 S   0.3  0.0   0:21.71 rcuos/0                     
20   0  185016   5672   3944 S   0.0  0.0   0:01.49 systemd                     
20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd                    

[halifax]

Originally posted by Maleko:

https://sourceforge.net/projects/architect-linux/

Thanks for the tip on Architect, I bookmarked that. It looks like the way I'll try an Arch first, and possibly only way, if it works well.

Originally posted by Cybertao:

The impression some Arch users give me is they just copy and paste commands from the wiki, or type them if they can't work out a way to do that. You don't have to be a shell wizard or understand what a regular expression is to use it.

Well maybe I have a shot at it, then :-) Although I am regexp proficient, after a Perl phase I went through professionally.

[Hwkiller]

Originally posted by Drako Frost:

Originally posted by Hwkiller:

It was never meant to be 'easy', it was meant to be 'simple', as in engineering.

The 'ease' of a distribution is highly dependent on its user.
Given that I need a lot of custom packages with my own build options, arch is actually far and away 'easier' than ubuntu and family. They wind up getting in my way, and packaging on my own is terrible in deb/rpm systems.

The install process, once you are acquainted with terminal, is much faster than other distros. I can install arch in about 10 minutes, if that, and most of that time is spent downloading the base packages.

If you want the distro to be cookie-cutter and handle things for you (and make some customizations harder), then use ubuntu and family.
If you want the distro to provide you tools with which you manage and build your own system, and the distro to get out of the way, then use arch or gentoo and family.
Not sure what you mean by 'constant user intervention'. Very occasionally you need to merge a .pacnew file (usually not needed). Sometimes big updates require a bit of configuration beforehand, but this is true *of all distributions* --- For non-rolling release, you are basically starting fresh with the new updates by installing a release. For rolling release, you need to prep your system for the update.
Tbh, I've had far more updating problems with ubuntu than arch, and at least with arch I know what went wrong (because I was the one to configure it).

Just different experiences is all.

It's like saying that it's easier to build a car than buying a manufactured one.

You can get a very customized distro using Debian or Ubuntu net-install images, and they are way more easier to setup than Arch.

10 minutes for a experience user, I can install Ubuntu in 3 minutes using a SSD, and I don't have to mess with config files.

I used Arch for 3 months, and it required A LOT of user intervention. You don't need to do such things on openSUSE Tumbleweed, and Tumbleweed it's also a rolling release distro.

I'm not saying that Arch is bad and nobody should use it, what I'm saying is that the statement: "Arch Linux is simple and easy to use", is incredibly misleading.

No, it's more like:
If you're going to build your own car anyway, it's better to order well-labeled parts with instructions on putting it together than it is to buy a premade one, disassemble it, and reassemble how you like it.

Really though, I haven't had to modify my configuration on any arch install in nearly a year, and I run on arch-testing.

And arch *is* 'simple', by design. It is SIMPLE, not necessarily easy. The mechanisms are simple, the packaging is simple, the commands are simple, the maintenance is simple. As in engineering --- It is not an over-engineered distro.
Arch may not be easier, depending on the user. I do think if you're wanting to build from the ground up and tweak to your heart's content, it is /much/ easier to start with arch than with ubuntu.

Anyway, all this to say --- Don't discourage people from using arch or other distros. I don't [usually] discourage anyone from trying any distro (except maybe new users to gentoo or slack). Each distro has its target audience. I love arch, I can stand fedora, but ubuntu/debian likes generally drive me nuts. But, I have my wife on mint, because she's their target user.

[halifax]

Originally posted by Maleko:

Originally posted by halifax:

The gnome-shell memory for me never seems to get too bad, starts <100MB and creeps from there, but not too high, 250MB is the highest I've seen yet, but if you ever try Gnome again, you might not have to reboot once a day, just try the 'gnome-shell -r' above, it appears to reset RAM usage too.

I think this is "normal" RAM usage for Gnome 3. Seems to start off very low, around 90MB, and increase the more you interact with the shell. After you've interacted with all the parts of the shell it caps out at about 250MB. I've never seen it much higher than that, but I do shut my computer off at night or if I'm away.

I use Alt + F2 and enter "r" instead of resetting the shell via the terminal. Works just as well.

Still no clue about what caused the high CPU usage though :\

Alt + F2, "r" is the same thing as "gnome-shell -r &" good to know! I knew of both, but had not made the connection between the two until this post. Alt+F2, "r" is a little quicker. I also use that in SteamOS, because occasionally the desktop background gets dorked after ALT-TAB'ing between game and desktop. This quick magic trick completely fixes it all, without losing my session, even the minimized full-screen game stays intact.