1440807 - Enormous Memory Usage during mundane browsing activity

Status: UNCONFIRMED

(Core :: General, defect)

Description

[discman]

Attachment: ffmemorydisaster.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13; rv:57.0) Gecko/20170101 Firefox/57.0
Build ID: 20180206200532

Steps to reproduce:

Firefox 58 was being running headless in a BSD jail. In the attached screenshot, the firefox process showing the nearly 15 gigabyte memory usage was on Youtube. However, I have not found any particular website that consistently drives up the memory usage in the massive amounts I have seen.


Actual results:

I had been experiencing thrashing on this server, and after much investigating, determined the root of the problem to be firefox processes grabbing enormous amounts of memory, resulting in thrashing.


Expected results:

Firefox should not grab so much memory that thrashing begins.

I have been able to somewhat remediate the problem by restricting firefox to jails that are limited to 4 gigabytes of RAM, but I feel its a serious problem if I have to jail my browser to prevent problems.

Comment 1

[Jan Beich]

mozjemalloc isn't supported on BSDs, so memory usage will be worse than on Windows/OSX/Linux/Android. For 14G of RSS it'd probably require a deep session history or an inadequate freeing resources of closed tabs/sites. Given Gecko Profiler is also a Tier1-only feature, fixing such bugs without being able to reproduce is almost impossible.

Can you at least provide verbose about:memory output during very high memory usage? What type of "BSD jail"? FreeBSD? If so what version/architecture?

Comment 2

[discman]

This is from FreeBSD 11.1 AMD64 running on a Xeon 1270v6 CPU with 32 GB physical memory. 

The idea behind jailing the browser was to limit its ability to consume resources and prevent system from thrashing. Before jailing the browser, it was not possible to get any idea of the cause of the problem as the system would thrash, precluding any kind of diagnostics. 

Getting about:memory may be doable, but will be difficult since when the memory use really goes up, if its running inside a jail, the jail will freeze up. If its running on the OS directly, the system will thrash. Both preclude much interaction with the browser. I could attempt to script it so we can see the progression of mallocs before the crash if you believe this is helpful.

As I mentioned, I was able to ameliorate this issue by putting very strict resource account limits on the jail the browser runs in. If FF is restricted to 4 GB of virtual memory in the jail, everything runs smoothly (I've allowed it to run in this state for a week so far, no problems). There does not seem to be any significant performance decrease either. It makes me wonder if the problem derives from FF having "too much" memory available with the 32 GB and attempting to cache massively.

Comment 3

[Jan Beich]

If you prefer lower memory usage over Stylo performance (bug 1361258) try running as

  $ MALLOC_CONF="narenas:1,tcache:false" firefox ...

which was the default behavior until bug 1363992.