1510762 - Firefox increases cpu usage over time

Status: RESOLVED INVALID

(Core :: Widget: Gtk, defect)

Description

[Hans-Peter Jansen]

Attachment: Screenshot_20181128_firefox63_started.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

I colour myself a heavy Firefox user. 

My setup consists from about 15 windows, populated with a few up to many tabs each. After switching from 52esr to 63.0.3 on openSUSE, I noticed a steady increase of cpu usage over time. After startup and Firefox settled, is runs with a few percent per process (up to 4%, 8 processes), that increases to around 30% after 3,5 hours (used from 4 processes, the other 4 processes are quiet), and approaches 90% after 8,5 hours (again those 4 processes, with childID 1, 4, 5, 6). The last 5 hours, the system wasn't used. 


Actual results:

This behaviour results in a Firefox, that is literally unusable after a day, because those 4 processes saturate the CPU completely (approaching 100%). It can be controlled with a LOT of patience, but typing in the search field of the home widget takes several seconds, before a character appears, and all kinds of misbehaviour due to lagging that much.


Expected results:

I expect Firefox to be usable even after days of operation such as older versions do, which is practically impossible with the current version.

I'm missing a way to examine, which sites (tabs) are CPU contender. 

System: openSUSE, Kernel 4.19.4, Firefox 63.0.3.

Comment 1

[Hans-Peter Jansen]

Attachment: Screenshot_20181128_firefox64_after_3,5h.png

Comment 2

[Hans-Peter Jansen]

Attachment: Screenshot_20181128_firefox64_after_8,5h.png

Comment 3

[Andre Klapper]

Please enter the address
   about:memory?verbose
in the address bar and attach (using the "Attach File" link above) the output here.

Comment 4

[Andre Klapper]

Argh, sorry. CPU, not Memory. Ignore, please.

Comment 5

[Hans-Peter Jansen]

Since this problem forces me to restart Firefox every few hours, which is further complicated by the resurrection of 

https://bugzilla.mozilla.org/show_bug.cgi?id=372650#c45

I downgraded to 52.9.0, that keeps its two processes (firefox and flash container) in reasonable bounds (10%-15%, 1%) during the whole day!

Comment 6

[Daniel_A[:daschilean] [Please contact - [e-mail]]]

Can you please test this in safe mode? Here is a link that can help you: https://goo.gl/AR5o9d.
I think it will be a good idea to retest this on the latest Firefox Nightly. Here is a link form where you can download it: https://nightly.mozilla.org. 
If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Comment 7

[Daniel_A[:daschilean] [Please contact - [e-mail]]]

Hi,
Marking this as Resolved: Incomplete due to the lack of response from the Hans-Peter.
If the issue is still reproducible with the latest Firefox version, feel free to reopen the bug with more information.

Comment 8

[Hans-Peter Jansen]

Here we go.

I can confirm this behaviour with 65.0 and 65.0.1 as well.

I'm sorry, but creating a new profile isn't a feasible option, since it involves creating many windows with many tabs in a certain order, and let it run for days. I cannot stop using FF in the usual way for that long. I depend on it too much!
Again. Sorry. Not an option.

Here's a workaround, that somewhat solves the problem temporarily, but has a downside as well.

In attachment Screenshot_20190217_firefox65.0.1_after_1d.png, you see the FF processes after one day. As you can see, the -childIO 8,9 and 10 are approaching 100%, saturating one core. I can mitigate the issue by terminating these processes.
FF will show the "one or more tabs crashed" window, and presents a button, which will rerun those again. Subsequent FF behaviour is back to normal again.

On a busy day, this procedure needs to be repeated 2-3 times. The lesser the distance from core saturation, the sluggishness increases up to a point, where FF is stalling.

The downside of this procedure is: my only(!) active add-on ADP+ gets into a non-functional state. It doesn't block any adds, nor does it show its configuration correctly.

As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1510762#c5, rerunning FF is no fun either, since it's unable to restore the session properly. The window positions and content is mixed up, only the tab order is preserved. FF 65 developed a new issue in this area: occasionally it "forgets" the URL of the active tab, and shows the "new tab" page instead.

I bet, the accumulation of CPU is related to some JS code, that piles up some (event) structures (those processes tend to have reserved the most memory as well).

Comment 9

[Hans-Peter Jansen]

How can I reopen this bug?

Comment 10

[Hans-Peter Jansen]

Attachment: Screenshot_20190217_firefox65.0.1_after_1d.png

Comment 11

[Liviu Seplecan]

Hi @Hans-Peter Jansen, Mention that I don't have openSUSE but I've tested this issue on Ubuntu 16.04 and cannot reproduce it. In my end the CPU range doesn't go over 10 % for 1h/30 min.
Additionally, the problem with restoring is another matter. I guess should remain to your main problem, the one with CPU high range.

Comment 12

[Liviu Seplecan]

Hi @Mike, can you help us with this issue? Is needed a performance profile recording to see what causes this high percentage of CPU? or other situation from which we figure it out what brings this increasing of CPU?
Thanks.

Comment 13

[Hans-Peter Jansen]

Hi @Liviu,

thanks for chiming in.

Yes, this issue should remain dedicated to the high cpu usage. I just wanted to outline, what issues a long time power user of FF may face...

As said, the issue accumulates over time. My FF runs up to 7 days because of https://bugzilla.mozilla.org/show_bug.cgi?id=1510762#c5 and starts miss-behaving with the second day.

It would be nice to be able to show the cpu usage relative to URL, possibly separated in JS, rendering, whatever...

Comment 14

[Liviu Seplecan]

Hi @Hans-Peter Jansen, until @Mike gives us a hand with that issue you could please capture a performance profile? You can get more info on how to install and use the Cleopatra add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
https://perf-html.io/
Thanks.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Typically, the first step with issues like this, is to eliminate add-ons and customizations as the source of the problem. In the event that it's a preference or add-on that is causing the issue, it allows us to more quickly reproduce and diagnose the issue. In the event that the problem can be reproduced without add-ons or customizations present, then it points to a deeper problem within Firefox itself (or the pages it's visiting), and we can start boxing in the problem from that state.

(In reply to Hans-Peter Jansen from comment #8)

I'm sorry, but creating a new profile isn't a feasible option, since it involves creating many windows with many tabs in a certain order, and let it run for days. I cannot stop using FF in the usual way for that long. I depend on it too much!
Again. Sorry. Not an option.

It's not necessary for you to create a new profile. What we're asking you to do is to use Firefox's Safe Mode to (temporarily, and in your default profile) disable your add-ons and customizations.

You can enter this mode by going to Help > Restart with Add-ons Disabled. Upon restart, a dialog will come up asking if you want to enter Safe Mode (say yes).

Especially for users that depend on a large number of add-ons or customizations, this mode might be a bit uncomfortable and not what you're used to, but it will certainly help us reduce the problem space to something we can try to fix.

Comment 16

[Hans-Peter Jansen]

Thanks @Mike for your reply.

Will do actively, but please note, that I effectively drive FF without plugins since I found the workaround of killing the -contentproc processes, which leaves adblock plus dysfunctional behind...

Especially for users that depend on a large number of add-ons or customizations, this mode might be a bit uncomfortable and not what you're used to, but it will certainly help us reduce the problem space to something we can try to fix.

I wouldn't count one a large number, but no problem, I've disabled adblock plus right now, and will follow the given procedure on the next run...

Comment 17

[Hans-Peter Jansen]

Liviu, Mike,

I'm going to close this issue now.

After migrating to openSUSE Tumbleweed, this issue dissolved.

FF is able to survive for a couple of days, and doesn't show any of the described problems, even with ABP enabled. Obviously, the much improved user space (glibc and other basic libraries) was the game changer here (because I provided current builds of rust, node, gcc for FF on the old system).

I'm very sorry to have wasted our time.

FF shines bright again, if only https://bugzilla.mozilla.org/show_bug.cgi?id=372650#c45 wouldn't spoil the show on FF restart/system reboot.