High memory usage

[ADDISON74]

Description

Ghostery is using a lot of RAM.

Expected Behavior

Ghostery should have a reasonable usage. I can accept 100 MB maximum 150 MB.

Actual Behavior

In my case it is using about 450 MB and the best value was 326 MB.

Steps to Reproduce

1. Chrome latest version on Windows 10 Pro. No other extensions except Ghostery
2. No URL in Address bar just Chrome home page.
3. Shift + Esc to check the memory usage. CPU usage is around 45% (4 cores).

I will disable Ghostery for a while. My machine is only 4 GB of RAM and more than 10% is too much. Usage of CPU is also an issue.

[suederade]

I'm getting the same problem except it's using over 2GB of memory and on MacOS.

[ghost]

Wow.. mine is much lower (around 15 mb). I'm on Firefox though. Maybe a browser related issue?

[Zetanova]

On my chrome it is using 1.5GB, visited only view sites.

any updates on this issue?

[christophertino]

Can you let me know how much memory Ghostery is consuming in the Chrome Task Manager vs the Windows Task Manager?

[gilbert-h]

Just had the same issue. Chrome had it using 3 GB, showed up as ~1.2 GB in Windows task manager. Had less than 10 tabs open, none particularly resource intensive. Windows 10, Chrome 80.0.3987.162, Ghostery 8.4.8

[Zetanova]

@christophertino ghostery has 1.5GB under the Chrome-Task-Manager

[christophertino]

Can you try manual garbage collection and see if that brings the memory value down?

• Navigate to chrome://extensions/
• Enable developer mode (top right)
• Under Ghostery click "background page" beside Inspect Views
• Click the Memory tab
• Click the trash icon 3 times, waiting ~3 seconds between each click
• Check Chrome task manager to see if any memory is released

I've been generating heap snapshots and memory allocation profiles but haven't seen anything conclusive. I was able to see some memory escalation but it seemed to go away after I closed out the developer tools.

This bug from the AdBlock team indicates there may be an issue with Chrome delaying garbage collection. They concluded that the browser may not trigger garbage collection until it runs out of memory (see here), but that the memory would be freed up eventually.

If anyone is able to take some heap snapshots (before the memory increase and during), that would be helpful. From the same Memory tab as above, where it says 'Summary' change that to 'Comparison'. Then sort the columns by # Delta and Size Delta, looking for large positive values. See if you can drill down into any large values.

[Zetanova]

@christophertino Started with 1.2GB memory footprint in the chrome task manager after 5h runtime

JS Heap size was only 20MB and snapshot size too.
The GC only reduced it to 18.5MB

In the chrome task manager the memory footprint is still at 1.2GB and JS memory 25MB (19MB live)

The Chrome task group has in windows task manager 1.7GB memory

[JacksonWrath]

Also seeing this issue lately. Details requested so far:

After a few days use:

Windows Task Manager	RAM
Chrome Total Usage	2.1 GB
Ghostery PID Usage	808 MB

Chrome Task Manager	RAM
Ghostery	1.3 GB

Ghostery is the top process by more than 100%. Next step down from there was a tab using about 376 MB (windows reported).

Manual garbage collection only helped by a few MB. Restarting Chrome, Ghostery starts at about 70MB. I took a snapshot after restart; will take another to compare deltas after the problem resurfaces and report back.

[suederade]

Here is some data from Chrome Task Manager and Activity Monitor. I also took a sample from Activity Monitor.

Activity Monitor	Memory
Base Process	2.3 GB
Real Memory Size	1.6 GB
Virtual Memory Size	25.04 GB
Shared Memory Size	73.9 MB
Private Memory Size	1.5 GB

Chrome Task Manager	RAM
Ghostery	2.2 GB

[macOneOone]

Yeah, how that hell happen to a single extension produce 2GB of RAM.

This issue was open at December 9, 2019 and nobody fix it. It means that we will remain to deal with that issue

[mdnahas]

I am a casual user of Ghostery (but one with advanced degrees of CS) and I'm seeing extremely high memory usage. I wouldn't post here, except I saw that the issue was already open.

When I enable Ghostery, the virtual memory used by Firefox's WebExtensions process jumps above 14gb. When I disable Ghostery, it drops below 1gb. I found the issue because I was getting lag and Firefox's Memory Report says I'm seeing a lot of "soft page swaps". I shouldn't see any page swaps --- my machine has 16gb of RAM and I wasn't even doing anything large on it.

I'm shocked how fast virtual memory size jumps up when enabling Ghostery. Are you mem-mapping a file or using a sparse memory map somewhere? A memory leak should take time to get to that amount. It's very odd.

I noticed the lag on my system about 2 to 3 weeks ago. Tech details are:

• Firefox 79.0 (64-bit)
• GNOME 3.36.3
• Ubuntu 20.04.1 LTS, 64-bit
• Dell XPS 13 model 9370, 16gb, Intel Core i5-8250U 1.60Ghx x 8

Reply to this message if you need me to do anything to help.

[christophertino]

@mdnahas If you're able to run some performance diagnostics it would be helpful. Unfortunately, FF doesn't allow memory snapshots for extensions the same way that Chrome does. But you can create a performance allocation profile that may be able to show some abnormal memory allocations taking place.

• Visit about:debugging#/runtime/this-firefox
• Click "Inspect" next to Ghostery
• In the toolbox window select the Performance tab
• Click the gear icon on the right and enable "Record Allocations"
• Start recording

There's some additional info from MDN on recording allocations here. I've been chasing this bug for several months without any luck and would be happy to have some extra help tracking this down.

[mdnahas]

Ghostery support ("Sloane") contacted me. They had me update my version of Ghostery and other add-ons, etc.

After doing that, I did some more investigation. Both Ghostery and HTTPS Everywhere are both allocating about 6.3GB of virtual memory when enabled. (As measured by the WebExtensions process in the "top" program.) The other extensions that I use don't do that. (Those extensions are Disconnect and Leech Block NG.)

I've learned more about using "top" and can now see the number of page faults in it. If I encounter the lag again, I'll confirm that it is the WebExtensions process that is faulting and causing the problem. So far, I've assumed it was Ghostery in Firefox because of the absurdly high amount of virtual memory. But it seems that is both Ghostery and HTTPS Everywhere extension.

Because you asked, I did a recording while I typed for a minute in GMail. Hopefully, it helps. (I changed the suffix from .json to .txt, so you'll have to change it back.)

Ghostery_recording.txt

[christophertino]

Thanks for that profile. I was seeing something similar on my end around _scheduleNextTick. Could you check one more thing:

• Visit about:debugging#/runtime/this-firefox
• Click "Inspect" next to Ghostery
• In the toolbox window select the Console tab
• Enter CLIQZ.services.pacemaker.api and look at the size of the tasks object. On my machine the size is 29.

And then let's try turning off Pacemaker:

• Restart FF
• Follow steps above to the Console
• Enter CLIQZ.services.pacemaker.unload()

This may break some things in Ghostery but I'm curious to see if the memory leak is still present.

[mdnahas]

CLIQZ.services.pacemaker.api
Object { freq: 1000, timer: 175567, tasks: Set(30) }

At the moment, I'm not sure there is a memory leak. It takes up 6GB of RAM right away when enabled. A leak takes time.

I'm hesitant to "break things" when I'm not sure what I'm turning off and don't know how to turn it on and don't know what the lasting effects are.

[christophertino]

Pacemaker is just used to schedule timeouts. It will restart when you restart the browser. But I understand if you are hesitant to turn it off.

Here's an open Bugzilla ticket that seems to be related: Very high virtual memory usage in the WebExtensions process on Linux

[mdnahas]

That bug report seems to be exactly what I'm seeing in "top".

The lag has reappeared. I'm not sure what's causing it. It is not (immediately) connected to the virtual memory issue. I was able to look at memory faults in "top". 5 processes were experiencing millions of "minor page faults", which happen when the data is already in physical memory but not mapped in the process's memory. E.g., when a process makes a call to a library function that was previously called by another process. The most faulted process wasn't even "WebExtensions".

I'm seeing CPU bursts when I encounter the lag. I'll try to track it down, but it doesn't seem to be connected to this issue.

[Lagicrus]

I can also reproduce the same bug with 1GB+ memory usage on the current latest build of Chrome (85) on Windows 10.
Let me know if I can do any testing/recording to narrow this down.

[Zeldazackman]

This is still an active issue that has been observed for years, ghostery has been called out as having a memory leak issue in that it can slowly creep to using nearly all of a system's memory despite nothing being used in chrome or firefox.

You can have a single blank tab for the browser and watch it's usage climb higher and higher for no discernable nor logical reason.

[WesselKroos]

The extension crashed on my laptop after it reached a memory usage of 5GB. I've restarted it and it's now using 65MB.