962943 - Memory usage is extremely high (2.2 GB after half a day)

Status: RESOLVED WONTFIX

(Firefox :: Untriaged, defect)

Description

[florin arjocu]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131206145143

Steps to reproduce:

My report is not necessary a bug report, more like a proposal:

Using Firefox for let's say half a day with no pause (browsing, youtube-ing, gmail + facebook). In total, about 12-15 open tabs.


Actual results:

Firefox got to an incredible memory usage of 2.2 GB. I think this is way too much I would like to allocate  to my browser. My computer has 4 GB of memory, the OS needs some of it and I would also like to do something else on the computer while browsing.


Expected results:

At some point the browser should clean memory. Facebook in special. Using FB in an intensive way (lots of friends, large lists/groups activity, lots of chats, messages, etc.) makes it reach an extreme memory usage. It should not be allowed to do that.

After blocking Facebook from being so hungry, another proposal would be to implement some function similar (but better working) than "The Great Suspender" extension for Chrome. A good way is to allow user to set a maximum time an unused tab would be active, and if it is inactive, it should release all its resources. Just like Firefox starts with many tabs, but without content; load it when pressing a button or when switching to that inactive tab.

Comment 1

[Loic]

We need some memory logs, type about:memory and save the log (there is a button for that) when memory use is high and join the log to the bug report.

Comment 2

[florin arjocu]

Will do that very soon. I'll be back with logs.

Comment 3

[florin arjocu]

Attachment: memory report firefox 26-01-2013

I have used Firefox today for half a day or more. I was almost ok for a while, but in the last 4 hours I got to 1.3 GB and using more Facebook now I use 1.8 GB of memory. The system creates swap file which makes the OS a lot slower.
I have also made a screenshot with the resource usage sorted by memory: http://goo.gl/ObVP9j

BTW, another thing that is very important for users. Many say Chrome is snappier, responsive. They are quite right, changing tabs is slow, FF is not that responsive as Chrome, although it might use the same memory amount as combining chrome processes together.

Comment 4

[Nicholas Nethercote [inactive]]

Florin: please follow the steps from comment 1. We need data from about:memory (use the "Measure and Save..." button) to make any progress here. That will give us *much* more data than the System Monitor.

Comment 5

[florin arjocu]

Attachment: memory report 2.4 GB memory 26-01-2014.json.gz

Just wait. Less than half an hour later, more Facebook and 1-2 more tabs, here you have 2.4 - 2.5 GB of memory used by Firefox. Another screenshot here: http://goo.gl/1Dfg4U

Comment 6

[florin arjocu]

@Nicholas Nethercote - I have attached 2 files, one for each comment. You probably have missed them :)

Comment 7

[florin arjocu]

It might help you to debug and find a partial solution: I am sure that Facebook tab was consuming 1GB of memory alone. Closing the FB tab consumed some processor resources, but in a few seconds (10-15), the memory usage dropped from 2.3-2.4 GB to 1.3 GB. I have saved memory log; if you need this one without facebook tab, just say.

It is not the complete solution, but I would not allow pages to "eat as much as they want". Also, something as I said in the bug report should work very good for all users (something similar but better that "The Great Suspender" plugin from Chrome).

BTW: I use Ad Block Plus addon; if I had all ads the memory usage would be larger.

Comment 8

[Nicholas Nethercote [inactive]]

Indeed, I missed them. Sorry!

Here's the important stuff from the second attachment:

2,406.70 MB (100.0%) -- explicit
├──1,722.49 MB (71.57%) -- window-objects
│  ├──1,062.06 MB (44.13%) -- top(https://www.facebook.com/pistol.luminita?fref=ts, id=2750)
│  │  ├──1,001.95 MB (41.63%) -- active
│  │  │  ├──1,001.82 MB (41.63%) -- window(https://www.facebook.com/pistol.luminita?fref=ts)
│  │  │  │  ├────500.59 MB (20.80%) -- js-compartment(https://www.facebook.com/settings/?tab=applications)
│  │  │  │  │    ├──350.09 MB (14.55%) -- objects
│  │  │  │  │    │  ├──285.37 MB (11.86%) ++ gc-heap
│  │  │  │  │    │  ├───64.71 MB (02.69%) ++ malloc-heap
│  │  │  │  │    │  └────0.00 MB (00.00%) ── non-heap/code/asm.js
│  │  │  │  │    ├───86.79 MB (03.61%) ++ shapes
│  │  │  │  │    ├───58.85 MB (02.45%) ++ scripts
│  │  │  │  │    └────4.86 MB (00.20%) ++ (3 tiny)
│  │  │  │  ├────478.83 MB (19.90%) -- dom
│  │  │  │  │    ├──467.71 MB (19.43%) ── orphan-nodes
│  │  │  │  │    └───11.12 MB (00.46%) ++ (5 tiny)
│  │  │  │  └─────22.40 MB (00.93%) ++ (3 tiny)
│  │  │  └──────0.13 MB (00.01%) ++ window(https://www.facebook.com/ai.php?aed=AQJpvd5XVFB0iDJnOXZB4I7oZfMvD-Py0LItrEI82jdWf1T

So yes, it's mostly Facebook. The "orphan-nodes" number is very high, which indicates that the page is churning through DOM nodes.

Here's the important stuff from the diff between the first and second attachments:

588.51 MB (100.0%) -- explicit
├──496.90 MB (84.43%) -- window-objects
│  ├──1,062.06 MB (180.47%) -- top(https://www.facebook.com/pistol.luminita?fref=ts, id=2750)
│  │  ├──1,001.95 MB (170.25%) -- active
│  │  │  ├──1,001.82 MB (170.23%) -- window(https://www.facebook.com/pistol.luminita?fref=ts)
│  │  │  │  ├────500.59 MB (85.06%) ++ js-compartment(https://www.facebook.com/settings/?tab=applications)
│  │  │  │  ├────478.83 MB (81.36%) ++ dom
│  │  │  │  ├─────10.97 MB (01.86%) ++ layout
│  │  │  │  ├──────8.42 MB (01.43%) ── style-sheets [+]
│  │  │  │  └──────3.01 MB (00.51%) ── property-tables [+]
│  │  │  └──────0.13 MB (00.02%) ++ window(https://www.facebook.com/ai.php?aed=AQJpvd5X...)
│  │  └─────60.11 MB (10.21%) -- js-zone(0xNNN)
│  │        ├──30.77 MB (05.23%) -- strings
│  │        │  ├──16.81 MB (02.86%) ++ notable
│  │        │  ├───9.03 MB (01.53%) ── short/gc-heap
│  │        │  └───4.93 MB (00.84%) ++ normal
│  │        ├──18.11 MB (03.08%) ── unused-gc-things [+]
│  │        ├───6.55 MB (01.11%) ── gc-heap-arena-admin [+]
│  │        └───4.67 MB (00.79%) ++ (4 tiny)
│  └──-565.16 MB (-96.03%) -- (19 tiny)
│     ├──-619.11 MB (-105.20%) -- top(https://www.facebook.com/florin.arjocu, id=2750)
│     │  ├──-574.03 MB (-97.54%) -- active
│     │  │  ├──-573.77 MB (-97.50%) -- window(https://www.facebook.com/florin.arjocu)
│     │  │  │  ├──-281.65 MB (-47.86%) ++ js-compartment(https://www.facebook.com/settings/?tab=applications)
│     │  │  │  ├──-271.12 MB (-46.07%) -- dom
│     │  │  │  │  ├──-259.70 MB (-44.13%) ── orphan-nodes [-]
│     │  │  │  │  ├───-10.63 MB (-1.81%) ── element-nodes [-]
│     │  │  │  │  ├────-0.56 MB (-0.09%) ── text-nodes [-]
│     │  │  │  │  ├────-0.20 MB (-0.03%) ── other [2] [-]
│     │  │  │  │  ├────-0.03 MB (-0.00%) ── event-targets [2] [-]
│     │  │  │  │  └────-0.00 MB (-0.00%) ── comment-nodes [-]
│     │  │  │  ├───-10.39 MB (-1.77%) ++ layout
│     │  │  │  ├────-8.35 MB (-1.42%) ── style-sheets [-]
│     │  │  │  └────-2.26 MB (-0.38%) ── property-tables [-]
│     │  │  ├────-0.13 MB (-0.02%) ++ window(https://www.facebook.com/ai.php?aed=AQJ1qjcsyKIN_...)
│     │  │  └────-0.13 MB (-0.02%) ++ window(https://www.facebook.com/ai.php?aed=AQL0qqtHQ3xBc-...)
│     │  └───-45.07 MB (-7.66%) ++ js-zone(0xNNN)

Lots more churn there -- the pistol.luminata Facebook page increased by 1062 MiB while the florin.arjocu one decreased by 619 MiB.

I'm not sure what this means; it looks like it is Facebook's own code that's responsible.

Two interesting things you could try:

- If you create a new profile, does this still happen?

- If you try another browser, does this still happen?

Answers to those two questions would help with understanding whether Firefox is doing something unreasonable.

Comment 9

[florin arjocu]

One of the questions you asked can be answered on the spot, from experience: Chromium does the same thing, but over theere each tab can has its own process so it can be closed and all resources for that tab get free, one hanging tab will not freeze the whole browser, etc.

Does having another profile loose my bookmarks/passwords/etc.? I have 1000+ bookmarks, lots of saved passwords, etc. and I use them.


In the end, yes, I know it is Facebook that creats lots of objects, but the browser should have a limited number of to allow one page or should destroy those objects after a while, so the browser can be properly used. Just by navigating in Facebook and chatting, today I got 1.8 GB of memory again. I do not wish to close the browser a few times a day and lose what I do just to free my system memory.

I would really like some feature to completely unload a tab after X minutes (and load it when switching to that tab or by pressing some button on that tab). With a whitelist for exceptions.

Comment 10

[florin arjocu]

For supporting my idea, I have an example: I could leave GIMP/Photoshop/FileZilla/MS Word/whatever software opened for one day. Nothing changes, it is open and the system memory is constant. Why leaving Firefox/the_browser open should only collect data and stuff the memory with DOM objects? It should also free them from time to time and make those pages work in a limited space. :)

If I had 8 GB of memory, Firefox would "eat it all"? FB alone would get to 2-3-4 GB? Not reasonable.

Maybe I also have GIMP with a 50+ megapixel image and I really need that memory. In the way things are not I should stop being productive on the computer just to allocate all memory to the browser...

Comment 11

[Nicholas Nethercote [inactive]]

You can have multiple profiles; creating a new one won't destroy the old one. See
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles for details.

Thanks for the info about Chromium. That indicates that the fault lies primarily with Facebook.

As for your other ideas, the "unload tabs after a while" idea has been filed as bug 675539. I'm not sure if the "limit memory available to each tab" idea has a bug, but it's certainly been suggested many times. In both case, the difficulty is choosing the right heuristics -- it's inevitable that they'll be wrong for some people, and then we'll get complaints "why did you unload this important tab?" or "why is this site not working properly?" or "I have 8 GiB, why isn't Firefox taking advantage of it?", etc, etc.

Comment 12

[florin arjocu]

Of course there are many people having many ways of interacting with the computer / Firefox. The only way to make all happy is to allow them to choose which tab (actually domain/dubdomain) can and which cannot be suspended, via a whitelist. Something very easy and obvious (something on top of that tab, etc.).

And, just as someone said in the 675539 bug report, allow plugins to do that with a very flexible and performant API :) For now I am trying BarTab Heavy to see how it works (it seems to do some part of the job, but it seems slow). I will also try UnloadTab.

Comment 13

[florin arjocu]

And I forgot something: this is just a part of the problem, the other one is that a tab can get very greedy. Getting to have swap file slows the enrire OS, so it should be completely avoided (I have no idea how it is on SDD, I don't have a SSD HDD, but this is what happens on (still) normal drives). Something should be done.

Comment 14

[Nicholas Nethercote [inactive]]

Resolving because it's the site that's the cause. Feel free to file new bugs or contribute to existing bugs about limiting tabs' resources.