regular garbage collection spike
Categories
(Core :: JavaScript: GC, defect, P3)
Tracking
()
People
(Reporter: private_lock, Unassigned)
Details
Attachments
(6 files)
Systemmonitor.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
This profile is really huge, with a hundred tabs open for days and a bunch of add-ons running. Though, I was just lazily reading some news article and scrolling the longwinded page. I just switched over to bugzilla and as I type, the behaviour continues.
See screenshot of System-monitor
about 8 spikes show GC in 2:30 min
Actual results:
I recoreded a profile of one of the spikes and found, it is spending time in multiple runs of GC one after another.
See other screenshots.
Expected results:
This is more a question, than a bug:
a) Shall the GC run multiple times in a row?
b) Shouldn't GC release at least some memory?
|
||
Comment 3•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::JavaScript: GC' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 4•4 years ago
|
||
(In reply to Holger from comment #0)
Can you share the profile? It's hard to see what's happening from screenshots.
This is more a question, than a bug:
a) Shall the GC run multiple times in a row?
b) Shouldn't GC release at least some memory?
The answers to these questions largely depend on what the page is doing, but hopefully we don't repeatedly collect for no effect. The system monitor appear to graph shows some fluctuations in memory size though.
|
||
Comment 5•4 years ago
|
||
This can be a symptom of a memory leak (either in the browser or, more often, one of the web pages). It would be useful to see a memory report saved from the URL about:memory to see how much memory is in use and what it is being used for.
This is the internal "Laufzeitanalyse" recording for about 30 seconds. In the end a second GC happened, but that one was shaddowed by my other open bug 1700200.
The memory report is done a few minutes after the other report. The GC collections happen in regular intervals - so it has seen some 10 other spikes ...
Oh I just saw: this profile https://share.firefox.dev/3lGViH6 must have captured a GC spike (by chance) in the first 10 seconds.
|
|
||
Comment 9•4 years ago
|
||
(In reply to Holger from comment #6)
Thanks for uploading the profiles.
It seems you've got rather a lot of extensions present. One of these might be causing this by doing a lot of allocation in the background. Could you try disabling your extensions and see if the problem persists?
|
Reporter | |
Comment 10•4 years ago
|
||
Here is a profile with all 71 addons deactivated: https://share.firefox.dev/3cpWiw0 (oh and I switched to FF88 beta)
I found, FF is every two minutes writing a 142 MB file to profile/sessionstore-backups/recovery.jsonlz4 ... is there some way, to look into this file and prune it a little?
Next I'll try to reactivate the addons one by one to see, which one has an impact on GC.
|
|
Reporter | |
Comment 11•4 years ago
|
||
Sorry, I was a little quick in the last comment: The spikes do actually happen quite regular, even without any addons as can be seen 7x in the screenshot of 2:30 min. Only this time, I was scrolling up and down a little in a news article (https://www.spiegel.de/panorama/corona-impfung-durch-hausaerzte-die-impfpriorisierung-ist-geschichte-a-c1b44e95-c4f8-4981-9458-793d846eed8e?utm_source=pocket-newtab-global-de-DE) - that gave me this profile: https://share.firefox.dev/2Pz0znM with 2 spikes only some 20 seconds apart. And both time it is writing the sessionstore. I think, it wants to uphold the latest scroll position - at the price of rewriting 142 MB every 20 seconds.
|
||
Updated•3 years ago
|
|
|
||
Comment 12•3 years ago
|
||
(In reply to Holger from comment #10)
Here is a profile with all 71 addons deactivated: https://share.firefox.dev/3cpWiw0 (oh and I switched to FF88 beta)
I found, FF is every two minutes writing a 142 MB file to profile/sessionstore-backups/recovery.jsonlz4 ... is there some way, to look into this file and prune it a little?
It looks like there are some answers at https://unix.stackexchange.com/questions/326897/how-to-decompress-jsonlz4-files-firefox-bookmark-backups-using-the-command-lin
Hopefully something there is up to date. I used to have something I used for this on an older machine (I was version-controlling my profile), but I haven't used it in a long time now.
You can refresh your profile from about:support (top right hand side, "Refresh Firefox" or similar). That'll create a new profile but copy some stuff over, I'm not sure how much. Your old profile will still exist, and you can use about:profiles to manage them.
Next I'll try to reactivate the addons one by one to see, which one has an impact on GC.
It's unclear to me at this point whether there's actually a GC problem, or just a problem with the monstrous sessionstore file. I see from your screenshots that the GCs are happening, but not that they're necessarily causing any problems. Maybe it's worth trying with a refreshed profile to hopefully shrink down the sessionstore file (I don't know what's in yours, but I know addons like Tree Style Tabs can store a lot of metadata in there), and then see if it looks like there's still anything GC related?
|
|
Reporter | |
Comment 13•1 year ago
|
||
In the end, I took a backup of my open tabs with
https://addons.mozilla.org/de/firefox/addon/tab-session-manager/
and deleted the extra large /sessionstore-backups/ from my profile. Now the whole folder with all backups together is down to 100 MB (6 files @ 17 MB each) ... closing here
Description
•