Open Bug 1672272 Opened 5 years ago Updated 4 years ago

High memory use and slow performance on Windows

Categories

(Core :: JavaScript: GC, defect, P2)

Product:
Core
Component:
JavaScript: GC
Platform:
All
Windows 10
Type:
defect

Tracking

()

People

(Reporter: mstange, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

memory usage in system monitor
170.64 KB, image/png
Details
about:memory dump
2.37 MB, application/x-gzip
Details

Basic information

I'm filing this bug on behalf of Mikal (mlewis@moz, cc'ed). Mikal is seeing high memory usage and bad responsiveness in Firefox 81 on Windows.

Profiles:

In the profiles I can see that the Grammarly and 1Password add-ons are installed.

Basic systems configuration:

OS version: Windows 10

GPU model: unknown

Number of cores: 4 physical, 8 logical

Amount of memory (RAM): unknown

Attached file about:memory dump —

(In reply to Markus Stange [:mstange] from comment #0)

This profile shows a huge amount of time spent in GC, in two of the content processes. This aligns with the high memory usage but it doesn't tell us what's taking up the memory.

about:memory dump (attachment 9182758 [details])

The dump is a bit weird. This is from a different occurrence of the problem, and two of the content processes take up 3GB, relatively evenly distributed over GMail and Google docs tabs, from what I can tell.

However, web content process 11244 has incomplete data:

WARNING: the 'heap-allocated' memory reporter does not work for this platform and/or configuration. This means that 'heap-unclassified' is not shown and the 'explicit' tree shows less memory than it should.
190.51 MB (100.0%) -- explicit

This is showing web content process 11244 (the one with incomplete data) to be blocked for a full minute in JSRope::hash, during xpc::JSReporter::CollectReports. So I think this is the process with the problem.

Does this mean we have accumulated gigantic JS strings?
It's too bad that about:memory doesn't have the data for the one process that we want to see.

Mikal, the following information would be helpful in tracking this down:

  • How often does this problem occur?
  • Could you check if it also occurs if you turn off the Grammarly add-on?
  • When it occurs again, before it gets extremely bad, can you capture another dump on about:memory? Hopefully it will succeed.
Flags: needinfo?(mlewis)

(In reply to Markus Stange [:mstange] from comment #4)

Mikal, the following information would be helpful in tracking this down:

  • How often does this problem occur?
    I can get a regular repro about two days after restart. Last count, it happens between 180-200 tabs. Which, due to aggressive web app open in new tab behavior happens on my work PC in about two days of work. Other browsers perform on this computer without issue.
Flags: needinfo?(mlewis)

Thanks! So we have a many-tabs situation, and a lot of those tabs seem to be gmail.

I took a look through the about:memory dump and I think this is a GC problem. Most of the gmail tabs have around 40-60MB in the js-zone/unused-gc-things bucket. On my machine, my gmail tabs currently only have 0.05MB and 0.58MB in that bucket.

I also wonder if other browsers are better at dealing with this case because they unload background tabs (do they?).

Jon, could you take a look at the about:memory dump and see if you notice anything suspicious?

Component: Performance → JavaScript: GC
Flags: needinfo?(jcoppeard)

(In reply to Markus Stange [:mstange] from comment #3)

It's too bad that about:memory doesn't have the data for the one process that we want to see.

If the anonymize box is checked, then I think the memory reporter will skip the string analyzer which might help in this particular case.

I looked at the report and I'm not really sure what might be going wrong. A few of the pages seem to be allocating a ton of stuff, resulting in lots of fragmentation. madison.com, gmail and google.com seem to have tons of unused-gc-things. In pid 18256, the google.com page has around 3300 copies of a ton of different strings, including lots of different search results for lots of different individual states, which seems weird. Seems like some kind of leak?

Some of the gmail windows have a ton of hangouts iframes which seems bad.

Mikal, could you capture another pair of about:memory reports, when the problem occurs again? First capture it normally, then, click "GC" under "Free Memory" on the page, and then save another capture. And then upload both captures.
This is an idea Paul Bone had in the memshrink channel and will hopefully tell us whether it's a GC scheduling problem.

Flags: needinfo?(mlewis)

(In reply to Markus Stange [:mstange] from comment #6)

Most of the gmail tabs have around 40-60MB in the js-zone/unused-gc-things bucket.

There are quite a lot of unused GC things but I don't think that's the root of the problem. This means there has been a lot of memory churn but compacting GC has not happened. Usually compacting GC runs when the user is idle. If the browser has been in use a couple of days it seems strange that this wouldn't have happened, but it could be due to current/recent use.

The GC in the first profile is much slower than I'd expect. I'd like to know the machine's memory configuration and how much physical RAM it has compared to the size of the Firefox processes.

Flags: needinfo?(jcoppeard)

(In reply to Markus Stange [:mstange] from comment #10)

Mikal, could you capture another pair of about:memory reports, when the problem occurs again? First capture it normally, then, click "GC" under "Free Memory" on the page, and then save another capture. And then upload both captures.
This is an idea Paul Bone had in the memshrink channel and will hopefully tell us whether it's a GC scheduling problem.

Pre: https://1drv.ms/u/s!At62kwkMbTkdroQZP7vH3L-NbiCheg?e=kkFLdR
Post: https://1drv.ms/u/s!At62kwkMbTkdroQa79ZPXUR5LmhMrg?e=CsaLh6

Flags: needinfo?(mlewis)

(In reply to Jon Coppeard (:jonco) from comment #11)

(In reply to Markus Stange [:mstange] from comment #6)

Most of the gmail tabs have around 40-60MB in the js-zone/unused-gc-things bucket.

There are quite a lot of unused GC things but I don't think that's the root of the problem. This means there has been a lot of memory churn but compacting GC has not happened. Usually compacting GC runs when the user is idle. If the browser has been in use a couple of days it seems strange that this wouldn't have happened, but it could be due to current/recent use.

The GC in the first profile is much slower than I'd expect. I'd like to know the machine's memory configuration and how much physical RAM it has compared to the size of the Firefox processes.

Config: https://1drv.ms/u/s!At62kwkMbTkdroQbfNSDTG4Jt9zUmQ?e=OXLyoC
32 GB of Ram.

(In reply to mlewis@mozilla.com from comment #12)

Post: https://1drv.ms/u/s!At62kwkMbTkdroQa79ZPXUR5LmhMrg?e=CsaLh6

This upload seems to be corrupted (incomplete). After renaming it to .json.gz, I cannot uncompress it.

(In reply to mlewis@mozilla.com from comment #12)

Pre: https://1drv.ms/u/s!At62kwkMbTkdroQZP7vH3L-NbiCheg?e=kkFLdR

Interesting. This one looks a bit different compared to the one from comment 5, in that the unused-gc-things buckets are about 5x smaller, mostly around 5-10MB. So this one looks more like it's "just a lot of gmail tabs".
With one anomaly: The google.com search page about electoral votes which Andrew mentioned in comment 8 is taking 1GB on its own by having 4500 copies of many strings. So that one is either caused by a misbehaving Google script, or potentially by an add-on. (Or by a bug in Firefox.)

@m(In reply to Markus Stange [:mstange] from comment #15)

(In reply to mlewis@mozilla.com from comment #12)

Pre: https://1drv.ms/u/s!At62kwkMbTkdroQZP7vH3L-NbiCheg?e=kkFLdR

I should be able to repro in about two days based on normal use. I'll recreate a snapshot then.

I also have Grammarly disabled now so that variable will be isolated--look out world! Typos here we come.

The severity field is not set for this bug.
:jonco, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jcoppeard)
Severity: -- → S3
Flags: needinfo?(jcoppeard)

(In reply to Markus Stange [:mstange] from comment #15)

(In reply to mlewis@mozilla.com from comment #12)

Pre: https://1drv.ms/u/s!At62kwkMbTkdroQZP7vH3L-NbiCheg?e=kkFLdR

Interesting. This one looks a bit different compared to the one from comment 5, in that the unused-gc-things buckets are about 5x smaller, mostly around 5-10MB. So this one looks more like it's "just a lot of gmail tabs".
With one anomaly: The google.com search page about electoral votes which Andrew mentioned in comment 8 is taking 1GB on its own by having 4500 copies of many strings. So that one is either caused by a misbehaving Google script, or potentially by an add-on. (Or by a bug in Firefox.)

Ooh, interesting. It depends on how the strings are being created, but ordinarily I would expect it to be difficult to create this many duplicate strings because they'll be deduplicated when they are tenured. (So you can add at most one duplicate per minor GC.) The strings might be created in a way that doesn't allow nursery strings, or perhaps we have previously disabled nursery strings because too few of them were short-lived. In the latter case, bug 1522186 might help.

I can't think of a way from telling from a memory dump whether pretenuring is happening.

Blocks: sm-leaks
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: