Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ublock origin uses 26.6gb of memory on firefox #994

Closed
8 tasks done
kstenerud opened this issue Apr 22, 2020 · 14 comments
Closed
8 tasks done

Ublock origin uses 26.6gb of memory on firefox #994

kstenerud opened this issue Apr 22, 2020 · 14 comments
Labels
Firefox specific to Firefox invalid not a uBlock issue

Comments

@kstenerud
Copy link

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • 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
@gwarser
Copy link

gwarser commented Apr 22, 2020

Is this "Virtual memory" by any chance?

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

@uBlock-user uBlock-user added external issue involving an external factor Firefox specific to Firefox and removed external issue involving an external factor labels Apr 22, 2020
@kstenerud
Copy link
Author

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

@gwarser
Copy link

gwarser commented Apr 22, 2020

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
Copy link
Member

gorhill commented Apr 22, 2020

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.

@uBlock-user uBlock-user added the invalid not a uBlock issue label Apr 22, 2020
@kinow
Copy link

kinow commented Apr 29, 2020

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:

image

Then after a while:

image

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:

image

After re-enabling uBlock Origin:

image

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

image

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.

image

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
Copy link
Member

gorhill commented Apr 29, 2020

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
Copy link
Member

gorhill commented Apr 29, 2020

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

kinow commented Apr 29, 2020

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
Copy link
Member

gorhill commented Apr 29, 2020

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

@kinow
Copy link

kinow commented Apr 29, 2020

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 !

@uBlock-user
Copy link
Contributor

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.

It's not something that's recommeded as disabling WebAssembly also disables WASM based functionality in uBO.

@gorhill
Copy link
Member

gorhill commented Jun 7, 2020

That reduced the virtual memory to 2GB.

And that also made uBO less performant since now it has to use JS instead of WASM, and nothing was gained since only addressable space was consumed, completely unrelated to physical memory usage.

@bradenbest
Copy link

"Virtual Memory is not Physical Memory" - this is splitting hairs. When the "extensions" field in about:processes lists its memory usage as 1GB and task manager / htop simultaneously shows Firefox using 1.5GB, and that shoots down to 400MB the instant you disable a specific extension, that shows that said extension is using 1GB of memory regardless of semantics. It doesn't matter that it may not be using that exact amount in physical memory it's still a gigabyte, and is not what I as a software developer would consider reasonable given the task that uBO performs (not even YouTube, the disgustingly memory-hungry website that it is, uses that much memory). I would expect something closer to 50MB, not 20x that. How much memory does it take to load 5-10MB worth of textfiles into memory? Certainly not a gigabyte. I've disabled as many lists as I feel safe disabling and uBO still accounts for about 50% of the overall extension memory usage on average.

uBO is a useful and very necessary tool -- why wouldn't you make efforts to optimize its speed and memory usage? I think it should be a design goal to never exceed 150MB of memory usage with the default blacklists / settings while idling. I think 150MB is more than reasonable. Ulysses by James Joyce only takes up a generous estimate of 1.3 MB of space. Surely uBO can do its job with an amount of memory equivalent to 100 of these:

image

@gorhill
Copy link
Member

gorhill commented Jun 17, 2024

Excerpt from README file:

Speculated performance issues are marked as invalid and closed if they do not come with actual profiling data from the Firefox Profiler/Chromium Profiler and a fully substantiated analysis supporting the claim.

Do not add pointless comments here, the issue is closed. If you have profiling data supporting your claims, open a new issue with these.

@uBlockOrigin uBlockOrigin locked as resolved and limited conversation to collaborators Jun 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Firefox specific to Firefox invalid not a uBlock issue
Projects
None yet
Development

No branches or pull requests

6 participants