FF60.0.2 Win7 8GB is paging as fast as SSD permits; (15 Windows with lots of tabs, closed many from 60.0.1 but still unusable esp Yahoo email) What's happened?
FF60.0.2 64 bit but not 60.0.1 on Win7 Lattitude E5250 128G SSD with many windows open some with few tabs some with very many tabs is now paging so furiously (80+MB/S) that typing in Yahoo mail is shown 5 to 10 seconds behind keystrokes. I did the FF update yesterday, have been fighting this ever since, have closed very many tabs some windows and have combined tabs of windows with few tabs. Nothing helps. Typing and reflection is faster here (IE) unless I switch window then return, but that reflects lack of javascript character analysis I think; however, scrolling is very slow on this screen.
Can I roll back to 60.0.1? If so, how do I get to 60.0.1 64-bit exe?
Solución elegida
I have learned from following up on the suggestions, although I achieved the my goal when a Refresh attempt I made finally took effect - it was very very s l o w because of the page threshing, so slow I had given it up.
I increased my browser.sessionstore.interval to 150000 milliseconds (2.5 minutes) from 15000 (15 seconds) default based on the SSD article after the Refresh made work possible, although it wasn't strictly necessary. The profile write does not always occur at the interval frequency when I leave Firefox up but am not looking at its pages, probably because nothing changed, tho' surely ads changed I would have thought.
I did notice that the many I/O threads sometimes show up on the Win7 resource monitor with parts of pages I had stored some minutes earlier, which makes me wonder if Firefox write buffers are not being flushed in a timely fashion, which would leave stored html pages needlessly incomplete in the event of a crash followed by session restore - unless the session restore info is complete enough that those writes get done when the session is restored. Of course users won't always do a restore.
Pkshadow: many thanks, and a little envy re your ram foresight. I do recall how much could be done in 8KB; I don't think having 6 orders of magnitude more memory significantly changes the problems that can be addressed, but certainly often improves their solution speed enough to make them usable (and makes pixel level graphics feasible.) I suspect sometimes systems written with 8GB ram in mind may run slower than those written for 8KB, a consequence of fostering/permitting different algorithm choices.
Leer esta respuesta en su contexto 👍 0Todas las respuestas (7)
To be Checked and turned off unless needed for accessibility : Please : go to the Firefox 3 Bar Menu --> Options --> Privacy & Security panel and under Permissions check (put a tick in the box) the setting to Prevent Accessibility Services from accessing your browser.
Multi-Processor Support : Go to the 3 Bar Menu then Options --> General --> Performance and untick everything. change the recommended size lower then see how it runs. Note: 1 = No Multiprocessor = slow again. Try 2 Restart Firefox after making these changes please. Note : Hardware Acceleration is for Video Card, Monitor to see if remain off or to turn back on.
Only Disable as last resort.
Multi-processor Can completely disable it this way in about:config : dom.ipc.processCount set to 1 browser.tabs.remote.autostart = false browser.tabs.remote.autostart.2 = false
Only move to esr if low ram and old system.
Firefox Extended Release Version : Firefox ESR does not come with the latest features but it has the latest security and stability fixes.
If do please :
- https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles
- https://support.mozilla.org/en-US/kb/export-firefox-bookmarks-to-backup-or-transfer
Please let us know if this solved your issue or if need further assistance.
Before your advice came through, I read about and finally managed to effect a Refresh (that was a very slow process because of the paging rate.)
It appears, fingers crossed, that my problem is solved. I have not tried to reinstall NoScript, so far just basking in the pleasure of typing a character or clicking on a tab and having them promptly appear.
The refresh has left me with accessibility options turned off, fine with me for now, but I do not know its former state. I have not reduced the processor or hardware acceleration use, but will try that if NoScript reintroduces the problem (not knowledgeable about why it would be different now that NoScript is removed as opposed to just being disabled - one of the things I tried earlier).
I have not visited every tab, but the refresh currently has only 6 of my 8GB memory in use, so disk rate is factor of 1,000+ times slower, total rate being less than 100 KB/sec in place of the former 100MB/sec.
Thank you very much for your unexpectedly rapid response to my problem. I am leaving this open for one day just to ensure that I can post some more feedback if adding NoScript or visiting all the tabs recreates my original dilemma.
Hi, having 8gig is the problem. Suggest reducing Processors if issue returns. If not concerned to much with sessions or history if happen to loose something I suggest doubling the amount that is suggest. I have. https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/
You can try to modify multi-process settings to see if this has effect.
- set number of content processes to 1 if it is currently set to a higher value (4)
Options/Preferences -> General -> Performance
remove checkmark: [ ] "Use recommended performance settings"
You can find the current multi-process state on the Troubleshooting Information (about:support) page.
- "Help -> Troubleshooting Information" -> "Application Basics":
Multiprocess Windows
Web Content Processes
See also:
As I replied to Pkshadow above, Refresh has so far solved the problem (disk I/O < 100KB/s was 100MB/s), but I am leaving this open for 24 hours until I have added NoScript back in and visited all the tabs.
I wish I had reached out 24 hours earlier, but did not want to burden the support community with something surely easily fixed myself (not). My poor SSD is surely tired having paged petabytes over that time span.
Thank you for your very prompt assistance, I will keep this information handy as I can imagine this coming up in the future (having started programing when Mainframes were lucky to have 32KB of memory it is still difficult to wrap my mind around the insufficiency of 8GB, far more memory than existed in the entire world in the early 60s).
Hi, yes it is, a friend bot a 8k chip for ram and was so happy about his home built system sporting 8k...
I planned on this one 6years ago and filled all the slots 6 with 24gig and my other one that just died was 5yrs old and planned it with 32gig. So yea enjoyment is having ram to spare.
Solución elegida
I have learned from following up on the suggestions, although I achieved the my goal when a Refresh attempt I made finally took effect - it was very very s l o w because of the page threshing, so slow I had given it up.
I increased my browser.sessionstore.interval to 150000 milliseconds (2.5 minutes) from 15000 (15 seconds) default based on the SSD article after the Refresh made work possible, although it wasn't strictly necessary. The profile write does not always occur at the interval frequency when I leave Firefox up but am not looking at its pages, probably because nothing changed, tho' surely ads changed I would have thought.
I did notice that the many I/O threads sometimes show up on the Win7 resource monitor with parts of pages I had stored some minutes earlier, which makes me wonder if Firefox write buffers are not being flushed in a timely fashion, which would leave stored html pages needlessly incomplete in the event of a crash followed by session restore - unless the session restore info is complete enough that those writes get done when the session is restored. Of course users won't always do a restore.
Pkshadow: many thanks, and a little envy re your ram foresight. I do recall how much could be done in 8KB; I don't think having 6 orders of magnitude more memory significantly changes the problems that can be addressed, but certainly often improves their solution speed enough to make them usable (and makes pixel level graphics feasible.) I suspect sometimes systems written with 8GB ram in mind may run slower than those written for 8KB, a consequence of fostering/permitting different algorithm choices.
Modificadas por ChicagoKenB el