1675554 - High memory use with Fission enabled

Status: RESOLVED DUPLICATE of bug 1690956

(Core :: DOM: Content Processes, defect, P3)

Description

[Asif Youssuff]

Attachment: comment-0-memory-report.json.gz

Dogfooding Fission and often run out of memory and experience swapping on a 8GB machine.

See attached memory report.

Comment 1

[Andrew McCreight [:mccr8]]

We do have bug 1675203 about a recent regression that causes high heap-unclassified, though you only have a few hundred MB of that so it might not be the issue, unless you were very close to your memory limits before.

Comment 2

[Andrew McCreight [:mccr8]]

Other than that, I don't see anything in particular that stands out. You have a lot of tabs open.

There are some detached windows, and some ghost windows in your Reddit process, so maybe that's causing some of the slowness.

Comment 3

[Andrew McCreight [:mccr8]]

Removing the profiler would also save you maybe half a GB of memory, if you aren't actively using it.

Comment 4

[Asif Youssuff]

Removing the profiler? I thought it was only "active" when it was recording.

Comment 5

[Andrew McCreight [:mccr8]]

I don't know how it works, but there's about 40MB per process of memory being used in your about:memory report.

Comment 6

[Chris Peterson [:cpeterson]]

Asif, the profiler memory overhead does seem to be a small problem but it adds up with more processes.

I am told that the profiler keeps memory (LUL data in every process) around after it finishes recording. I'll ask if we can unload that profiler memory after it is no longer needed. The profiler is typically only used by developers, not regular users, so optimizing its memory usage has not been a high priority. :)

In the meantime, can you try running Fission without activating the profiler? It will be interesting to see if you still see memory problems without the profiler using memory.

You've filed a few related bugs about Fission memory usage. They're all probably the same root cause, so let's consolidate all our investigation and discussion in this bug report here. I'll link those other bugs reports to this one. Thanks!

Comment 9

[Asif Youssuff]

FWIW, I don't recall running the profiler in the browsing session that I reported. Happy to grab a new memory report while making sure I don't run the profiler.

I'll also note that I ended up expanding my swap size from 4GB to 8GB due to the frequent swapping I was seeing over a day of use - this is not likely to be something that users will do manually. Additionally, I tend to restart Firefox on every nightly build, so seeing Firefox lead to swapping after a few hours does not bode well for people with high tab counts running Firefox and a few other desktop apps - to be clear, I am also running Signal desktop and an email client most of the time - which I don't think is an unusual pattern of use.

Comment 10

[Asif Youssuff]

Attachment: comment-10-memory-report.json.gz

Attaching a new memory profile - Firefox used nearly all of the memory not used by my desktop environment, including dipping into swap. I did not run the Firefox profiler as well.

Comment 12

[Chris Peterson [:cpeterson]]

(In reply to Asif Youssuff from comment #10)

Attaching a new memory profile - Firefox used nearly all of the memory not used by my desktop environment, including dipping into swap. I did not run the Firefox profiler as well.

Thanks, Asif. Knowing that the memory problem and swapping can happen without the profiler memory is helpful.

@ mccr8: Nika says the latest memory report (comment 10) shows 800 MB of heap-unclassified in parent process. Do you have any suggestions for diagnosing the cause? Should we ask the reporter to run DMD?

Nika also says the memory report shows 1022 memory pressure notifications! The reporter has over 100 content processes. Will a memory pressure notification cause every content process to GC simultaneously? That stampede could definitely impact performance or cause swapping. (The reporter's machine has 8 GB RAM and 8 GB swap.) Do we have a bug to schedule GC more intelligently across many content processes?

Comment 13

[Andrew McCreight [:mccr8]]

(In reply to Chris Peterson [:cpeterson] from comment #12)

@ mccr8: Nika says the latest memory report (comment 10) shows 800 MB of heap-unclassified in parent process. Do you have any suggestions for diagnosing the cause? Should we ask the reporter to run DMD?

That is a lot of heap-unclassified, even given the large number of pages that are open. Maybe it is IPC overhead? DMD would help. Is this OSX? There is a known heap-unclassified issue on OSX involving WebRender and fonts.

Nika also says the memory report shows 1022 memory pressure notifications! The reporter has over 100 content processes. Will a memory pressure notification cause every content process to GC simultaneously? That stampede could definitely impact performance or cause swapping. (The reporter's machine has 8 GB RAM and 8 GB swap.) Do we have a bug to schedule GC more intelligently across many content processes?

Paul is looking at this in bug 1629064.

Comment 14

[Paul Bone [:pbone]]

(In reply to Chris Peterson [:cpeterson] from comment #12)

Nika also says the memory report shows 1022 memory pressure notifications! The reporter has over 100 content processes. Will a memory pressure notification cause every content process to GC simultaneously? That stampede could definitely impact performance or cause swapping. (The reporter's machine has 8 GB RAM and 8 GB swap.) Do we have a bug to schedule GC more intelligently across many content processes?

Ouch. that's going to be really really painful when things are already swapping. That's not something I had considered so far.

Comment 15

[Nika Layzell [:nika] (ni? for response)]

(In reply to Andrew McCreight [:mccr8] from comment #13)

(In reply to Chris Peterson [:cpeterson] from comment #12)

@ mccr8: Nika says the latest memory report (comment 10) shows 800 MB of heap-unclassified in parent process. Do you have any suggestions for diagnosing the cause? Should we ask the reporter to run DMD?

That is a lot of heap-unclassified, even given the large number of pages that are open. Maybe it is IPC overhead? DMD would help. Is this OSX? There is a known heap-unclassified issue on OSX involving WebRender and fonts.

I don't think it's macOS, because the hidden window is hiddenWindow.html in the memory log, not hiddenWindowMac.xhtml. I'm guessing Linux because there's also no GPU process, which is usually present on Windows.

I've also occasionally noticed abnormally heap-unclassified on Linux in the parent process, which is why I was looking into DMD a week ago or so, but I haven't been able to figure out exactly what was using the memory, as I wasn't running a DMD-enabled profile for long enough.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #15)

I've also occasionally noticed abnormally heap-unclassified on Linux in the parent process, which is why I was looking into DMD a week ago or so, but I haven't been able to figure out exactly what was using the memory, as I wasn't running a DMD-enabled profile for long enough.

Nika, note that you can run DMD with a regular Nightly build. That's what I'm doing since weeks, and found a couple of heap-unclassified issues. Just start Firefox from the console like:

DMD=1 /Applications/FirefoxNightly.app/Contents/MacOS/firefox --mode=dark-matter --stack=full

Comment 17

[Asif Youssuff]

Attachment: memory-report.json-2020-11-27.gz

Ran into a pretty bad case of bad swapping on Windows 10 today. Attaching a memory report from after quitting Thunderbird. Hope there are interesting things here.

Comment 18

[Chris Peterson [:cpeterson]]

(In reply to Asif Youssuff from comment #17)

Created attachment 9190067 [details]
memory-report.json-2020-11-27.gz

This memory report shows about 800 MB of heap-unclassified memory. We need to figure out what that is. May be related to cert_storage bug 1677866 or cookie jar bug 1677882.

There is no GPU process, so this is not WebRender related.

I see Asif just attached a DMD report to Fission bug 1690956. Since the memory problems in these bugs look related, I will close this bug as a duplicate of bug 1690956. We are tracking that bug for Fission.