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

Status: RESOLVED DUPLICATE of bug 1264161

(Core :: Graphics, defect, P1)

Description

[Michal K]

Attachment: Reported resident memory of main process

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.

Comment 1

[Michal K]

Attachment: Resident memory of Web Content process

Comment 2

[Michal K]

Attachment: Memory reported in Task Manager

Comment 3

[Michal K]

Attachment: Memory consumption after minimizing of memory usage

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.

Comment 4

[Chris Peterson [:cpeterson]]

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.

Comment 5

[Michal K]

Attachment: 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.

Comment 6

[Michal K]

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?

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

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?

Comment 8

[Michal K]

Yes. I'll test it and let you know the results.

Comment 9

[Michal K]

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?

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Can you take a look at this Andrew? It sounds like measuring memory usage is causing us to use lots of memory.

Comment 11

[Andrew McCreight [:mccr8]]

There's also bug 1190258 still open about high memory usage on YouTube.

Comment 12

[Andrew McCreight [:mccr8]]

(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.

Comment 13

[Michal K]

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.

Comment 14

[Nicholas Nethercote [inactive]]

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.

Comment 15

[Michal K]

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: [e-mail]

Name: Google Translator for Firefox
Version: 2.1.0.5.1
Enabled: false
ID: [e-mail]

Name: uBlock Origin
Version: 1.0.0.0
Enabled: false
ID: [e-mail]

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
---------------------

Comment 16

[Michal K]

Attachment: 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.

Comment 17

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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?

Comment 18

[Andrew McCreight [:mccr8]]

(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.

Comment 19

[Nicholas Nethercote [inactive]]

> Can you maybe post instructions for using DMD?

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD

Comment 20

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 21

[Michal K]

(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.

Comment 22

[Michal K]

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.

Comment 23

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

If you get another memory report, please post it. Don't worry about DMD for now.

Comment 24

[Michal K]

Attachment: 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.

Comment 25

[Michal K]

Attachment: 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.

Comment 26

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

475.62 MB (100.0%) -- explicit
├──280.58 MB (58.99%) -- gfx
│  ├──280.38 MB (58.95%) ── heap-textures

Comment 27

[Michal K]

Attachment: 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.

Comment 28

[Michal K]

Attachment: memory-report.json.gz

Nightly 43.0a1 (2015-08-24) uptime: 01 day 21:16:46, ~1 GB per main process consumed.

Comment 29

[Nicholas Nethercote [inactive]]

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.

Comment 30

[Michal K]

Thank you for the update. Should I keep posting the memory measurements or is it enough?

Comment 31

[Nicholas Nethercote [inactive]]

I think it's enough for now, thank you. We need a graphics person to take a look.

Comment 32

[Tobias B. Besemer [:BesTo] (QA)]

Michal, do you have this problem still?

Which version of Firefox do you use at the moment?

Comment 33

[Michal K]

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.

Comment 34

[ovidiu boca[:Ovidiu]]

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

Comment 35

[Michal K]

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.

Comment 36

[ovidiu boca[:Ovidiu]]

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

Comment 37

[Michal K]

(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.

Comment 38

[Jim Mathies [:jimm]]

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.

Comment 39

[Michal K]

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.

Comment 40

[Milan Sreckovic [:milan] (needinfo for best results)]

Do you see if on the *latest* nightly?  I'm thinking bug 1255448 (landed March 15) may have improved, if not resolved this.

Comment 41

[Michal K]

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.

Comment 42

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 43

[Michal K]

(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?

Comment 44

[Michal K]

(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.

Comment 45

[Michal K]

Attachment: 20160327-memory measure

Comment 46

[Michal K]

Attachment: 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

Comment 47

[Nicholas Nethercote [inactive]]

(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.

Comment 48

[u279076]

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)?

Comment 49

[Michal K]

(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.

Comment 50

[Michal K]

Attachment: 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.

Comment 51

[Andrew McCreight [:mccr8]]

Thanks for your report.