High memory and CPU usage on www.tvnow.de with garbage collector involved
Categories
(Core :: XPCOM, defect)
Tracking
()
| Performance Impact | low |
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: memory-footprint, perf, perf:responsiveness)
Over the last day with running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:84.0) Gecko/20100101 Firefox/84.0 ID:20201108212832 I noticed the following huge memory usage for one of the web content processes including www.tvnow.de:
4,336,725,992 B (100.0%) -- explicit
├──3,564,624,088 B (82.20%) -- window-objects
│ ├──3,503,335,168 B (80.78%) -- top(https://www.tvnow.de/serien/unter-uns-20/2020-11/episode-6481-janas-geburtstag-3561382, id=445)
│ │ ├──3,431,190,776 B (79.12%) -- active
│ │ │ ├──3,431,047,016 B (79.12%) -- window(https://www.tvnow.de/serien/unter-uns-20/2020-11/episode-6481-janas-geburtstag-3561382)
│ │ │ │ ├──3,409,407,824 B (78.62%) -- js-realm(https://www.tvnow.de/serien/unter-uns-20/2020-11/episode-6480-eva-im-kampf-um-noah-3523479?isAutoStart=1)
│ │ │ │ │ ├──3,404,097,840 B (78.49%) -- classes
│ │ │ │ │ │ ├──1,154,281,136 B (26.62%) -- class(Function)/objects
│ │ │ │ │ │ │ ├────827,685,616 B (19.09%) ── gc-heap
│ │ │ │ │ │ │ └────326,595,520 B (07.53%) ── malloc-heap/slots
│ │ │ │ │ │ ├────748,552,784 B (17.26%) -- class(Object)/objects
│ │ │ │ │ │ │ ├──474,525,968 B (10.94%) ── gc-heap
│ │ │ │ │ │ │ └──274,026,816 B (06.32%) -- malloc-heap
│ │ │ │ │ │ │ ├──231,263,232 B (05.33%) ── slots
│ │ │ │ │ │ │ └───42,763,584 B (00.99%) ── elements/normal
│ │ │ │ │ │ ├────422,245,648 B (09.74%) -- class(LexicalEnvironment)/objects
│ │ │ │ │ │ │ ├──422,238,928 B (09.74%) ── gc-heap
│ │ │ │ │ │ │ └────────6,720 B (00.00%) ── malloc-heap/slots
│ │ │ │ │ │ ├────376,471,424 B (08.68%) -- class(Call)/objects
│ │ │ │ │ │ │ ├──376,379,456 B (08.68%) ── gc-heap
│ │ │ │ │ │ │ └───────91,968 B (00.00%) ── malloc-heap/slots
│ │ │ │ │ │ ├────326,997,200 B (07.54%) -- class(Array)/objects
│ │ │ │ │ │ │ ├──321,296,256 B (07.41%) ── gc-heap
│ │ │ │ │ │ │ └────5,700,944 B (00.13%) -- malloc-heap
│ │ │ │ │ │ │ ├──5,560,352 B (00.13%) ── elements/normal
│ │ │ │ │ │ │ └────140,592 B (00.00%) ── slots
│ │ │ │ │ │ ├────316,734,592 B (07.30%) -- class(Arguments)/objects
│ │ │ │ │ │ │ ├──211,150,080 B (04.87%) ── gc-heap
│ │ │ │ │ │ │ └──105,584,512 B (02.43%) -- malloc-heap
│ │ │ │ │ │ │ ├──105,583,424 B (02.43%) ── misc
│ │ │ │ │ │ │ └────────1,088 B (00.00%) ── slots
Beside the high memory usage this also causes a constant 80% CPU usage of the web content process. It all seems to be related to the garbage collector.
Here the Firefox profile: https://share.firefox.dev/3eJe1xT
Andrew, mind having a look at this? Could this be a regression? I haven't seen that behavior before yet while constantly observing this page. The only thing i did was to turn off ublock origin yesterday.
Comment 1•5 years ago
|
||
This looks like a JS issue, so I'm forwarding it to Jon.
I'll note we have a ton of existing issues on this website on file so maybe this is a dupe: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=tvnow.de&list_id=15483820
| Reporter | ||
Comment 2•5 years ago
|
||
The others are all different in how the profile looks like. So I filed this as a new bug. Also I don't use HD videos on that site for testing.
| Reporter | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #0)
How much RAM does your machine have? Based on how slow the GC in the profile is, I suspect your computer is swapping.
I wasn't able to reproduce this locally, either the high memory usage or high CPU usage.
The only thing i did was to turn off ublock origin yesterday.
Does it reproduce with ublock enabled again? It may be an ad frame doing something crazy.
| Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #3)
How much RAM does your machine have? Based on how slow the GC in the profile is, I suspect your computer is swapping.
My machine has 16GB of memory. But note that I also run another Firefox process in parallel, so a couple of GB already go into that one. So when this problem was visible I clearly had less than 1GB left.
I wasn't able to reproduce this locally, either the high memory usage or high CPU usage.
Maybe it might take a bit of time (eg. watching different videos) until the problem starts. It happened once to me so I don't have step to reproduce yet.
The only thing i did was to turn off ublock origin yesterday.
Does it reproduce with ublock enabled again? It may be an ad frame doing something crazy.
Well, I never have seen it with ublock origin turned on. So for testing purposes I left it off. Since I reported that bug I haven't had the time to watch anything else on that site.
| Reporter | ||
Comment 5•5 years ago
|
||
Actually they might have changed something on their site last week. With ublock origin enabled I'm no longer able to watch videos since then, which actually caused me to disable the extension on that site. Before that change it was able to remove any commercials.
Note that when the problem happened no active or paused video was displayed in the tab, which was also in the background for about a day.
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Since it's no longer reproducible, can we close this as WFM?
| Reporter | ||
Comment 7•5 years ago
|
||
What I meant was that a change on that particular website might have actually caused this problem. Usually I use ublock origin, but due to the change I wasn't able to and deactivated the extension for that site.
Here another profile as recorded today: https://share.firefox.dev/3lp8RsL
| Reporter | ||
Comment 8•5 years ago
|
||
Mike, what was the reason to move this bug from JS:GC over to performance? A clarification would be nice. Thanks.
Comment 9•5 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away 12/11 - 01/03) from comment #8)
Mike, what was the reason to move this bug from JS:GC over to performance? A clarification would be nice. Thanks.
Mainly to ensure it'd get triaged by someone from the Performance team.
Comment 10•5 years ago
|
||
The profile from comment 7 shows the content process was doing GC and causing 7.3 seconds jank, moving back to GC.
Comment 11•5 years ago
|
||
Sorry to play ping pong, but the time is actually going to the CC (nsCycleCollector_collectSlice, while building the graph). I really need to add those subcategories to make this more clear.
Much time went into resizing the hashtable, suggesting that the CC graph is pretty huge.
| Reporter | ||
Comment 12•5 years ago
|
||
Maybe the huge memory usage related to bug 1641673 is causing that as a side-effect? It's not happening all the time but only when I leave the video paused for hours or some days in a background tab, and continue playing.
Updated•4 years ago
|
Updated•3 years ago
|
Description
•