814899 - Leaving facebook open causes arbitrarily large memory usage

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect)

Description

[Damian Shaw [Quan]]

Attachment: memory profile of experience high memory usage from facebook vs. 30 other tabs open

Steps to reproduce:

1. Open up facebook and sign in, (I make pinned tab)
2. Leave browser open for 3 - 6 days
3. Notice very high memory usage
4. Performance deteriorates (during the time looking at memory in task manager it's jumping up and down very fast, going up 200 MB in 30 seconds and then dropping immediately)
5. Firefox freezes and has to be killed from task manager at 2 GB of RAM 

I can reproduce both with a clean profile and no add-ons and also with add-ons that help reduce memory (e.g. adblock). Only prevention is to notice beforehand and kill facebook tab and then reopen. Is there some kind of memory profile too I can use to work out what exactly is causing this? Currently all I have is about:memory

1,534,995,337 B (100.0%) -- explicit
├──1,000,505,792 B (65.18%) -- window-objects
│  ├────297,543,442 B (19.38%) -- top(http://www.facebook.com/, id=15)/active
│  │    ├──295,893,562 B (19.28%) -- window(http://www.facebook.com/)
│  │    │  ├──220,087,322 B (14.34%) -- js
│  │    │  │  ├──219,771,074 B (14.32%) -- compartment(http://www.facebook.com/)
│  │    │  │  │  ├───96,673,792 B (06.30%) ++ gc-heap
│  │    │  │  │  ├───87,865,200 B (05.72%) ++ objects-extra
│  │    │  │  │  ├───20,889,986 B (01.36%) ++ string-chars
│  │    │  │  │  ├───10,242,048 B (00.67%) ++ shapes-extra
│  │    │  │  │  ├────2,980,896 B (00.19%) ── script-data
│  │    │  │  │  ├──────586,784 B (00.04%) ++ type-inference
│  │    │  │  │  ├──────467,936 B (00.03%) ── analysis-temporary
│  │    │  │  │  ├───────32,928 B (00.00%) ── jaeger-data
│  │    │  │  │  ├───────18,144 B (00.00%) ── ion-data
│  │    │  │  │  ├────────8,192 B (00.00%) ── regexp-compartment
│  │    │  │  │  └────────5,168 B (00.00%) ── other-sundries
│  │    │  │  └──────316,248 B (00.02%) ++ compartment(http://www.facebook.com/, NoScript::ScriptSurrogate@http://www.facebook.com/ (from: chrome://noscript/content/ScriptSurrogate.js:244))
│  │    │  ├───65,327,736 B (04.26%) ++ dom
│  │    │  ├────6,481,456 B (00.42%) ++ layout
│  │    │  ├────3,208,184 B (00.21%) ── style-sheets
│  │    │  └──────788,864 B (00.05%) ── property-tables
│  │    └────1,649,880 B (00.11%) ++ window(http://www.facebook.com/****************
│  ├─────72,255,272 B (04.71%) -- top(none)
│  │     ├──69,942,008 B (04.56%) ++ detached
│  │     └───2,313,264 B (00.15%) ++ ghost/window(https://4lam9a1ki27mb9p1h5q3furvvf58ss02-a-gm-opensocial.googleusercontent.com/gadgets/ifr?url=http%3A%2F%2Fwww.gstatic.com%2Fig%2Fmodules%2Fgm%2Fgmaps%2Fcard-gmaps.xml&container=gm&view=card&lang=en-gb&country=CH&sanitize=0&v=22637a3903cdfc88&libs=core%3Adynamic-height%3Aflash%3Agoogle.contentmatch%3Agoogle.debug%3Agoogle.sharebox%3Agoogle.waitforload%3Alocked-domain%3Aoauthpopup%3Arpc%3Asecurity-token%3Asetprefs%3Askins%3Aviews%3Aauth-refresh&parent=https%3A%2F%2Fmail.google.com%2Fhtml&skintype=gm&skinval=GM_BG_COLOR%3A%23F2F2F2%3BGM_TEXT_COLOR%3A%23222%3BGM_LINK_COLOR%3A%2315c%3BGM_SELECTED_BG_COLOR%3A%23ffc%3BGM_SELECTED_TEXT_COLOR%3A%23222%3BGM_SELECTED_LINK_COLOR%3A%23222%3BGM_MENU_BORDER_COLOR%3A%23888%3BGM_MENU_BG_COLOR%3A%23fff%3BGM_MENU_TEXT_COLOR%3A%23333%3BGM_MENU_LINK_COLOR%3A%230065cc#c=gm&rpctoken=afx6p853u71s&cob=%257B%2522GOOGLE_ADDRESS_EXTRACTOR%2522%253A%255B%257B%2522address%2522%253A%25221355%2520Market%2520St%255CnSan%2520Francisco%252C%2520CA%252094103%2522%257D%255D%257D&mid=2&st=e%3DAA6WCYYGzyzY3s82iqtu5j5QlKatJKT3Y82ehgsGeBAgLT6a1XvJM33xETgmYPc4FXkd82ycHpAMMrQ1yhCWpiyKqHXkbr5Mtci1OZVxo1yU9vJn3w7OH2l7wcOTQcsrl26ryaHImENy%26c%3Dgm)
│  ├─────63,120,128 B (04.11%) -- top(https://mail.google.com/mail/u/0/?shva=1#inbox, id=19)/active

Comment 1

[Damian Shaw [Quan]]

Adding memshrink because of obvious memory implications, adding snappy because performance crawls to a halt when trying to interact with the UI or other websites or Flash.

Again, I can reproduce this on a clean profile with no addons on nightly builds, but don't know how to help analyse it further. I'm 90% confident I can reproduce this without looking at facebooks photo viewer as well.

Comment 2

[Justin Lebar (not reading bugmail)]

This looks like a bug in Facebook.

Kev, who's our contact there?

Comment 3

[Damian Shaw [Quan]]

Are you sure it's facebook that's causing the problem? It's always the gc-heap that's the biggest issue, in face in my latest reproduce it's particularly "unused-gc-things" that stands out ahead of everything else:

2,100,319,833 B (100.0%) -- explicit
+--1,598,725,494 B (76.12%) -- window-objects
¦  +----730,719,828 B (34.79%) -- top(http://www.facebook.com/, id=3764)/active
¦  ¦    +--729,073,548 B (34.71%) -- window(http://www.facebook.com/)
¦  ¦    ¦  +--682,919,844 B (32.52%) -- js
¦  ¦    ¦  ¦  +--682,695,868 B (32.50%) -- compartment(http://www.facebook.com/)
¦  ¦    ¦  ¦  ¦  +--584,134,656 B (27.81%) -- gc-heap
¦  ¦    ¦  ¦  ¦  ¦  +--491,179,560 B (23.39%) -- unused-gc-things
¦  ¦    ¦  ¦  ¦  ¦  +---80,317,264 B (03.82%) -- objects
¦  ¦    ¦  ¦  ¦  ¦  ¦   +--50,523,712 B (02.41%) -- ordinary
¦  ¦    ¦  ¦  ¦  ¦  ¦   +--25,469,984 B (01.21%) -- function
¦  ¦    ¦  ¦  ¦  ¦  ¦   +---4,300,944 B (00.20%) -- dense-array
¦  ¦    ¦  ¦  ¦  ¦  ¦   +------22,624 B (00.00%) -- slow-array
¦  ¦    ¦  ¦  ¦  ¦  +----5,854,184 B (00.28%) -- shapes
¦  ¦    ¦  ¦  ¦  ¦  ¦    +--2,807,744 B (00.13%) -- base
¦  ¦    ¦  ¦  ¦  ¦  ¦    +--2,044,848 B (00.10%) -- dict
¦  ¦    ¦  ¦  ¦  ¦  ¦    +--1,001,592 B (00.05%) -- tree
¦  ¦    ¦  ¦  ¦  ¦  ¦       +----992,712 B (00.05%) -- global-parented
¦  ¦    ¦  ¦  ¦  ¦  ¦       +------8,880 B (00.00%) -- non-global-parented
¦  ¦    ¦  ¦  ¦  ¦  +----2,976,368 B (00.14%) -- arena-admin
¦  ¦    ¦  ¦  ¦  ¦  +----2,341,168 B (00.11%) -- strings
¦  ¦    ¦  ¦  ¦  ¦  ¦    +--1,628,304 B (00.08%) -- normal
¦  ¦    ¦  ¦  ¦  ¦  ¦    +----712,864 B (00.03%) -- short
¦  ¦    ¦  ¦  ¦  ¦  +------983,280 B (00.05%) -- scripts
¦  ¦    ¦  ¦  ¦  ¦  +------481,920 B (00.02%) -- type-objects
¦  ¦    ¦  ¦  ¦  ¦  +----------912 B (00.00%) -- sundries
¦  ¦    ¦  ¦  ¦  +---58,713,136 B (02.80%) -- objects-extra
¦  ¦    ¦  ¦  ¦  ¦   +--50,829,296 B (02.42%) -- elements
¦  ¦    ¦  ¦  ¦  ¦   +---7,883,840 B (00.38%) -- slots
¦  ¦    ¦  ¦  ¦  +---25,208,700 B (01.20%) -- string-chars
¦  ¦    ¦  ¦  ¦  ¦   +--18,022,400 B (00.86%) -- huge
¦  ¦    ¦  ¦  ¦  ¦   +---7,186,300 B (00.34%) -- non-huge
¦  ¦    ¦  ¦  ¦  +---11,100,896 B (00.53%) -- shapes-extra
¦  ¦    ¦  ¦  ¦  ¦   +---5,703,904 B (00.27%) -- dict-tables
¦  ¦    ¦  ¦  ¦  ¦   +---4,122,816 B (00.20%) -- tree-tables
¦  ¦    ¦  ¦  ¦  ¦   +---1,089,792 B (00.05%) -- compartment-tables
¦  ¦    ¦  ¦  ¦  ¦   +-----184,384 B (00.01%) -- tree-shape-kids
¦  ¦    ¦  ¦  ¦  +----2,411,584 B (00.11%) -- script-data
¦  ¦    ¦  ¦  ¦  +----1,072,320 B (00.05%) -- type-inference
¦  ¦    ¦  ¦  ¦  ¦    +----393,216 B (00.02%) -- type-pool
¦  ¦    ¦  ¦  ¦  ¦    +----318,624 B (00.02%) -- type-scripts
¦  ¦    ¦  ¦  ¦  ¦    +----262,144 B (00.01%) -- analysis-pool
¦  ¦    ¦  ¦  ¦  ¦    +-----98,336 B (00.00%) -- allocation-site-tables
¦  ¦    ¦  ¦  ¦  +-------32,928 B (00.00%) -- jaeger-data
¦  ¦    ¦  ¦  ¦  +-------13,456 B (00.00%) -- other-sundries
¦  ¦    ¦  ¦  ¦  +--------8,192 B (00.00%) -- regexp-compartment
¦  ¦    ¦  ¦  +------223,976 B (00.01%) -- compartment(http://www.facebook.com/, NoScript::ScriptSurrogate@http://www.facebook.com/ (from: chrome://noscript/content/ScriptSurrogate.js:244))
¦  ¦    ¦  ¦         +--126,976 B (00.01%) -- gc-heap
¦  ¦    ¦  ¦         ¦  +---78,664 B (00.00%) -- unused-gc-things
¦  ¦    ¦  ¦         ¦  +---17,880 B (00.00%) -- sundries
¦  ¦    ¦  ¦         ¦  +---17,328 B (00.00%) -- objects/function
¦  ¦    ¦  ¦         ¦  +---13,104 B (00.00%) -- shapes/tree/global-parented
¦  ¦    ¦  ¦         +---36,960 B (00.00%) -- string-chars/non-huge
¦  ¦    ¦  ¦         +---32,768 B (00.00%) -- type-inference/analysis-pool
¦  ¦    ¦  ¦         +----9,544 B (00.00%) -- other-sundries
¦  ¦    ¦  ¦         +----9,024 B (00.00%) -- objects-extra/slots
¦  ¦    ¦  ¦         +----8,704 B (00.00%) -- shapes-extra/compartment-tables
¦  ¦    ¦  +---35,716,328 B (01.70%) -- dom
¦  ¦    ¦  ¦   +--31,901,872 B (01.52%) -- orphan-nodes
¦  ¦    ¦  ¦   +---2,984,756 B (00.14%) -- element-nodes
¦  ¦    ¦  ¦   +-----462,912 B (00.02%) -- other [2]
¦  ¦    ¦  ¦   +-----366,788 B (00.02%) -- text-nodes
¦  ¦    ¦  +----6,146,752 B (00.29%) -- layout
¦  ¦    ¦  ¦    +--3,438,976 B (00.16%) -- style-sets
¦  ¦    ¦  ¦    +----840,976 B (00.04%) -- pres-shell
¦  ¦    ¦  ¦    +----783,304 B (00.04%) -- frames
¦  ¦    ¦  ¦    ¦    +--248,160 B (00.01%) -- nsBlockFrame
¦  ¦    ¦  ¦    ¦    +--147,920 B (00.01%) -- nsInlineFrame
¦  ¦    ¦  ¦    ¦    +--135,280 B (00.01%) -- nsTextFrame
¦  ¦    ¦  ¦    ¦    +---58,464 B (00.00%) -- nsHTMLScrollFrame
¦  ¦    ¦  ¦    ¦    +---35,840 B (00.00%) -- nsPlaceholderFrame
¦  ¦    ¦  ¦    ¦    +---29,568 B (00.00%) -- nsImageFrame
¦  ¦    ¦  ¦    ¦    +---22,504 B (00.00%) -- sundries
¦  ¦    ¦  ¦    ¦    +---15,696 B (00.00%) -- nsTableFrame
¦  ¦    ¦  ¦    ¦    +---15,224 B (00.00%) -- nsContinuingTextFrame
¦  ¦    ¦  ¦    ¦    +---12,544 B (00.00%) -- nsTableColFrame
¦  ¦    ¦  ¦    ¦    +---12,208 B (00.00%) -- nsTableRowFrame
¦  ¦    ¦  ¦    ¦    +---10,848 B (00.00%) -- nsBulletFrame
¦  ¦    ¦  ¦    ¦    +---10,272 B (00.00%) -- nsTableCellFrame
¦  ¦    ¦  ¦    ¦    +----9,592 B (00.00%) -- nsTableColGroupFrame
¦  ¦    ¦  ¦    ¦    +----9,592 B (00.00%) -- nsTableOuterFrame
¦  ¦    ¦  ¦    ¦    +----9,592 B (00.00%) -- nsTableRowGroupFrame
¦  ¦    ¦  ¦    +----430,592 B (00.02%) -- pres-contexts
¦  ¦    ¦  ¦    +----270,952 B (00.01%) -- style-contexts
¦  ¦    ¦  ¦    +----203,200 B (00.01%) -- rule-nodes
¦  ¦    ¦  ¦    +----172,368 B (00.01%) -- line-boxes
¦  ¦    ¦  ¦    +------6,384 B (00.00%) -- text-runs
¦  ¦    ¦  +----3,503,168 B (00.17%) -- style-sheets
¦  ¦    ¦  +------787,456 B (00.04%) -- property-tables

Comment 4

[Justin Lebar (not reading bugmail)]

> It's always the gc-heap that's the biggest issue, in face in my latest reproduce it's 
> particularly "unused-gc-things" that stands out ahead of everything else

Hm.  That's fragmentation in our GC heap.  Traditionally, we say basically can't fix that without a compacting GC (bug 619558).  But that is a lot of fragmentation.  Maybe we're allocating objects into arenas sub-optimally.

Comment 5

[Justin Lebar (not reading bugmail)]

Gregor, do we commonly see fragmentation exceeding used space by more than a factor of 5?

> ¦  ¦    ¦  ¦  ¦  +--584,134,656 B (27.81%) -- gc-heap
> ¦  ¦    ¦  ¦  ¦  ¦  +--491,179,560 B (23.39%) -- unused-gc-things
> ¦  ¦    ¦  ¦  ¦  ¦  +---80,317,264 B (03.82%) -- objects

Do you think something interesting might be going on here on our end?

Comment 6

[Gregor Wagner [:gwagner]]

(In reply to Justin Lebar [:jlebar] from comment #5)
> Gregor, do we commonly see fragmentation exceeding used space by more than a
> factor of 5?
> 
> > ¦  ¦    ¦  ¦  ¦  +--584,134,656 B (27.81%) -- gc-heap
> > ¦  ¦    ¦  ¦  ¦  ¦  +--491,179,560 B (23.39%) -- unused-gc-things
> > ¦  ¦    ¦  ¦  ¦  ¦  +---80,317,264 B (03.82%) -- objects
> 
> Do you think something interesting might be going on here on our end?

I also noticed a bigger JS heap today. After closing all tabs and minimizing I still had around 80MB. Do we see any regression on areweslimyet?

Comment 7

[Justin Lebar (not reading bugmail)]

> Do we see any regression on areweslimyet?

Not really, no.

Comment 8

[Gregor Wagner [:gwagner]]

Bill, did we change any GC code that might be related?

Comment 9

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

Do we know if this is a regression? Damian, is there any chance that you could try an older version of Firefox? Also, did you use your tests using a current nightly? If so, it would be helpful to try FF17 and see if it has the same problem.

Comment 10

[Damian Shaw [Quan]]

Yeah sure, this typically takes me 3 days to reproduce and I often need to restart to get reasonable performance again, so the nightly builds I've been testing on are no older than 1 week from the dates I've posted.

I first started noticing the performance regression a few months ago, so I'll try running a few versions of Firefox in parallel with completely clean profiles and just Facebook left open. Will check-in with the results next week.

Comment 11

[Damian Shaw [Quan]]

This became much harder to reproduce shortly after posting this. I'm going to try once more with some clean VMs and a few different versions of Firefox, but otherwise will change status to WORKSFORME.

Comment 12

[Damian Shaw [Quan]]

I have been unable to reproduce this in the same way for quite sometime [though still have regular >2GB memory problems don't see the same wild memory fluctuations or direct link to FB]. 

Can only conclude a mix of FB improvements and FF improvements have resolved the issue.

Thanks all for taking note, I'll get all details requested and file a new bug if I see issue again.