We will have to debug more into that.Behind the scenes, a typical web page pulls in ads, photos and videos, social-network widgets, recommended links, commenting sections, and other elements from dozens of companies’ servers. But, of course, it could also be that the extension keeps references alive in some callbacks. (It would be interesting to test more on a constrained environment instead of a dev machine with lots of memory.)ĭocumentCachedAccessor is part of the Blink render engine:Īnd the class ScopedPersistent is defined here:įrom the comments (and the name "cache"), it could be that Chrome is not aggressively cleaning up the values in the cache if there is enough memory available on the system. At least on my machine, there is typically enough idle memory to justify keeping the entries in the cache alive. (Chrome specific from here on) One aspect that I'm currently not fully understand is whether the entries in Window#DocumentCachedAccessor will be cleared by the GC if there is no memory pressure.
#Ghostery figleaf disconnect trackoff how to
It is not clear yet how to fix it, but we reached now a stage where the problem is clearly reproducible on Chrome. Reply to this message if you need me to do anything to Thanks for the snapshot! I'm was able to produce the high memory usage on Chrome and my heap summary looked almost identical ( Window#DocumentCachedAccessor holding references). I noticed the lag on my system about 2 to 3 weeks ago. Are you mem-mapping a file or using a sparse memory map somewhere? A memory leak should take time to get to that amount. I'm shocked how fast virtual memory size jumps up when enabling Ghostery. I shouldn't see any page swaps - my machine has 16gb of RAM and I wasn't even doing anything large on it. I found the issue because I was getting lag and Firefox's Memory Report says I'm seeing a lot of "soft page swaps". When I disable Ghostery, it drops below 1gb.
When I enable Ghostery, the virtual memory used by Firefox's WebExtensions process jumps above 14gb. I wouldn't post here, except I saw that the issue was already open. I am a casual user of Ghostery (but one with advanced degrees of CS) and I'm seeing extremely high memory usage. See if you can drill down into any large values. Then sort the columns by # Delta and Size Delta, looking for large positive values. From the same Memory tab as above, where it says 'Summary' change that to 'Comparison'. If anyone is able to take some heap snapshots (before the memory increase and during), that would be helpful. 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. This bug from the AdBlock team indicates there may be an issue with Chrome delaying garbage collection. I was able to see some memory escalation but it seemed to go away after I closed out the developer tools. I've been generating heap snapshots and memory allocation profiles but haven't seen anything conclusive. Check Chrome task manager to see if any memory is released.Click the trash icon 3 times, waiting ~3 seconds between each click.Under Ghostery click "background page" beside Inspect Views.
#Ghostery figleaf disconnect trackoff manual
Can you try manual garbage collection and see if that brings the memory value down?
0 kommentar(er)
