Ublock origin uses 26.6gb of memory on firefox

[kstenerud]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uBlockOrigin
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

Ublock origin uses TONS of memory. I have no custom settings, and have tried resetting to defaults and starting a fresh profile. Upon launch it uses 32gb of memory, and then settles down to 26.6gb if ublock is enabled.

A specific URL where the issue occurs

about:blank

Steps to Reproduce

Start firefox

Expected behavior:

Normal memory usage (2.5gb or so)

Actual behavior:

Firefox's memory usage jumps to 26gb

Your environment

• uBlock Origin version:1.26.2
• Browser Name and version: Firefox 75.0
• Operating System and version: Ubuntu 18.04

Is this "Virtual memory" by any chance?

If "yes", then it's just how Firefox is handling WASM code. Nothing to worry about as this is only address space reservation.

[kstenerud]

The problem is that everything gets laggy when this happens. The only way I can run without the whole system lagging is if I disable ublock origin (with ublock disabled, VIRT is at 1500 or so on a fresh launch).

VIRT is at 1500

Any chance you somehow ended-up on 32bit system? (Ubuntu 18.04 is released as 64bit, but there are some ways for 32bit install).

[gorhill]

Upon launch it uses 32gb of memory, and then settles down to 26.6gb if ublock is enabled.

Addressable memory usage is not physical memory usage. You need to detail how you measured Firefox's memory usage.

I get 4.8 MB on my side as per about:performance, and this is with Firefox opened since yesterday afternoon with many tabs including one video playing from Youtube for hours, and with uBO configured with extra filter lists and rules.

everything gets laggy when this happens

This is an extraordinary claim and requires actual evidence, use https://profiler.firefox.com/ to make the case that uBO is your issue.

[kinow]

This is an extraordinary claim and requires actual evidence, use https://profiler.firefox.com/ to make the case that uBO is your issue.

I will try this profiler some other day (never used, so afraid of sharing the profile without understanding what data it contains), good tip. And my first time over here, so my thanks for uBlock Origin 🎉

Today I decided to have a look at the virtual memory of firefox. I have the exact same case.

Normally upon launch, or if I edit lists I have:

Then after a while:

But I came here, and searching for memory in the issues found this one, because I went to about:addons, and patiently disabled each extension I have (password manager, noscript, facebook container, etc), and restarted the browser.

Without uBlock Origin:

After re-enabling uBlock Origin:

Looking at about:memory and taking some reports, looks like "web extensions" get the 32 GB when ublock is enabled:

But when I disable it, then it gets the same amount as the other 3 processes (Main process, Web content, and another web content).

I am not super concerned about virtual size, as it may grow for many different reasons (application allocated, externally dynamically loaded libraries, etc), but I feel like whenever my system starts to get a bit slow, or the fan is going a bit crazy after watching 1 youtube video while looking at 1 or 2 github issues in other tabs, after I close the browser then open again, and reload the video and tabs, it seems to perform a bit better (though normally I would have navigated to hacker news, company e-mail, stack overflow, news sites, etc, so could be from previous used tabs perhaps too?).

Anyway, just thought it would be useful to report my case too, in case it ever gets re-opened or another issue is created 👍

I am not sure if this is a problem with uBlock. I am working on a software that is replacing an old GUI. The new system is written in Python, and started quite small, but suddenly it started using a lot of virtual memory. Later we found out it was due to libraries loaded by modules (especially protobuf and zeromq).

I think what would be useful, is a note maybe in the docs explaining why this is normal to expect when installing uBlock Origin, and could prevent further issues like this.

Thanks
Bruno

ps: another think I tested, was opening htop in one monitor, while looking at the virt memory, then going to the uBlock Origin settings, and disabling a list and then hitting "Apply changes". Every time did that, or re-enabled the list and applied changes again, the process virtual memory would increase by ~3-6 GB, and then eventually reduce back to 32 or 26 GB again. Not sure if helpful/related. Maybe it's just starting some executable that consumes a bit of virtual memory to re-index the lists.

ps2: to clarify, I feel like the browser gets slower, but there is no indicationg that it's because of uBlock Origin. It would still be helpful to know that that amount of virtual memory is expected, and maybe know the reason too :)

[gorhill]

It's just virtual memory -- it's merely addressable space, nothing to do with physical memory. The high addressable space is just the result of loading WASM modules. At launch uBO loads a lz4 decompression module, which is then unloaded afterward, hence addressable space will be a bit lower after launch.

Nothing in this thread shows any performance issue.

[gorhill]

What does Virtual memory size in top mean?:

Address space (ie. virtual memory in the process list) doesn't cost anything; it's not real. What's real is the RSS (RES) column, which is resident memory. That's how much of your actual memory a process is occupying.

[kinow]

It's just virtual memory -- it's merely addressable space, nothing to do with physical memory. The high addressable space is just the result of loading WASM modules. At launch uBO loads a lz4 decompression module, which is then unloaded afterward, hence addressable space will be a bit lower after launch.

Nothing in this thread shows any performance issue.

Thanks for the explanation!

[gorhill]

By the way, you can prevent uBO from using WASM by toggling advanced setting disableWebAssembly to true.

[kinow]

By the way, you can prevent uBO from using WASM by toggling advanced setting disableWebAssembly to true.

That reduced the virtual memory to 2GB. Not sure if anything discussed here deserves going to the readme or some other doc. I suspect most users won't really care about it.

Thanks @gorhill !