1596857 - High memory usage with Fission enabled and dom.ipc.processCount = -1

Status: RESOLVED DUPLICATE of bug 1634063

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

Description

[Asif Youssuff]

Attachment: memory-report.json.gz

I am seeing unexpectedly high memory use on my machine - it feels like it is worse in the past few days than ever before. I have Fission and unlimited content processes enabled.

Memory report attached.

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

[Andrew McCreight [:mccr8]]

I see lots of content processes, which to some extent is expected, but lots of them, like the one for PID 481069, don't have anything besides about:blank loaded in them.

Do you still see this behavior if you don't have dom.ipc.processCount set to -1? That should not be needed for Fission, because we will always create new processes for new domains, but it might be causing us to not recycle processes when all of the pages in a process go away.

Comment 3

[Andrew McCreight [:mccr8]]

I also see the Devtools loaded in a lot of these processes, so it is possible that some dev tools usage is keeping the processes alive.

Comment 4

[Asif Youssuff]

I actually have a bunch of about:blank pages open because I found that Firefox startup was very slow on session restore (I have 10 windows open) while doing some regression testing a few days ago.

I can restore the default value for dom.ipc.processCount and see how things go.

I don't think I have DevTools opened anymore, but I was attempting to debug an extension (that I have since removed), so I'm not really sure why those would still be around. I guess it may be open in a tab that I don't see open at the moment though.

Comment 5

[Andrew McCreight [:mccr8]]

Ok. If you have a bunch of about:blank pages open, then the behavior you are seeing might be expected behavior with Fission. We are trying to reduce the memory overhead of content processes, but it is still fairly high if you have a lot of tabs open. For instance, PID 486931 has some static content page served from some AWS subdomain in it, and the page itself only takes 1.22MB, but the process as a whole is using about 48MB.

Bug 1595707 landed about 5 days ago, and regressed the amount of heap-unclassified in content processes, and I do see a lot of heap-unclassified, so maybe that is what is going on here.

Comment 6

[Andrew McCreight [:mccr8]]

I'll speculatively mark the regression, because the timing and symptoms seem to match up well.

Comment 7

[Chris Peterson [:cpeterson]]

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Comment 8

[Chris Peterson [:cpeterson]]

Memory usage is higher than expected, but Andrew and kmag say this is not a dogfooding blocker (M5 milestone).

Comment 9

[Andrew McCreight [:mccr8]]

Have you been using Fission for awhile? I'm just wondering if the increase in memory usage might be from enabling Fission, or if it feels like the memory usage with Fission enabled increased. It sounded like you meant the latter, but I want to make sure I am understanding you correctly. Thanks.

Comment 10

[Asif Youssuff]

I had been using Fission in this configuration since it became available in Nightly builds. Since I set the content process limit back to the default (not -1), memory usage has been better -- I have not had any memory swapping issues.

Is dom.ipc.processCount = -1 not advisable with Fission? Is there any downside or benefit to keeping it enabled?

Comment 11

[Andrew McCreight [:mccr8]]

(In reply to Asif Youssuff from comment #10)

I had been using Fission in this configuration since it became available in Nightly builds. Since I set the content process limit back to the default (not -1), memory usage has been better -- I have not had any memory swapping issues.

Great, thanks for clarifying. I'm going to clear the regressed by thing because we're not entirely sure what is going on here.

Is dom.ipc.processCount = -1 not advisable with Fission? Is there any downside or benefit to keeping it enabled?

Well, I would expect that it doesn't do anything, but I would guess that nobody else besides you has tried it, so I am a little concerned that there could be some unintended interaction.

Comment 12

[Neha Kochar [:neha]]

Randell, this might be of interest to you.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

The patch to remove the memory regression from bug 1595707/bug 1572337 has landed and should be in Nightly. All it would do is cause a few hundred K per process of head-unclassified to be allocated. (likely 100-200K/per-process - ~2k per thread). The fix actually reduces memory use below the original amount

Comment 14

[Asif Youssuff]

Attachment: memory-report-2019-12-01.json.gz

Experienced a near OOM event today -- took another profile. Hoping this may be interesting in some way.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Chris Peterson [:cpeterson]]

Asif, have you seen this memory usage with Fission lately?

Are you still using dom.ipc.processCount = -1?

Comment 17

[Asif Youssuff]

I haven't been using dom.ipc.processCount = -1 so I haven't seen this issue. I can go back if you like, but I'm pretty sure I just stopped using it after I was asked not to in this bug.

Keep in mind that prior to Fission, I used this configuration for a decent amount of time (months) and never ran into memory issues like the one reported here.

Comment 18

[Paul Bone [:pbone]]

FYI Randel, this may be of interest.

Comment 19

[Chris Peterson [:cpeterson]]

Alex, this may be a DevTools bug. kmag looked at the attached memory report. The report shows many DevTools processes using lots of memory but having no windows.

The report shows many "web" processes and no "webIsolated" (Fission) processes. The web processes have the same origin, so they are actual Fission processes. I filed new bug 1643787 to fix memory reports to report Fission's processes as "webIsolated" instead of "web".

Tracking for Fission M7 Beta

Comment 20

[Alexandre Poirot [:ochameau]]

If you are opening the Browser Console or Browser Toolbox, then, yes you can easily get OOM if you keep your browser open for a while, or, have lots of processes.
Fission support means that we suddently inspect all the processes when opening these two tools, and it stresses all the tools a lot, because that's like opening devtools in each individual tab.
We are currently time pressured to fix DevTools support for Fission. We know that there is an associated performance penalty.
In many cases it only highlights already existing performance issues, which should be tracked by bug 1378418.
Otherwise, we are tracking fission specific perf issues via bug 1643041.

But, if you weren't opening them, or were only opening one tab DevTools, we should probably investigate this issue right away.
Do you have an STR to reproduce this?

Comment 21

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

(In reply to Alexandre Poirot [:ochameau] from comment #20)

If you are opening the Browser Console or Browser Toolbox, then, yes you can easily get OOM if you keep your browser open for a while, or, have lots of processes.

See my filed bug 1634063. I believe it covers exactly this underlying problem.

Comment 22

[Neha Kochar [:neha]]

Marking it dup based on comment 21.