1397324 - 56b high amount of memory usage

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[hinoglu]

Attachment: memory-reports.tar

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170903140023

Steps to reproduce:

Apparently each upgrade on 56b series is using more and more ram than the previous ones. Daily usage causes ff to use 40%of ram until it starts to lag. Attached are the memory reports from 55b13, 56b01 and 56b09 for the same set of tabs that are 2 pinned tabs, one being the about:memory, 1 whatsapp web tab and 5 tabs of the same youtube video, playing at the same time . Even 55b13 and 56b01 significantly differ in memory usage. 


Actual results:

55b13 consistently allocates, then reduces the used memory in time.
56b01 consistently allocates, then reduces the used memory in time, but still using 5-8% more than 55b13. 
56b09 consistently allocates, then reduces the used memory in time, but still using 10-15% more than 55b13 for the same period

56b instances reduce the used memory, proportionally lesser than 55b13 does. 


Expected results:

Memory usage should stay in a stable margin, like 55b13 does. But with 56b instances, allocated memory keeps growing, especially with the later versions.

Comment 1

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: Memory reports of different scenarios.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID 20170910220126

I have tested this issue on Ubuntu 14.04 and Windows 10 x64, with Firefox beta (55.0b13), (56.0b1), (56.0b9) and the latest Nightly (57.0a1) build. I have managed to reproduce it using the steps provided in the description.

I've pinned two tabs (about:memory and web.whatsapp.com) and also i've opened five tabs of same youtube video. The memory consumption is reduced in time (~10 minutes), but still remains fairly high (in my case 800 Mb down from 1200 Mb).

In the attachment you will find 5 memory reports of different scenarios using latest Nightly and 1 memory report of 55.0b13.

Mike, can you please take a look over the memory reports and help us find a suitable component?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I'm afraid I'm unable to load any of the non-55.0b13 memory reports from the ZIP file. They appear to not be valid JSON.

Comment 3

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: Memory reports of different scenarios.zip

I've attached again the memory reports. Apparently adding the .gz extension to the files fixes the problem.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Thanks. I'm afraid I'm not seeing anything particularly suspicious in these memory reports. In fact, the memory usage is quite low.

I wonder if Firefox is just reserving (and not using) more memory. Instead of measuring memory usage with the Windows Task Manager or whathaveyou, can you use the memory reporter in about:performance? That should (hopefully) help measure actual allocations over reservation.

Comment 5

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: about_performance.zip

Hi Mike, I've attached the screenshots of the about:performance page.
Hinoglu, can you also provide screenshots of the about:performance page? I think it will be useful to compare the results.

Comment 6

[hinoglu]

Attachment: performance.zip

screenshots of the about:performance pages in all versions, including 56b12

Comment 7

[Selena Deckelmann :selenamarie :selena]

Marius -- can you have a look? Thanks!

Comment 8

[Marius Coman [:mcoman], Ecosystem QA]

If I compare the results from Hinoglu's screenshots of the about:performance page with my results, there are approximately the same (my memory usage is even bigger in a couple of cases).
Mike, can you please give us your opinion regarding these reports?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

One thing that jumps out to me is that neither of these about:performance screenshot sets show anything except the parent process.

cmarius, do you have e10s enabled?

Comment 10

[hinoglu]

@mconley well, i do have e10s enabled. 

As an update if it helps, 57b4 is very consistent on memory usage and freeing. Haven't had any lags yet with it.

Comment 11

[Marius Coman [:mcoman], Ecosystem QA]

Attachment: about_performance_new.zip

Hi Mike,

I've reproduced the issue and the behavior is the same on the next Firefox builds: release (56.0), latest Beta (57.0b6), latest Nightly (58.0a1), 55.0b13, 56.0b1 and 56.0b9.

The odd part is that when I've reproduced the issue again on Firefox 55.013, 56.0b1 and 56.0b9, using a new profile in each case, this time all the processes appeared in about:performance page not only the parent process.

I've attached screenshots of the about:performance page for each of the tested builds. 

Could you please see if something stands out?

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Nothing particularly egregious is standing out to me, I'm afraid.

Still, I'll whiteboard this for MemShrink in case the folks working on that see anything I don't.

Comment 13

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598

Comment 14

[Eric Rahm [:erahm]]

I'll try to repro.

Comment 15

[Selena Deckelmann :selenamarie :selena]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #14)
> I'll try to repro.

Any update?

Comment 16

[Eric Rahm [:erahm]]

We've had reports of youtube using a lot of memory, so that might be a separate issue (eg bug 1386177, comment 58). It's possible that's an issue with youtube itself holding references to old iframes. In general playing 5 videos at once is certainly a stress test, but may not be valid as a baseline for investigating memory regressions. Comparing memory across test runs can be tricky as well if things aren't timed properly. 

I'll test and see if the youtube issue here (memory keeps growing) mirrors other reports or if it's a separate issue.

Comment 17

[Eric Rahm [:erahm]]

Note that the tests for 55 in comment 1 had e10s disabled, the 56 ones don't. The 56 one appears to be from a linux machine, the 55 one is from windows. These aren't valid comparisons at all.

Comment 18

[Eric Rahm [:erahm]]

I'm unable to reproduce the memory-keeps-increasing behavior in 57, which is now in release, on Linux. The reporter also notes in comment 10 that everything seems fine in 57 for them. I'm going to close this as WFM

hinoglu, thank you for the thorough testing across revisions; feel free to reopen this bug if you experience these issues again.