Memory loop kills performance and causes crash in last 3 releases
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: juerg, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0
Steps to reproduce:
Session restore already fails due to to much memory bandwidth used and chaotic net I/O in the background. V 123.0.1
Actual results:
Firefox hangs almost for ever and most of the time crashes. Each new release made the issue much worse. Last process in monitor use far to many resources. Randomly background net io is started like somebody did insert spyware.
If I unplug the network the performance improves but despite no net I/O is started again.
Did you hire some junior programmers??
Now I have to use edge to fill out this form. May be Ill donwload chrome if you cannot switch back to the end of year release.
Please do not restore tabs in the background!!
Expected results:
Firefox should work. Now its just a piece of crashing crap! As said all latest releases made it worse.
I use Firefox on HP with fast solid state memory disk.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Firefox crashes for researchgate threads like : https://www.researchgate.net/post/what_is_the_most_important_problem_in_the_theoretical_physics_now
to many screen refreshes are done, may be also the new experimental translate page option plays a role....
During a session restore unusual large amounts of Memory (1300MB) are allocated.
opening https://www.researchgate.net/post/what_is_the_most_important_problem_in_the_theoretical_physics_now adds 400MB that afterwards get paged out. This web page just contains text an no graphics - only icons. So Firefox completely screws up the memory allocation.
Some threads have 10x more writes (Bytes) than reads. Worst thread has 200x more writes than reads. Normal would be 3..5 reads for 1 write (Bytes)
My tip: wrong compiler options used or linked with the whole useless MS framework that always preloads stuff you never will use. Use load on demand option and never use Microsoft tools you have no control on. The above page should need < 1MB if you do proper coding.
Please do not automatically restore tabs that we manually kill due to excess resource usage. This is 100% counter productive.
|
||
Comment 4•1 year ago
|
||
You can disable restoring tabs on restart from the preferences page. If you did turn on restoration (it's off by default), then we load only pinned tabs plus the visible tab in each restored window; all other tabs are not restored until you select them (I have 9000 tabs at the moment, and startup is fast (though not quite as fast as if I had 1)). If you have a large number of tabs (like me), it will use memory to load the state for all those tabs and favicons at startup, but the actual pages won't be loaded until the tab is visible in a window (or pinned).
Note that extensions can often cause large amounts of memory use; I suggest restarting in Help -> Troubleshoot Mode and see if the problems continue.
researchgate.net uses about 110MB on my system; only perhaps 1.78 MB of images, at least 50MB of which can be attributed to JS in one way or another. Most pages nowadays use FAR more JS memory than they do for the text or layout, and usually more than they use for images. (This wasn't always the case, but JS frameworks have made it common).
If Firefox is crashing on pages like that, please submit/add the crash report URL you should see in about:crashes, and we can look into why.
Note that I get cc'd on too many bugs; if you want me to see any responses, please NeedInfo me (Request information from)
The restore Tab/windows always was off.
The crashes I here did report did look like restarts so all but at most 5 slaves did go away and the session:restore option was presented.
So there is no full crash report. But killing (task manager) the Firefox task did show the same outcome.
Do you have a tool to verify (checksum is not enough unless it is higher order) a binary?? We all know that everything goes over the AKAMAI 5 eyes cache and they can insert their version of Firefox on the fly. Unluckily I do some kind of sensitive work and these (NSA-) fools still believe that my public machine has some importance.... So we could exclude this case as it never happende before. But I had to many updates recently...
So it still remains the question why are there more slaves, than tabs and why do some of them extensive write I/O. 200x more than reads.
I can give you the processes screenshot.
|
||
Updated•8 months ago
|
|
|
||
Comment 6•8 months ago
|
||
We use multiple processes for security, performance and stability reasons, such as a GPU process (which can be restarted), separate processes for ServiceWorkers, utility processes, and a Socket Process.
If Restore Tabs & Windows at Startup is off, then we don't restore any, except for 'Pinned' tabs, which you would see loading.
Loading about:memory and Measure and Saving a memory report could help track down what's allocating memory. Or start a profile as soon as you can after startup (put the Profiler icon in your toolbar); profiles measure memory use for each process. You can also set the environment variable MOZ_PROFILER_STARTUP to 1, and the profiler will start early in Firefox startup.
Note that the Windows Process Manager is a very poor tool for investigating resource use of something like Firefox. It double-counts things (shared memory/libraries), includes heap memory that's been freed but not given back to the OS (i.e. effectively just address-space usage), etc. Process Explorer from SysInternals is better, but still doesn't have the sort of internal knowledge needed.
researchgate.net may look like plain text, but it's not. There are megabytes (once parsed and compiled and run by the browser at least) of script on that page (including ads/ad-frameworks, formatting code, etc). You can see this via about:memory if you take a measurement. For me it uses 225-270MB for the researchgate.net process according to Linux sysinfo; while about:memory shows about 110MB is actually allocated (and sysinfo says ~125MB is resident, which mostly matches). This is typical for modern web pages; if anything this is a little heavier a site than some.
All mozilla executables and updates that we distribute are signed. No one can insert a modified version of Firefox.
The new releases work much better and the old bug seems to be solved.
May be Firefox can now handle large Java scripts much better!
|
|
||
Comment 8•8 months ago
|
||
Closing this issue based on Comment 7.
Please re-open if you see similar performance issues.
Description
•