240.00 KB, application/x-tar
835.04 KB, application/x-zip-compressed
264.00 KB, application/x-zip-compressed
371.04 KB, application/zip
208.70 KB, application/x-zip-compressed
Created attachment 8905084 [details] 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.
Created attachment 8906583 [details] 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?
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.
Flags: needinfo?(mconley) → needinfo?(marius.coman)
Created attachment 8906930 [details] Memory reports of different scenarios.zip I've attached again the memory reports. Apparently adding the .gz extension to the files fixes the problem.
Attachment #8906583 - Attachment is obsolete: true
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.
Component: Untriaged → Untriaged
Product: Firefox → Core
Created attachment 8907993 [details] 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.
Flags: needinfo?(marius.coman) → needinfo?(hinoglu)
Created attachment 8908982 [details] performance.zip screenshots of the about:performance pages in all versions, including 56b12
Marius -- can you have a look? Thanks!
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?
Flags: needinfo?(marius.coman) → needinfo?(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?
Flags: needinfo?(mconley) → needinfo?(marius.coman)
@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.
Created attachment 8915892 [details] 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?
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.
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
I'll try to repro.
(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #14) > I'll try to repro. Any update?
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.
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.