Jump to content

Heavy SSD Writes from Firefox


Batu69

Recommended Posts

If you are a user of Firefox we have a must-change setting. Today’s modern multi-core processor systems and higher quantities of RAM allow users to open multiple Firefox tabs and windows simultaneously. This can have an unintended effect for those SSDs as session store data can write data constantly to NAND. This issue is being discussed in a STH forum thread where you can follow the discussion.

Observing the Issue: Heavy SSD Writes from Firefox

Purely by chance, I fired up a free copy of SSDLife on two consecutive days where I haven’t really used my workstation for anything other than email and browsing. For those of you unfamiliar with this tool, it simply reports estimated lifetime for the attached SSD and it also shows the amount of data read and written.

 

In my case, SSDLife notified me that 12GB was written to the SSD in one day. Since I didn’t recall downloading any huge files over the previous day or visiting any new sites that could’ve resulted in bringing down a lot of new content to the cache, this puzzled me. I monitored these stats over the next couple of weeks and this behavior stayed consistent. Even if the workstation was left idle with nothing running on it but a few browser windows, it would invariably write at least 10GB per day to the SSD.

 

firefox-with-32gb-written-in-a-single-day

firefox-with-32gb-written-in-a-single-day

To find out what’s going on, I fired up Resource Monitor and looked at disk utilization.

 

Firefox Disk Writes

 

At the very top of the list was Firefox, writing tirelessly at anywhere between 300K and 2MB per second to a file called “recovery.js”. Researching revealed that this is Firefox’s session backup file that is used to restore your browser sessions in case of a browser or an OS crash. That is extremely useful functionality. I was aware of the fact that Firefox had this feature, but I had no idea that session information was so heavy!

 

Researching the issue a bit more over the next day, I discovered that things are worse than I originally thought and “recovery.js” isn’t the only file involved. In case someone wants to replicate, here’s what I did this morning:

  • I reset browser.sessionstore.interval to 15000 and then got rid of all my currently open FF windows.
  • I opened a single window with just Google running in it, left it sitting for a couple of minutes, and then closed it.
  • I started the browser again and on this final restart the recovery.js file was only 5KB in size, down from around 900KB before.
  • Next, I opened a bunch of random reviews for Samsung 850 pro and Samsung Galaxy S7 in two separate windows. Simply searched for “samsung 850 pro review” and “samsung galaxy s7 review” and then went down the list of results opening them in new tabs.
  • I opened a 3rd window and created a bunch of tabs showing front pages for various news sites.
  • I launched Process Monitor and configured it to track recovery.js and cookie* files:

Firefox Disk Activity Process Monitor

 

  • I went to File->Capture Events and disabled it. Cleared all events that were currently showing up.
  • I went back to File->Capture Events and re-enabled it. Left the three FireFox windows sitting idle for 45 minutes while I was using Chrome instead.
  • Then I went to Tools->File Summary to get overall stats.
  • Firefox managed to write 1.1GB to disk with the vast majority of data going into cookie* files.

Firefox Disk Activity File Stats

 

Note that recovery.js managed to accumulate only about 1.3MB of writes.

I went back to one of the Firefox windows and opened my outlook.com mailbox. Cleared all events in Process Monitor and re-started the capture. Again, I left all Firefox windows sitting idle, but only for ~10 minutes. This time recovery.js was at ~1.5MB and it took only about 1/4-th of the time to get there. Cookie* files had a ton of data written to them, as before.

 

Firefox Disk Activity File Stats 2

 

Depending on what you’ve got open in your tabs, Firefox could be dumping tons of data into recovery.js, cookie* files, or both. Running at 1.1GB for every 45 minutes, you’re looking at ~35GB/day written to your SSD if you leave your machine running. And at least in my case this wasn’t even the worst example of how much data could be going into recovery.js. In my original tests I clocked Firefox at 2MB/s writing to this file and the writing thread never went dead always showing up on the top of the list in Resource Monitor.

The Easy Fix

After some digging, I found out that this behavior is controlled by a parameter that you can access through typing “about:config” in the address bar. This parameter is called: —browser.sessionstore.interval

 

It is set to 15 seconds by default. In my case, I reset it to a more sane (at least for me) 30 minutes. Since then, I’m only seeing about 2GB written to disk when my workstation is left idle, which still feels like a lot but is 5 times less than before.

 

Bottom line is that if you have a lower capacity consumer level SSDs in some of your machines, you may want to check and tweak your Firefox config. Those drives can be rated for about 20GB of writes per day and Firefox alone might be using more than half of that. This is especially true if you’re like me and have a several browser windows open at all times each with numerous tabs. Changing this parameter may even help with normal HDDs. Your machine will feel faster if it doesn’t have to constantly write this session info. We have seen in the STH forum thread that content open in browser does have a major impact on writes as does the number of open windows and tabs. If you are using Firefox and a lower write endurance SSD you should check this immediately.

 

If you are wondering how this compares to real-world enterprise SSD usage, STH did a study buying hundreds of used enterprise/ datacenter SSDs off of ebay and checking SMART data for actual DWPD usage. See: Used enterprise SSDs: Dissecting our production SSD population

 

Update 1: We are testing other browsers. Currently in the middle of a Chrome Version 52.0.2743.116 m test. We have been able to see a pace of over 24GB/ day of writes on this machine (see here.)

 

Article source

Link to comment
Share on other sites


  • Replies 19
  • Views 1.9k
  • Created
  • Last Reply

Kreistalmighty!?!?... What NEXT???? Is there a best practice (spelled simple, practical) way to cope with this--and Does Mozilla know about this problem?

 

Note to self: Place order for another gross of Samsung SSD's...  cha-ching!

Link to comment
Share on other sites


 

1 hour ago, Batu69 said:

After some digging, I found out that this behavior is controlled by a parameter that you can access through typing “about:config” in the address bar. This parameter is called: —browser.sessionstore.interval

 

Just updated to 49.0.1 so I can't give testimony how it was before but browser.sessionstore.interval in this latest version is 1500.

1500 what?

Link to comment
Share on other sites


  • Administrator

This is a big and important find. As the updated part shows, it even effects Chrome.

 

How the heck does Firefox writes so much amount of cookies though. Has to be a bug.

 

If not done already, they should file bugs for Firefox and Chrome in their respective places for this.

Link to comment
Share on other sites


16 minutes ago, DKT27 said:

This is a big and important find. As the updated part shows, it even effects Chrome.

 

How the heck does Firefox writes so much amount of cookies though. Has to be a bug.

 

If not done already, they should file bugs for Firefox and Chrome in their respective places for this.


I found this topic there's  a utility  for Linux to stop it called profile sync daemon, PSD.

Quote

 

Chrome, on my system, is even more abusive. Watch the size of the .config/google-chrome directory and you'll see that it grows to multi-GB in the profile file.

There is a Linux utility that takes care of all browsers' abuse of your ssd called profile sync daemon, PSD. It's available in the debian repo or [1] for Ubuntu or [2] for source. It uses `overlay` filesystem to direct all writes to ram and only syncs back to disc the deltas every n minutes using rsync. Been using this for years. You can also manually alleviate some of this by setting up a tmpfs and symlink .cache to it.

 

 


 

https://news.ycombinator.com/item?id=12565023

Profile-sync-daemon

https://github.com/graysky2/profile-sync-daemon

but no fix for Windows or Mac OSX  but what is shown in op ...and seems to be even be worse on chrome

Link to comment
Share on other sites


  • Administrator

I can understand the disk cache writing so much, but cookies, which are so small in size, really should not write so much I think.

Link to comment
Share on other sites


Dude I'll be honest,

 

This is why I love coming to Nsane.

You guys have got your shit nicely organized.

 

A simple visit to NsaneDown and I can see the news in specific topics.

I guess I'm really just too lazy to find an alternative with RSS and news in topics organized like you guys.

 

Big thank you to those contributing to NsaneDown

An appreciation post once in a while won't hurt... right? :) 

Link to comment
Share on other sites


3 hours ago, luisam said:

 

 

Just updated to 49.0.1 so I can't give testimony how it was before but browser.sessionstore.interval in this latest version is 1500.

1500 what?

 

I think it should be 15000. That's 15000 milliseconds, i.e. 15 seconds. That's the default value.

Link to comment
Share on other sites


nsaneforums welcome back we missed you.

 

Now on the subject...i never keep any browser data on my ssd i simply link the folder to a mechanical drive.

The easiest way to do that is with Symlink Creator or you could also go with command prompt 

Link to comment
Share on other sites


Is it possible to just cut off the browser storage function altogether?  I don't usually crash and rarely care about session recovery.

Link to comment
Share on other sites


Yeah, this is not exactly a new find, its been known about for years, back to at least 2008, its why i always set sessionstores interval to a huge value, not only because i dont need or find restoring a session useful...especially after a crash, because its going to load the on average 20 tabs i have open in a way that fragments the memory needed and slows the browser.

 

If you want to go to a page you had open before a crash, try your history, or become good with bookmarking. Sessionstore is a bad idea that should die

 

Not sure theres a way to completely disable it, but you can make it write a hell of a lot less

 

I do this:

 

1) about:config in address bar

2) find browser.sessionstore.interval

3) set it to 999999999 (largest value you can set) - 11.5 days

 

 

Im just about to migrate to my first SSD...lol, i bought it 4 weeks ago, but been too busy to put it on and reinsatll windows and programs from scratch, and sessionstore was on my checklist of things to (effectively) disable

 

1 hour ago, haxzion said:

nsaneforums welcome back we missed you.

 

Now on the subject...i never keep any browser data on my ssd i simply link the folder to a mechanical drive.

The easiest way to do that is with Symlink Creator or you could also go with command prompt 

 

Yup thats a valid solution too :)

 

But just editing the profiles.ini is better/easier: https://support.mozilla.org/en-US/questions/944695

Link to comment
Share on other sites


Mozilla Firefox is one of the well-known web browsers. During its long life from 2004, it got extremely popular due to add-on support but lost the race to Google once they released the Chrome browser. Lately, Firefox has been doing some changes which are not being well-received by users. One latest discovery shows that Firefox causes an abnormally high amount of disk operations which on SSDs can wear them out or reduce their lifespan.

By default, Firefox's profile is located on the same drive where Windows is installed. If you are using an SSD drive, then the profile is stored on it as well in your %appdata%\Firefox folder.

In a recent research from Sergey Bobik of servethehome.com, it was observed that Firefox is, for some reason, writing a huge amount of data in a relatively short period of time to the disk drive. In the case of the author, the freeware version of SSDLife notified him that as much as 12 GB was written to the SSD in one day. Once he spotted this, he started tracking processes using SysInternals Process Explorer. Without browsing heavy websites or watching video streams, Firefox managed to write at least 10 GB of data per day to the drive.

Firefox-with-32GB-written-in-a-single-da

 

After a long investigation, the author found out that the cause of the issue is the session auto saving feature of Firefox. It is enabled by default and saves the current browsing session's state every 15 seconds. After increasing the timeout, the issue was fixed.

 

To reduce the frequency with which Firefox writes data to the drive, this is what the author did and what you can do too.

 

1.Open a new tab in Firefox and enter the following text in the address bar:

about:config

Confirm that you will be careful if a warning message appears for you.

 

2. Enter the following text in the filter box:
 

browser.sessionstore.interval

3. Set the browser.sessionstore.interval to 108000000, this means 30 minutes. Now, Firefox will save the session once every 30 mins and not every 15 seconds!

Firefox-fix-SSD-trashing-600x459.png

 

4.Restart Firefox.


According to the author, if you have a lower capacity consumer level SSD in any of your machines, your drive can be rated for about 20 GB of writes per day and Firefox alone might be using more than half of that. This is especially true for users who usually have several browser windows open with a huge number of tabs.

 

Changing the mentioned parameter in about:config can help you to lengthen your SSD's life. This tweak can be useful for hard disk drive users too because it reduces the disk load.

 

It is worth mentioning that SSD technology has greatly improved in recent years and is still rapidly evolving. With MLC and TLC NAND flash memory, 3D NAND and now 3D XPoint memory, modern SSD drives have a very long long span and can withstand several terabytes of data written per day. They can survive for years under heavy load so frequent writes should not be a problem at all. In any case, I recommend to adjust the parameter to some value higher than 15 seconds.

Article source

Link to comment
Share on other sites


21 minutes ago, Petrovic said:

3. Set the browser.sessionstore.interval to 108000000, this means 30 minutes. Now, Firefox will save the session once every 30 mins and not every 15 seconds!

 

30 mins is 1800000 ms, not 108000000 ms! Check your math. (108000000 ms is 30 hours.)

 

 

Link to comment
Share on other sites


On 9/24/2016 at 3:20 AM, stylemessiah said:

Yeah, this is not exactly a new find, its been known about for years, back to at least 2008, its why i always set sessionstores interval to a huge value, not only because i dont need or find restoring a session useful...especially after a crash, because its going to load the on average 20 tabs i have open in a way that fragments the memory needed and slows the browser.

 

If you want to go to a page you had open before a crash, try your history, or become good with bookmarking. Sessionstore is a bad idea that should die

 

Not sure theres a way to completely disable it, but you can make it write a hell of a lot less

 

I do this:

 

1) about:config in address bar

2) find browser.sessionstore.interval

3) set it to 999999999 (largest value you can set) - 11.5 days

 

 

Im just about to migrate to my first SSD...lol, i bought it 4 weeks ago, but been too busy to put it on and reinsatll windows and programs from scratch, and sessionstore was on my checklist of things to (effectively) disable

 

 

Yup thats a valid solution too :)

 

But just editing the profiles.ini is better/easier: https://support.mozilla.org/en-US/questions/944695

Don't reinstall Windows unless you just want to for other reasons.  Clone that old drive to your new SSD.  Works like a charm and is easy assuming you've got the hardware to connect 2 drives at once.  PM me for cloning program if you don't have access to once already.

 

Link to comment
Share on other sites


  • Administrator

I think adding a single 0 would be sufficient for most people if you ask me. But that would not properly fix the issue though.

Link to comment
Share on other sites


The main thing I couldn't pinpoint is that if I'm using a browser based on Chrome,

do I need to do anything?

 

-- Quick Google. found 

Anonym URL

 

Quote

Update 1: We are testing other browsers. Currently in the middle of a Chrome Version 52.0.2743.116 m test. We have been able to see a pace of over 24GB/ day of writes on this machine

 

Link to comment
Share on other sites


On 9/26/2016 at 9:24 PM, Stricken said:

The main thing I couldn't pinpoint is that if I'm using a browser based on Chrome,

do I need to do anything?

 

-- Quick Google. found 

Anonym URL

 

 

Thank you in advance and please keep us informed... esp the repair/tweak too.

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...