FF25, 26, 27, 28, 29 betas chew increasing amounts of CPU even when no user interaction

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: charlesc-mozilla.org, Unassigned)

Tracking

({perf})

29 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2015-03-15][bugday-20131106][needs profiler])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131028225529

Steps to reproduce:

1. Start firefox.  Open a number of windows and tabs - I typically have half a dozen windows and 30-40 tabs open.
2. Let all pages load completely, then leave firefox alone.  At this point, FF will typically be using a continuous 20% CPU.
3. Leave the machine alone for several hours with no interaction.
4. FF will now be using significantly more CPU.  At the moment, mine is up to 90%.  It will reach 100% eventually.

This happened in all the FF25 betas, and is happening in FF26 beta right now.  I'm in safe mode with no extensions, so it's not due to bad extensions.

This is on Linux, x86_64.


Actual results:

Firefox chews increasing amounts of CPU, eventually reaching 100%.


Expected results:

When not being actively used, FF's CPU usage should remain minimal and constant.
(Reporter)

Comment 1

5 years ago
For what it's worth, Firefox 26 beta 2 seems to have improved this.  I've had it running quiescently overnight and then in moderate use for several hours and CPU usage is still relatively low.  I'll need to wait a day or two to be certain it doesn't recur.

Updated

5 years ago
Keywords: perf
Whiteboard: [bugday-20131106]
(Reporter)

Comment 2

5 years ago
Turns out the problem is not fixed, it's just that CPU usage (and memory usage) is growing more slowly with FF26 beta 2 than beta 1 or FF 25 betas did.  I restarted Firefox and now some eight or nine hours later, with me not actively using it at the moment, it's sitting around 85% CPU again.

I'm not sure what it's actually doing.  If I strace the process, it's polling, reading, and writing in what looks like a quick loop, but that's about it.

i.e.:

[...]
poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
writev(11, [{"\24\0\6\0\365\n\200\10\32\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=11, events=POLLIN}], 1, -1)   = 1 ([{fd=11, revents=POLLIN}])
read(11, "\1\0009\r\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(11, 0x7f73421dc074, 4096)          = -1 EAGAIN (Resource temporarily unavailable)
read(11, 0x7f73421dc074, 4096)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
writev(11, [{"\24\0\6\0\25\7\200\10\32\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
poll([{fd=11, events=POLLIN}], 1, -1)   = 1 ([{fd=11, revents=POLLIN}])
read(11, "\1\0:\r\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(11, 0x7f73421dc074, 4096)          = -1 EAGAIN (Resource temporarily unavailable)
read(11, 0x7f73421dc074, 4096)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=11, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=11, revents=POLLOUT}])
writev(11, [{"\24\0\6\0\375\23\210\10\32\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 24}, {NULL, 0}, {"", 0}], 3) = 24
[...]

Comment 3

5 years ago
You can try "killall -ILL firefox" to cause a few crashes and send the crash reports, then get the report ids from about:crashes.
(Reporter)

Comment 4

5 years ago
I just tried this, but the new report took a long time to submit and does not show up in about:crashes (the last one listed is from a month ago), so perhaps it didn't go.
(Reporter)

Comment 5

5 years ago
FF26 beta 3 seems to have improved it yet again.  I let it upgrade and restart a few hours ago and CPU usage seems fairly low (~5%) at the moment.  I'll let it run overnight and see if it starts eating CPU again.
(Reporter)

Comment 6

5 years ago
FF26 beta 3 has definited improved things.  After leaving it overnight, it was still in single-digits CPU usage this morning, and after using it actively for a couple of hours, if I leave it alone CPU usage drops back into single digits.
I'll keep monitoring it for a while.
(Reporter)

Comment 7

5 years ago
I think I'm going to call this fixed by FF26 beta 3.  After using it normally yesterday and leaving it overnight again, FF was still in the single digits when I looked in on it this morning.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 8

5 years ago
This is back.  I'm not sure if it came back when I let FF26beta update to the next beta version or if it just took a long time for FF to start chewing CPU, but a quiescent FF is now back to using 100% CPU.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 9

5 years ago
Updated to next (current) beta again, problem is still there.  FF was using about 30% CPU, left the machine overnight, come back and it's sitting at 100%.
(Reporter)

Comment 10

5 years ago
Created attachment 8333484 [details]
strace log of what FF is doing while chewing CPU; approx 15s worth

What FF is doing while chewing 100% CPU.
(Reporter)

Comment 11

5 years ago
FF 27.0a2 is still doing this.
(Reporter)

Comment 12

5 years ago
Current Aurora (28.0a2) is still doing this.  I end up having to restart Aurora several times a day to take care of the spinning CPU.  It's really annoying.
Version: 26 Branch → 28 Branch
Charles, could you go to about:support and attach the results? 
Is this still happening?
Flags: needinfo?(charlesc-mozilla.org)
(Reporter)

Comment 14

5 years ago
Created attachment 8374280 [details]
about:support JSON

about:support output with current FF28 beta
Flags: needinfo?(charlesc-mozilla.org)
(Reporter)

Comment 15

5 years ago
Yes, it's still doing this in FF28 current beta.  Within a few hours of starting FF, it's chewing 100% of a CPU while doing nothing.

Comment 16

5 years ago
[testday-20140214]
I'm testing with Firefox 28.0b3 and windows 8 and it doesn't has such consumption of CPU, it could go from %0.6 to a maximum of %40.0, but never get to %90.

Comment 17

5 years ago
My Firefox 28.0 Beta does this sometimes.
(Reporter)

Comment 18

5 years ago
Clearly martinfp642@gmail.com is not seeing the same behaviour as I am.

To be clear:
 * every or almost every version of FF26, 27, and 28 (on Linux, x86_64) that I've tried seems to have suffered from this problem to some greater or lesser degree.  This is with both Aurora and FF beta, as I've switched back and forth between them a number of times.
 * the symptom is gradually increasing CPU usage and virtimage size *even when firefox is not being actively used at all*.  i.e. start Firefox, let it load up my windows & tabs from when I closed it, let it sit unused, and CPU usage will gradually climb to 100% or slightly more.  To me, this screams a leak of some sort (increasing memory size), and the garbage-collection or other management code takes longer and longer to run each time it goes over the objects (the increasing CPU usage).
 * in addition to increasing CPU usage, the browser seems to get more sluggish - i.e. it will take longer and longer to react to events such as mouse or keyboard input, getting worse even if the CPU usage was already ~100%.  I *think* this is an indicator that some single-threaded repeating job is taking longer and longer each time, eventually taking so long to complete that it interferes with the runnability of the part of the code processing input.
 * at its worst (i.e. some versions), this problem can render the browser unusably slow in as little as a couple of hours.  Current FF28 beta isn't the very worst I've seen, but it's quite bad.  I'm having to restart FF at least twice a day and sometimes more.  At its best (i.e. a very few versions) it has sometimes taken 2 or 3 days to slow down noticeably, and perhaps even longer to reach 100% CPU -- these versions are the ones that I couldn't tell immediately whether the problem was actually fixed or not.

I'd really like to help nail this down, but I don't know what other information I can supply - I've straced the task and attached the results, and I've collected the about:support info requested.  Anything else Mozilla devs would like me to do?
Charles, I looked around a little more and maybe this is the same issue as described in bug 508427. Sorry this has been a continuing problem. It also is hard for us to replicate in QA, and doesn't have crash information associated, so it's never been confirmed or triaged into somewhere that developers might have taken a look. Thanks for sticking with this and attaching more information.  We'll try to move this a bit further along :)

jaws, do you have any advice on what we can do to investigate this bug further, how I should tag it, or whose attention to bring it to? Thanks very much!
Flags: needinfo?(jaws)
You could see if maybe we are doing unnecessary repainting of the browser by enabling the nglayout.debug.paint_flashing_chrome pref in about:config.

The user interface of the browser will change colors each time an area is repainted. Repaints should only occur if the UI is visibly changing. Lack of movement/changes normally should not result in repaints.
Flags: needinfo?(jaws)
Flags: needinfo?(ioana.budnar)

Comment 21

5 years ago
I am not able to reproduce this issue with Fx 28 beta 1 build 2 (as per comment 14) on a Ubuntu 13.10 64bit machine. After loading 35 links in 6 windows, the CPU reached 35% after 3 hours; after 2 more hours and +10 links loaded, I get 45% CPU. No actions where made on this machine in that time.
Please let me know how can I help more.
Flags: needinfo?(ioana.budnar)

Comment 22

5 years ago
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #21)
> After loading 35 links in 6 windows, the CPU reached 35% after 3 hours; after 2 more hours and +10 links loaded, I get 45% CPU. No actions where made on this machine in that time.

I'd say that's high enough.  Although I always suspect the same site (tenderapp.com), and when I close its tabs, CPU load falls from > 60-90% to 30-something.  But maybe it's just a coincidence related to something like cache: with a tab of that site open, the load falls from 35% to 1-3% soon.

Comment 23

5 years ago
(In reply to [:Aleksej] from comment #22)
> 30-something.  But maybe it's just a coincidence related to something like
> cache: with a tab of that site open, the load falls from 35% to 1-3% soon.

I don't mean load there, but use by a firefox process according to htop.

Comment 24

5 years ago
(In reply to [:Aleksej] from comment #22)
> I'd say that's high enough.  Although I always suspect the same site
> (tenderapp.com), and when I close its tabs, CPU load falls from > 60-90% to

Now I am sure it's not a coincidence and not related to a proxy. When trying to write a comment at https://anki.tenderapp.com/discussions/effective-learning/112-need-help-formulating-questions, Firefox Beta was becoming too slow.
(Reporter)

Comment 25

5 years ago
I tried enabling nglayout.debug.paint_flashing_chrome pref, but I see no unusual behaviour.  It was only repainting after a control or other bit of chrome was "damaged" etc - normal windowing behaviour.  I'm running the latest FF 28 beta, and have upgraded my Ubuntu distro from natty to oneiric (long story), and FF is showing the same behaviour - I've had it open for a day, and it's spinning at 95% CPU.

Liz, it does look like bug 508427 is similar - but the observed behaviour is far worse in my case.  If it was only taking ~10% of my CPU when idling I wouldn't have even noticed.

Comment 26

5 years ago
(In reply to [:Aleksej] from comment #24)

If you can identify any tabs causing the load, the following might help.  In my case, it's probably a server-side bug.

Firefox' Developer Tools (Tools → Web Developer) include a profiler.  I ran it at this page (warning, it slows Firefox down a lot): https://anki.tenderapp.com/discussions/ankidesktop/5870-buried-card-number-in-cards-types-list , and found the call that is causing the load.  Here is a manual for the profiler: https://developer.mozilla.org/en-US/docs/Tools/Profiler
taras, gandalf, can either of you take a look or help us get this bug to where it should be for a developer to look at it?   Thanks!
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics: Layers
Ever confirmed: true
Flags: needinfo?(taras.mozilla)
Flags: needinfo?(gandalf)
Product: Firefox → Core

Comment 28

5 years ago
s/taras/vladan/
Flags: needinfo?(taras.mozilla)
(Reporter)

Comment 29

5 years ago
I let FF upgrade from the 28 beta to 29 beta yesterday, and this problem looks better.  I'll have to keep an eye on it for a few days, but at the moment FF when quiescent is using only a few percent CPU.
Component: Graphics: Layers → General
Product: Core → Firefox
(Reporter)

Comment 30

5 years ago
No, I spoke too soon.  I've been away from the machine for some hours, and FF 29 beta is now using ~50% CPU while quiescent.  So the problem's still there.
(Reporter)

Updated

5 years ago
Version: 28 Branch → 29 Branch
(Reporter)

Updated

5 years ago
Summary: FF26 beta and 25 betas chew increasing amounts of CPU even when no user interaction → FF25, 26, 27, 28, 29 betas chew increasing amounts of CPU even when no user interaction
Component: General → General
Product: Firefox → Core
(Reporter)

Comment 31

5 years ago
The FF30 betas appear to have finally fixed this issue for me.  I've not noticed the problem in at least several days; I will keep an eye out for a few more.
(Reporter)

Comment 32

4 years ago
... and it's back.

The FF30 betas were indeed much better than before, and the first few FF31 betas seemed fine too, but I let FF update to the latest FF31 beta yesterday, and the problem is back.  After not very long, FF again hits 100% CPU usage and appears to stay there, and its VM footprint grows constantly.
(Reporter)

Comment 33

4 years ago
Hm: FF31 may not actually have this bug, as it hasn't repeated for me since it happened above.  CPU usage is occasionally somewhat higher than I'd like, but it doesn't climb continuoually until it reaches 100% as previous versions did -- perhaps it was a different issue causing it this one time.

Comment 34

4 years ago
(In reply to Liz Henry :lizzard from comment #27)
> taras, gandalf, can either of you take a look or help us get this bug to
> where it should be for a developer to look at it?   Thanks!

(In reply to Taras Glek (:taras) from comment #28)
> s/taras/vladan/
Flags: needinfo?(vdjeric)
(Reporter)

Comment 35

4 years ago
This is definitely back.  In v31-rc1 and -rc2, after a couple of days of normal use, FF is eating 100% CPU when idle, and UI responsiveness goes to hell.
- Can I ask you to capture a Firefox profile when you see this behavior again? Info on setting up the profiler and sharing the profile: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem
- How big is the sessionstore.js file in your firefox profile directory?
Flags: needinfo?(vdjeric) → needinfo?(charlesc-mozilla.org)
(Reporter)

Comment 37

4 years ago
Ok, I've installed the profiler (in current beta, v31-rc2, not nightly) and will report when I can reproduce.  As I said, the problem has generally taken a couple of days of usage for it to manifest in the current rcs.

This profile's sessionstore.js is currently ~190k (190551 bytes).  I normally have half a dozen windows and somewhere between 50 and 150 tabs (total) open at a time.
Flags: needinfo?(charlesc-mozilla.org)

Comment 38

4 years ago
This seems pretty stalled, and not actionable without more information.
If you no longer see the problem, please close the bug report.
Flags: needinfo?(gandalf) → needinfo?(charlesc-mozilla.org)
Whiteboard: [bugday-20131106] → [closeme 2015-03-15][bugday-20131106][needs profiler]
(Reporter)

Comment 39

4 years ago
I wasn't able to capture a performance profile as I was running the beta, and it appeared to require using a nightly build.

However, I have not been seeing the problem with more recent betas (I'm on 37 atm).  I'll close this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago4 years ago
Flags: needinfo?(charlesc-mozilla.org)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.