Closed Bug 1190170 Opened 4 years ago Closed 4 years ago

[e10s] (MacOSX) Nightly (FF42.0a1) main process use a lot of memory and the amount of memory continuously rises with daily browsing

Categories

(Core :: Graphics, defect, P1, major)

42 Branch
x86
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1264161
Tracking Status
e10s + ---
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- ?
firefox47 --- ?
firefox48 --- ?
firefox49 --- ?

People

(Reporter: mkem, Assigned: BenWa)

References

Details

(Whiteboard: [MemShrink:P1] gfx-noted)

Attachments

(13 files)

Version of Nightly: 42.0a1 (2015-08-01)

Since last 2 or 3 weeks there is something wrong with Nightly's memory consumption. 
I have executed Nightly for 16 hours and visited about 100 pages (10 - 20 websites) and the "main" process of Nightly have over 900 MB. 
I closed all windows of Nightly and tried to minimize memory by clicking on "minimize memory usage" on about:memory page. I waited 1 min and then I clicked on "measure" button. But the result was no change. Still the process had 900 MB. No windows opened, 0 ghost windows. 
This behaviour is very strange, because 1 month ago the "main" process of Nightly had consumption about 400 MB after 4 days of running with 50 - 70 visited pages per day.
I also noticed that the measure of total memory (resident) on about:memory is different from measure of OS X. In the past the measures were equal.
I createed some attachment, which should prove my statements.
After the reporting of the bug I tried to minimize memory usage again and the results are in the attached screenshot. Only about 20 MB were released and about 980 MB still in use with 0 opened pages. And the about:memory shows resident memory 1 125 MB.
Thanks for reporting this bug, Michal. Are you watching any YouTube videos? The problem you describe sounds a lot like bug 1190530 and bug 1190019, which are related to playing videos.
Attached file memory-report.json.gz
You're welcome. I'm very interested in e10s project. Great work. 

Yes, I saw at least 50 videos on youtube. However I tested the use cases of the mentioned bugs and I can't say it is the same. I have 0 ghost-windows. Maybe the reason is e10s active, I don't know. I attached measure of memory to check it from your side.
Additional strange thing is that memory measure shows 849.91 MB ── resident, but the task manager of OS X says Nightly consumes 1.5 GB. Normally the values should be equal +/- some MB, shouldn't be?
It looks like bug 1190530 and bug 1190019 landed today. Can you try testing in tomorrow's nightly and report back if it still reproduces?
Flags: needinfo?(mkem)
Yes. I'll test it and let you know the results.
Flags: needinfo?(mkem)
I made some tests with Nightly 42.0a1 (2015-08-05). 
I saw at least 20 videos on youtube and the main process of Nightly had ~300 MB. So I thought that problem was solved. Then I visited a few other websites and suddenly I noticed that main process had ~1.1 GB after closing of all windows and waiting some minutes. I had Nightly running for 3 hours. 
I was thinking about what I did to cause the increasing of memory too much. I found only one action, which I did except the browsing and watching youtube - measuring consumed memory via about:memory page. 

I made some tests with the action of measuring consumed memory via about:memory and here are the results:
1. freshly started Nightly, 0 windows, 200 - 250 MB of main process
2. opened 10 tabs, ~360 MB
3. closed the window with 10 tabs, 0 windows opened, ~250 MB
4. opened 10 tabs again, ~360 MB
5. opened new tab about:memory and clicked on "Measure", result: ~450 MB
6. I was curious what happens if I measure the memory repeatedly by clicking on "Measure" more times
7. I clicked 10 times on "Measure" to see what happens. The memory of main process went up with every clicking. I reached 1 GB of consumed memory per main process. 
8. I closed window with opened 11 tabs - 10 tabs of pages, 1 with about:memory
9. I waited 5 mins and the consumed memory was ~500MB.

I guess there is some problem with releasing of memory after the measures of consumed memory. This is probably the reason why I was able to reach 1 GB of main process after 3 hours of using Nightly. I measured the memory a few times during browsing to see if memory is ok or not, so that I was increasing the memory, which was not fully released.

What do you think about it? Do you have the same results?
Can you take a look at this Andrew? It sounds like measuring memory usage is causing us to use lots of memory.
Flags: needinfo?(continuation)
There's also bug 1190258 still open about high memory usage on YouTube.
Component: General → Audio/Video
Product: Firefox → Core
Flags: needinfo?(continuation)
(In reply to Bill McCloskey (:billm) from comment #10)
> Can you take a look at this Andrew? It sounds like measuring memory usage is
> causing us to use lots of memory.

about:memory is just a webpage, so if you repeatedly reload it, it will take a few GC/CC cycles to clear it out. njn made some attempt to reuse stuff, but the memory is still going to go up. Then the memory won't go down all the way because you've probably got some additional fragmentation.
I didn't use youtube for the test, which I described. So we can exclude youtube. 
I used worst case in my test to find out some connection, but if I do measure a few times during 3 hours (not repeatedly) and reach 1 GB, it is strange. The memory should go down, but it didn't. Minimize memory usage executed 5 times during 30 minutes and nothing happened. Memory usage stood still. 
And why if I measure the memory only once, the consumption increased about 90 - 100MB. The page about:memory has nothing except strings and divs/spans. I made only 1 measure with opened 2 windows with one tab, result: increasing of memory from 470M to 622 MB. Page about:memory was closed, but the memory decreased only about 20 MB. It is strange from my point of view.
Component: Audio/Video → about:memory
Product: Core → Toolkit
about:memory's measurements are text. You can copy & paste them instead of taking screen shots.

As Andrew said, about:memory generates a *lot* of DOM nodes to hold all those measurements, and if you hit "measure" repeatedly you're constantly discarding and generating new ones, which spikes memory temporarily. It should go down eventually.

"Minimize memory usage" isn't guaranteed to actually cause memory to go down.

In the memory-report.json.gz file there are 18 ghost windows in the Web Content process. (There are 0 in the Main Process.) This is probably your main problem. Do you have any add-ons enabled? It would be helpful if you could open about:support, click "copy text to clipboard" and then paste it in a comment here.

(There's also some weirdness in window IDs in that report. I filed bug 1192128 for that.)

Thank you.
Flags: needinfo?(mkem)
Whiteboard: [MemShrink]
Hi, I have 4 addons installed, but they are disabled. I disabled them because of testing Nightly e10s and I didn't want them to make some problems. 

I can agree with your statements and understand them, but as you wrote "which spikes memory temporarily. It should go down eventually." The problem is that it doesn't return at least close to the memory usage before. Only one measure increased memory about 150 MB and then only 20 MB was released. The rest was not released even though after 1,5 hours. It is strange. I think 1 or 2 months ago I didn't have this problem. I had consumption around 400 MB after 4 days of running with 40 - 50 pages per days and  executed measure at least twice a day.



Here is the requested output: 


Application Basics
------------------

Name: Firefox
Version: 42.0a1
Build ID: 20150807030210
Update Channel: nightly
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Multiprocess Windows: 1/1 (default: true)
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

Report ID: bp-74306c1d-4d0b-4ed6-934e-1fbb12150806
Submitted: 21 hours ago

Report ID: bp-04cb7230-c47c-4c64-8a13-869cc2150806
Submitted: 21 hours ago

Report ID: bp-c8cf93a0-4958-4985-891a-2f82b2150806
Submitted: 22 hours ago

Report ID: bp-dd66afb6-e9a5-4182-815d-3c1b42150805
Submitted: 2 days ago

All Crash Reports

Extensions
----------

Name: DownThemAll!
Version: 2.0.18.1-signed
Enabled: false
ID: {DDC359D1-844A-42a7-9AA1-88A850A938A8}

Name: Firebug
Version: 2.0.11
Enabled: false
ID: firebug@software.joehewitt.com

Name: Google Translator for Firefox
Version: 2.1.0.5.1
Enabled: false
ID: translator@zoli.bod

Name: uBlock Origin
Version: 1.0.0.0
Enabled: false
ID: uBlock0@raymondhill.net

Graphics
--------

Asynchronous Pan/Zoom: wheel input enabled
Device ID: 0x0166
GPU Accelerated Windows: 1/1 OpenGL (OMTC)
Supports Hardware H264 Decoding: false
Vendor ID: 0x8086
WebGL Renderer: Intel Inc. -- Intel HD Graphics 4000 OpenGL Engine
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: quartz
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 1

Important Modified Preferences
------------------------------

accessibility.blockautorefresh: true
accessibility.browsewithcaret: true
accessibility.typeaheadfind: true
accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 4
browser.download.importedFromSqlite: true
browser.download.useDownloadDir: false
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20150807030210
browser.startup.homepage: about:newtab
browser.startup.homepage_override.buildID: 20150807030210
browser.startup.homepage_override.mstone: 42.0a1
browser.tabs.loadInBackground: false
browser.tabs.remote.autostart: true
browser.urlbar.suggest.searches: true
browser.urlbar.trimURLs: false
browser.urlbar.userMadeSearchSuggestionsChoice: true
dom.apps.reset-permissions: true
dom.mozApps.used: true
extensions.lastAppVersion: 42.0a1
media.gmp-gmpopenh264.enabled: true
media.gmp-gmpopenh264.lastUpdate: 1430162325
media.gmp-gmpopenh264.version: 1.4
media.gmp-manager.buildID: 20150807030210
media.gmp-manager.lastCheck: 1438958776
media.mediasource.webm.enabled: true
network.cookie.cookieBehavior: 3
network.cookie.lifetimePolicy: 2
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1438786841
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.flash: 1
print.print_bgcolor: false
print.print_bgimages: false
print.print_colorspace:
print.print_command:
print.print_downloadfonts: false
print.print_duplex: 1515870810
print.print_evenpages: true
print.print_in_color: true
print.print_margin_bottom: 0.5
print.print_margin_left: 0.5
print.print_margin_right: 0.5
print.print_margin_top: 0.5
print.print_oddpages: true
print.print_orientation: 0
print.print_page_delay: 50
print.print_paper_data: 0
print.print_paper_height: 11.00
print.print_paper_name:
print.print_paper_size_type: 1
print.print_paper_size_unit: 0
print.print_paper_width: 8.50
print.print_plex_name:
print.print_resolution: 1515870810
print.print_resolution_name:
print.print_reversed: false
print.print_scaling: 1.00
print.print_shrink_to_fit: true
print.print_to_file: false
print.print_unwriteable_margin_bottom: 57
print.print_unwriteable_margin_left: 25
print.print_unwriteable_margin_right: 25
print.print_unwriteable_margin_top: 25
print.printer_Canon_MG5200_series__069A8E000000.print_bgcolor: false
print.printer_Canon_MG5200_series__069A8E000000.print_bgimages: false
print.printer_Canon_MG5200_series__069A8E000000.print_duplex: 1515870810
print.printer_Canon_MG5200_series__069A8E000000.print_edge_bottom: 0
print.printer_Canon_MG5200_series__069A8E000000.print_edge_left: 0
print.printer_Canon_MG5200_series__069A8E000000.print_edge_right: 0
print.printer_Canon_MG5200_series__069A8E000000.print_edge_top: 0
print.printer_Canon_MG5200_series__069A8E000000.print_evenpages: true
print.printer_Canon_MG5200_series__069A8E000000.print_footercenter:
print.printer_Canon_MG5200_series__069A8E000000.print_footerleft: &PT
print.printer_Canon_MG5200_series__069A8E000000.print_footerright: &D
print.printer_Canon_MG5200_series__069A8E000000.print_headercenter:
print.printer_Canon_MG5200_series__069A8E000000.print_headerleft: &T
print.printer_Canon_MG5200_series__069A8E000000.print_headerright: &U
print.printer_Canon_MG5200_series__069A8E000000.print_in_color: true
print.printer_Canon_MG5200_series__069A8E000000.print_margin_bottom: 0.5
print.printer_Canon_MG5200_series__069A8E000000.print_margin_left: 0.5
print.printer_Canon_MG5200_series__069A8E000000.print_margin_right: 0.5
print.printer_Canon_MG5200_series__069A8E000000.print_margin_top: 0.5
print.printer_Canon_MG5200_series__069A8E000000.print_oddpages: true
print.printer_Canon_MG5200_series__069A8E000000.print_orientation: 0
print.printer_Canon_MG5200_series__069A8E000000.print_page_delay: 50
print.printer_Canon_MG5200_series__069A8E000000.print_paper_data: 0
print.printer_Canon_MG5200_series__069A8E000000.print_paper_height: 11.00
print.printer_Canon_MG5200_series__069A8E000000.print_paper_name:
print.printer_Canon_MG5200_series__069A8E000000.print_paper_size_type: 1
print.printer_Canon_MG5200_series__069A8E000000.print_paper_size_unit: 0
print.printer_Canon_MG5200_series__069A8E000000.print_paper_width: 8.50
print.printer_Canon_MG5200_series__069A8E000000.print_resolution: 1515870810
print.printer_Canon_MG5200_series__069A8E000000.print_reversed: false
print.printer_Canon_MG5200_series__069A8E000000.print_scaling: 1.00
print.printer_Canon_MG5200_series__069A8E000000.print_shrink_to_fit: true
print.printer_Canon_MG5200_series__069A8E000000.print_to_file: false
print.printer_Canon_MG5200_series__069A8E000000.print_unwriteable_margin_bottom: 57
print.printer_Canon_MG5200_series__069A8E000000.print_unwriteable_margin_left: 25
print.printer_Canon_MG5200_series__069A8E000000.print_unwriteable_margin_right: 25
print.printer_Canon_MG5200_series__069A8E000000.print_unwriteable_margin_top: 25
privacy.clearOnShutdown.downloads: false
privacy.clearOnShutdown.history: false
privacy.clearOnShutdown.offlineApps: true
privacy.cpd.extensions-dta: true
privacy.cpd.offlineApps: true
privacy.cpd.siteSettings: true
privacy.donottrackheader.enabled: true
privacy.sanitize.migrateClearSavedPwdsOnExit: true
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.sanitizeOnShutdown: true
privacy.trackingprotection.pbmode.enabled: true
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1437234352

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.9 Beta
Version in use: 4.10.9 Beta

NSS
Expected minimum version: 3.19.3 Basic ECC
Version in use: 3.19.3 Basic ECC

NSSSMIME
Expected minimum version: 3.19.3 Basic ECC
Version in use: 3.19.3 Basic ECC

NSSSSL
Expected minimum version: 3.19.3 Basic ECC
Version in use: 3.19.3 Basic ECC

NSSUTIL
Expected minimum version: 3.19.3
Version in use: 3.19.3

Experimental Features
---------------------
Flags: needinfo?(mkem)
Attached file memory-report.json.gz
Today's version: 42.0a1 (2015-08-07), uptime: 6 hours, visited 80 pages. ~700 MB per main process consumed. I closed all windows and wait for 20 mins, the memory stayed without any decreasing. The computer was active.
I made only 2 measures today. First when memory rised over 500 MB and second when I created the attached file.
I attached measure.
Hi Michal,
It looks like there is a leak here. However, I also see pages like nytimes.com loaded in the main process. Do you use "New non-e10s window" much?

Andrew, I see a huge heap-unclassified here. Can you maybe post instructions for using DMD?
Flags: needinfo?(mkem)
(In reply to Bill McCloskey (:billm) from comment #17) 
> Andrew, I see a huge heap-unclassified here. Can you maybe post instructions
> for using DMD?

Which report are you talking about Bill? I looked at the most recent one from comment 16 and I don't see nytimes.com and heap-unclassified is only about 24%. I think the other reports are from before the YouTube fixes went in.
Oops. I was looking at the wrong report.

The report in comment 16 doesn't look too bad to me. The explicit number is what we usually look at. 336MB isn't horrible. That's about the same as what I see in my browser right now. It would be better if it were closer to the startup size, but that's hard because of issues like fragmentation.

It does seem a bit strange that resident is 800MB. I don't think it's usually that much higher than explicit. Unfortunately I don't think DMD will catch that.
(In reply to Bill McCloskey (:billm) from comment #17)
> Hi Michal,
> It looks like there is a leak here. However, I also see pages like
> nytimes.com loaded in the main process. Do you use "New non-e10s window"
> much?
> 
> Andrew, I see a huge heap-unclassified here. Can you maybe post instructions
> for using DMD?

I agree with your statement. I used "New non-e10s window" maybe 2 times. But not frequently, because all pages, which I have visited so far works in e10s great.
Flags: needinfo?(mkem)
It is pity, that I didn't attach yesterday's state of memory. I had 1,12 GB memory consumption of "main" process. Maybe I would try to use DMD, but I don't have experience with custom build of firefox on mac.
If you get another memory report, please post it. Don't worry about DMD for now.
tracking-e10s: --- → +
Flags: needinfo?(mkem)
Attached file memory-report.json.gz
Main process of Nightly 42.0a1 (2015-08-11) consumed 1,18 GB after 2 days of uptime. 100% use of e10s. I used a few times private browsing mode.
Flags: needinfo?(mkem)
Attached file memory-report.json.gz
Nightly 43.0a1 (2015-08-16), uptime: 1 day 23:18:58. 1.3 GB consumed per main process of nightly.
475.62 MB (100.0%) -- explicit
├──280.58 MB (58.99%) -- gfx
│  ├──280.38 MB (58.95%) ── heap-textures
Component: about:memory → Graphics
Product: Toolkit → Core
Attached file memory-report.json.gz
I created another test, which could help to identify the problem. 
I have set up about:newtab as homepage. About:newtab contains 12 tiles (top + suggested sites) with previews.

I did the following steps of testing: 
1. Quit Nightly and start the new one again - new window with homepage of "about:newtab" with tiles appears.
2. Close window.
3. Open new window and close window again.
4. Repeat step 3 10-times (Open window, close window)
5. Check consumed memory after 2-3 minutes of inactivity

Here are my results: 
Nightly 43.0a1 (2015-08-21), e10s enabled - begin: 220 MB, peak: 620 MB, 2 mins later: 530 MB
Nightly 43.0a1 (2015-08-21), e10s disabled - begin: 220 MB, peak: 350 MB, 2 mins later: 260 MB
Firefox 41b3 - begin: 180 MB, peak: 400 MB, 2 mins later: 240 MB

The conclusion is pretty obvious. If I disable e10s the results are ok and they are similar to normal Firefox, but if I have e10s enabled, something goes wrong with memory. The memory was not released even after 5 minutes, still around 530 MB. 

I close and reopen window of Nightly many times per day, because it is normal to close window if you don’t need it and reopen it if you want to look at some page. So maybe it could be source of the problem. I attached measurement of Nightly's memory consumption.
Attached file memory-report.json.gz
Nightly 43.0a1 (2015-08-24) uptime: 01 day 21:16:46, ~1 GB per main process consumed.
From the latest report:

> 369.17 MB (100.0%) -- explicit
>  996.50 MB ── resident

When "explicit" and "resident" differ significantly it's because there are large non-heap allocations that we're not tracking, and those are usually graphics-related. Combine that with this:

> ├──160.47 MB (43.47%) -- gfx
> │  ├──160.27 MB (43.41%) ── heap-textures

and it definitely looks graphics-related. There are probably allocations beyond these tracked ones that we're not measuring.
Thank you for the update. Should I keep posting the memory measurements or is it enough?
I think it's enough for now, thank you. We need a graphics person to take a look.
Whiteboard: [MemShrink] → [MemShrink:P1]
Michal, do you have this problem still?

Which version of Firefox do you use at the moment?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mkem)
Summary: [e10s] Nightly "main" process eats a lot of memory and the amount of memory continuously rises with daily browsing → [e10s] (MacOSX) Nightly (FF42.0a1) main process use a lot of memory and the amount of memory continuously rises with daily browsing
See Also: → 1228615
Hello, yes. The problem persists. Only "change" I noticed is, that the memory consumption per main process rises a little bit slower than before. 
Currently I'm using the version 45.0a1 (2015-11-23) without any activated addons. 

Actual state: uptime 4 days, 1.5 GB per "main" process.
Flags: needinfo?(mkem)
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID 	20160205004003


Tested this on Mac OS X 10.10 with Firefox 46.0a2 and I can't reproduce it with the steps from comment 27. My memory consumption is:       
e10s enabled begin:  220MB  peak: 280MB  2 minutes later: 280MB 
e10s disabled begin: 310MB  peak: 347MB  2 minutes later: 344MB
Could you please try it with latest Nightly - 47.0a1 (2016-02-05) 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0

I have same results as in comment 27.
I have tested on Mac OS X 10.11 with Firefox Nightly 47.0a1(2016-02-07):

e10s enabled begin:  220MB  peak: 580MB  2 minutes later: 560MB 
e10s disabled begin: 230MB  peak: 525MB  2 minutes later: 514MB
(In reply to ovidiu boca from comment #36)
> I have tested on Mac OS X 10.11 with Firefox Nightly 47.0a1(2016-02-07):
> 
> e10s enabled begin:  220MB  peak: 580MB  2 minutes later: 560MB 
> e10s disabled begin: 230MB  peak: 525MB  2 minutes later: 514MB

At least you reached similar result as me with e10s enabled in Nightly. If you compare the results with your previous test, it is definetely difference. I think the problem is somehow related to "Nightly" channel, because I tested the latest beta of Firefox with e10s enabled and the memory consumption was around 350 MB after 4 days of running.
Anyway it is very suspicious to have 560 MB per main process with 0 windows opened.
Flags: needinfo?(jmathies)
All the reports here point to memory accumulation in gfx in the main process over long run times (2 days or so). Milan, what would you like to do with this, we need to decide if discovery work here should block e10s.
Flags: needinfo?(jmathies) → needinfo?(milan)
The problem was observed only in Nightly channel before, but now I see it also in current beta channel - 46.0b4. 
Uptime 1 day 18 hours - Explicit: 380 MB, Resident: 900 MB per "Main" process.
Do you see if on the *latest* nightly?  I'm thinking bug 1255448 (landed March 15) may have improved, if not resolved this.
Flags: needinfo?(milan) → needinfo?(mkem)
The problem is still there. I tested Nightly 48.0a1 (2016-03-25): 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0

The problem is that beta 45 didn't suffer of this problem, but beta 46 already yes. 

If I repeat the STRs from my Comment 27, I reach only 500 MB per "Main process", so the memory consumption is less than before, but still to much.
Flags: needinfo?(mkem)
Right, this is more about raising day by day, rather than the amount being used, but I suppose that may take a few days to verify.
(In reply to Milan Sreckovic [:milan] from comment #42)
> Right, this is more about raising day by day, rather than the amount being
> used, but I suppose that may take a few days to verify.

Shoud I continue with the testing latest Nightly?
(In reply to Milan Sreckovic [:milan] from comment #40)
> Do you see if on the *latest* nightly?  I'm thinking bug 1255448 (landed
> March 15) may have improved, if not resolved this.

I tested daily browsing with Nightly 48.0a1 (2016-03-26) and reach 1.1 GB per main process after 9 hours. So the problem is still persist. I attached the memory report from today - 20160327. 

If I check the https://telemetry.mozilla.org/ and set up "memory_resident_fast" for Nightly 48 64-bit e10s main process, I see that median is ~800 MB, so it definetely shows some problem with memory especially if you compare it with beta 46, which has median 363 MB.
Assignee: nobody → bgirard
Priority: -- → P1
Actual beta 46.0b5 is affected with this problem too. 45.0beta wasn't. I attached measure of memory after uptime 2 days 21:26:58
(In reply to Michal K from comment #46)
> Created attachment 8736351 [details]
> memory-report-46.0b5.json.gz
> 
> Actual beta 46.0b5 is affected with this problem too. 45.0beta wasn't. I
> attached measure of memory after uptime 2 days 21:26:58

Similar results to before:

> 453.19 MB (100.0%) -- explicit
> ├──219.80 MB (48.50%) -- gfx
> │  ├──219.63 MB (48.46%) ── heap-textures
> │  └────0.17 MB (00.04%) ++ (4 tiny)
> ├───86.34 MB (19.05%) ── heap-unclassified
> 
>   950.75 MB ── resident
> 1,542.00 MB ── resident-peak
>   485.30 MB ── resident-unique

"gfx/heap-textures" is high. "resident" is more than double "explicit". "resident-unique" is a lot lower than "resident", which is surprising but I'm not sure what to make of it.
This has been shipped in 4 releases now. Are we making any progress on this issue? Mikel, does it still affect the current Firefox versions (release, beta, aurora, and nightly)?
Whiteboard: [MemShrink:P1] → [MemShrink:P1] gfx-noted
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #48)
> This has been shipped in 4 releases now. Are we making any progress on this
> issue? Mikel, does it still affect the current Firefox versions (release,
> beta, aurora, and nightly)?

Actual Nightly 49.0a1 doesn't suffer of this bug, see my comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1264161#c45

Currently I'm testing the latest beta 47.0b2 to find out if the bugfix of bug 1264161 resolves this one.
Attached file memory-report.json.gz
Finally this bug is fixed, resolved. The uplift of bug 1264161 fixed this bug. See my comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1264161#c56

Thank you very much for your efforts and I wish you good luck in approaching to final release.
Thanks for your report.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1264161
You need to log in before you can comment on or make changes to this bug.