Firefox is eating your SSD – here is how to fix it

86
Mozilla Firefox Eating SSD
Mozilla Firefox Eating SSD

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.)

86 COMMENTS

  1. Thanks, Sergei. Observing similar behavior with:
    Vivaldi 1.5.609.8 (Developer Build) (32-bit). just looking at the I/O Write Bytes column in Process Explorer. Launched this Vivaldi session ~40 ago, some of the child processes (Twitter tabs?) have written as much as 1.4 GB to date.

  2. I cannot reproduce this while Firefox is idle. It seems that data is only written, when i change something in Firefox, e.g. if I scroll down a page i see a write a few seconds later. This makes total sense to me, as the session has changed.

    -> May it be, that some websites or plugins or you ff constantly change the session data? can you reproduce this problem without any plugins on simple html sites? I am also using u Block, maybe some updated banners or something like that cause a change?

    (I am using the Linux Version 45.4.0 (64 bit) o FF on Gentoo)

  3. In looking at the parameters, it shows 15000 for the value, I’m guessing to multiply that by 4 to get the minute and then by 30 to get to 30 minutes for the refresh?

  4. Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plenty of manpower.

  5. It would be great if you’d remind people that the unit of “browser.sessionstore.interval” is MICROSECONDS,
    If people set it to a value like “15” and not “15000” for a 15 second interval (default in FF), they might have a write every 15/1000 of a second, with far more devastating results!

    Hint: to set it to half an hour the correct value would be 1800000 = 1.800.000 (1.8 Million)

  6. Is there a setting to shut off this feature manually?

    Or do we need to increase the interval to ridiculous high values?

  7. “Cookie* files had a ton of data written to them, as before.”

    Should be good to see other browsers behavior and see it they do the same, I wouldn’t be surprised if all others do this, because it seems to be bound to sites abusing of javascript (intersitials, tracking) and therefore creating cookies.

  8. That’s still 24GB/DAY, still too much. Also Chrome manages things differently, which files got the most I/O in your case?

  9. Chrome is less offending with this issue (12GB/Day less than FF), but in the other hand it eats a lot of RAM making things slower, it’s time for all browser developers to revamp their creations and also this is a signal to websites to stop overusing scripts, they run several times per second so the “site” changes very often and new status must be -unnecesarily- written

  10. why are they not using a transaction logfile for the session? they would just append changes to the session and replay it on restore.

  11. Does Firefox also do this when you close it? Can I set it to a high interval and still be sure to get my session, assuming that Firefox has been closed properly the last time?

  12. I just run portable Firefox off my secondary, non-ssd harddrive. I don’t notice any performance issues and I try to run only games on my SSD.

  13. Since you observed lots of cookie data being written: were ads and/or tracking scripts being blocked (in-browser or via proxy or some other solution)?
    If not, this might be something interesting to try for comparison purposes.
    Related: using Firefox in private mode probably could be a workaround.

  14. Not sure I can get the link posted here, so I’ll write out the search: “Firefox on RAM – ArchWiki site:archlinux.org” (via HN).

    A few solutions, some slanted toward Linux but can be modified for other OSes. I’m going to experiment with the first option: Relocate cache only to RAM and give it a few MBs to see how this plays out. Session restore = not a big deal for me. I have an older computer (dualCore, older HD) and although I don’t ever see the HD’s LED flashing often (FF is pretty responsive), I don’t like the idea of my older SATA drive over-working.

  15. That value is stored in milliseconds (1 second = 1000 ms). So, in order to change it to 30 minutes, you would do the following:

    (1000 * 60 * 60) * 30 = 108000000
    (1m) (f) (ms)

    Here’s the definition of those labels:
    ms = millisecond
    s = second
    m = minute
    h = hour
    d = day
    w = week

    And some constant values to help you along:
    1s = 1000 (base)
    1m = 1000 * 60 = 60000
    1h = 1000 * 60 * 60 = 3600000
    1d = 1000 * 60 * 60 * 24 = 86400000
    1w = 1000 * 60 * 60 * 24 * 7 = 604800000

  16. Using uBlock Origin in Firefox and I’m not seeing any excessive disk writes. I recommend you use an adblocker as well.

  17. Hi Yoric,
    thanks for chiming in on this.
    Is there an existing Firefox bug regarding this problem? If so, which ID does it have? Could you link it?
    Are there plans on Mozillas side, to address this issues. You describe that a fix is not trivial but at the same time it sounds like there is no active work happening ot the moment.
    I understand that with e10s being your main focus point, this may have to wait until after Firefox 51.

    Would appreciate more detail though. And thanks for the work you are doing at Mozilla!

  18. Yes, but if you aren’t only using the browser…

    Also, the question is if most people actually need a full session restore or if they are satisfied with a URL restore for each tab.
    For this the browser would only need to write whenever the URL of a tab is changed – which would result in much much less data.

  19. My two year old system drive (Samsung 840 Pro) has written 7.75TB. So making the very conservative assumption of a write endurance of 100TB the drive should be good for another 25 years at this rate.

    I think I’ll leave the default settings.

  20. I think you’re making a mountain out of a molehill.
    Although I think 15 seconds is quite on the paranoid side (then again, I think Mozilla expects Firefox to crash left right and center) it still wouldn’t matter in terms of lifetime of your SSD.

    Raw IO measurements will likely not indicate what is actually written to disk, to begin with, so your measurement is quite biased to the high side.
    Keep in mind: If you write 50GB of data every single day to an inexpensive 256GB SSD, without skipping a day, you can easily last the stated average lifetime for those disks (8 years) without it developing a problem (considering you don’t slam it chock-full of data and forcing it to over-use the same chips time and again). So, does a few MB more or less matter? Not really. Unless you’re the person who wants to buy a sports car to just have it sit in front of their house and not use it 🙂

  21. I like this idea, and use the AddOn called Session Manager to restore any browsing session, including crashed browsing sessions.

  22. There’s a Firefox Add-on called “Session Manager” which backs up any number of sessions you want. It also backs up a crash. I wonder if it uses a similar scanning protocol? If not, that’s the right way to backup sessions. I’ll check with the developer.

  23. Hey! I launched disk IO monitoring tool `iotop` in cumulative mode on my desktop right after reading this article today morning. Below are the results after tracking any single disk READ or WRITE today. Please note that my desktop SSD has a SandForce controller and I have just no idea whether iotop takes it compression in account or not.

    – Firefox Aurora v50 has been running for six hours, half of it being pretty active browsing with my current session of 190 tabs.
    – Slimjet (Chrome fork) was launched and running six time less or one hour long, 5′ of which where active and 3-5 tabs.
    – Thunderbird was also launched and running for one hour with automatic fetching of 5 IMAP accounts.
    – Last, my podcast client (with automatic fetching of new episodes) was launched and running for two hours.

    $ iotop -oPa

    PID DISK READ DISK WRITE> SWAPIN IO COMMAND
    6343 46.44 M 309.09 M 0.00 % 0.00 % firefox-aurora
    15342 38.04 M 90.58 M 0.00 % 0.01 % python2 /usr/bin/gpodder
    17062 76.27 M 59.71 M 0.00 % 0.01 % slimjet
    28931 97.32 M 8.75 M 0.00 % 0.00 % thunderbird

    So taken back to one then twenty four hour each, stats are as follow
    – Firefox (190 tabs): 7.74 MB reads and 51.51 MB writes per hour → 0.186 GB reads and 1.236 GB writes a day
    – Slimjet (3-5 tabs): 73.27 MB reads and 59.71 MB writes → 1.758 GB reads and 1.433 GB writes a day
    – Thunderbird (5 accounts): 97.32 MB reads and 8.75 writes →2.336 GB reads and 0.21 GB writes a day
    – Podcast client (a hundred shows): 19.02 MB reads and 45.29 writes →456 GB reads and 1087 GB writes a day.

    ‘browser.sessionstore.interval’ has been set on ten minutes even since I put an SSD in that box. ‘browser.bookmarks.max_backups’ to three for even longer.

    S.M.A.R.T. says my SanDisk Extreme SSD [1] has written 23 TB in 27632 hours.

    9 Power_On_Hours_and_Msec 0x0032 069 069 000 Old_age Always – 27632h+35m+20.000s
    177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline – 7
    241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always – 23459

    So?
    Given the measured endurance for even more budget and smaller SSD is of dozen of TB written [2], that the real amount of data physically written *may* be lower than what iotop reports by an order of a magnitude (both sessionstore and else files are heavily compressible text files) thanks to the SF “magic”, and last but not the least that all my data is backed up twice a day to an external destination, I’d say what’s the big deal of all this? Focusing on a single process is OK but not cool unless taking the others in account.

    For those of us using the most hackable main stream browser available, do our job and reduce its IO activity as we wish. Gain a 50 years SSD life expectancy if that’s what you want 😉 a higher battery life on our laptop and a (much) better reactivity by making full use of our available RAM. And think of these using another browser that can’t be hacked half of what Firefox (or Seamonkey, Pale Moon) can (e.g. using a couple of small utilities available for Linux I swear I could have FF write 10 MB or less per hour).

    [1]: SanDisk Extreme SSD (with then ubiquitous SF2281VB1-SDC) on Arch Linux.
    [2]: http://ssdendurancetest.com/

  24. Is there any way to only create a session restore when the browser is closed? Without writing to your drive every x minutes?

  25. according to this documentation [1], the field browser.sessionstore.enabled must be set to true for the setting to have effect.

  26. You can create new entries:
    Right mouse click -> New -> String -> browser.sessionstore.enabled -> {Enter} -> false {Enter}

  27. I think you may be looking at the wrong values, at Process Explorer column selection look for the Process Disk tab instead of Process I/O.

  28. I got 16GB of RAM, so I decided that FIrefox shouldn’t use my SSD for storage in the presence of plentiful fast RAM.

    browser.cache.disk.enable = false
    browser.cache.memory.enable = true

    Done.
    Sessionsrestore works fine, too.

  29. Can this stupid site change the extremely misleading title?

    Chrome is writing 24GB and killing drives faster and yet you’re blaming Firefox?

    Is the author an idiot moron or what?

  30. For a second I thought maybe everyone was crazy and some new undetected browser malware was in the wild because I see hardly any disk activity at all even with 15 tabs open,

    Then I remembered I run noscript along with ublockO. Don’t let every random newsblogmarketspamwhatever site connect to 200 extra domains (with a potentially infinite tree of domains from a subset of those) and run whatever code they all demand you run, after that the internet sucks a lot less.

  31. Thanks for investigating and publishing your findings. Have added the tweaks and, so far, all working as before. I am using Session Manager addon.

  32. This doesn’t matter at all. Modern SSD’s have write lifespans in excess of 1,000 terabytes. Even if firefox was writing ten times the amount of data that it does, it would take 25+ years for it to cause drive failure.

    Really not worth disabling a useful function to stop something that wouldn’t have an effect on my drives until long after I’ve replaced them for something bigger/faster.

    Your SSD’s are fine, don’t worry about it.

  33. Browsers are the main piece of software we use today. To make sure everything goes well they have to use that ressources.
    Considering today’s SSDs which much higher TBW than expected from the manufacturer (Samsung ones get about 300-400 TB on expected 100 TB written before they mark single bits as unusable I read somewhere) disk utilisation not really that much of a problem…

  34. How do we turn off this SSD-killer on Chrome?
    I’ve set Chrome to start up with the cache directory pointing to a RAM drive. But I don’t think Chrome session store goes there.

  35. found same issue;
    can said only one firefox made something bad in last updates from spring to autumn;
    before years without any changes it don’t eat ssd and Ikeave it as is on work PC with small SSD;

    in end of summer found somethink eat ssd ~9-15 Gb per day;

    moved firefox from ssd to hdd via mklinks;

    later will try your option with session interval;

  36. @ R Puig.
    September 23, 2016 at 3:34 pm

    Thanks a lot, you are the god of numbers.

    This what i was going to calculate but would not going so far, excellent!
    ****************************************************************************
    (1000 * 60 * 60) * 30 = 108000000
    (1m) (f) (ms)

    Here’s the definition of those labels:
    ms = millisecond
    s = second
    m = minute
    h = hour
    d = day
    w = week

    And some constant values to help you along:
    1s = 1000 (base)
    1m = 1000 * 60 = 60000
    1h = 1000 * 60 * 60 = 3600000
    1d = 1000 * 60 * 60 * 24 = 86400000
    1w = 1000 * 60 * 60 * 24 * 7 = 604800000

  37. But 30 minutes are not 108000000
    but 3600000
    (1000ms*60)= 60000 (1 minute)
    (1000*60*30)=3600000 (30 minute)

    1h = 1000 * 60 * 60 = 3600000
    2h= 7200000

  38. All browsers writes cookies a lot while watching YouTube. It saves your position about every some time. Takes around 3 mb of cookies per minute. But could be much larger to SSD, as those writes are much smaller than 4 kb.

  39. You can’t really have it both ways; you want the speed so you have the files regularly accessed on the SSD, but think about it, do you NEED this?

    It is a bit like thw Windows page file, I always move it to a dedicated logical partiion.

    You can and SHOULD move your Windows profile location from the SSD to another drive, this page says how

    “The default location of user profile in Windows 7 is still the same as Vista, in c:\users folder, which I often find it seems quite dumb putting user profiles in the same partition as the system, especially when I store most of my day-to-day files in my user profile, rather than another folder in another partition. So my preference of the first step after installing the OS on my own computer is always to change the default location to another partition before I actually start setting up my profile.”

    https://www.nextofwindows.com/how-to-change-user-profile-default-location-in-windows-7

    This page tells you how to do it in Windows 10

    https://www.tenforums.com/tutorials/1964-users-folder-move-location-windows-10-a.html

  40. I just don’t understand why the Mozilla devs don’t just provide a quick optional session restore which only saves the links to each tab so it is simply read again once you fire up the browser? I would be very happy with just that and that would not take much space at all. Save a list of 50 links in a text file, that’s not much data.

  41. Searching for “chrome ssd writes’ brings up plenty of similar complaints.
    According to comment 7 for this bug 401391 at bugs.chromium.org, the heavy I/O stopped after disabling the disk cache with switches at startup.
    https://bugs.chromium.org/p/chromium/issues/detail?id=401391
    The disk-cache-size and disk-cache-dir command line switches are still used in Chrome, as shown at:
    http://peter.sh/experiments/chromium-command-line-switches/

    I get the same effect by directing the disk cache elsewhere. I use a RAM drive. With a 400 MB ram drive on drive G, I created a shortcut for Chrome, with this in the target field:
    “C:\Program Files\Google\Chrome\Application\chrome.exe” –disk-cache-dir=”G:\chrome-cache” –disk-cache-size=314572800
    (note the double dashes in front of each switch)

  42. Why would one stop using the only browser that even tries to ensure any sort of online privacy and doesnt think eating all your memory is the correct way to load websites?

  43. at 10 GB per day my SSD would last me theoretically over 100 years, which means such session writes are completel irrelevant for realistic lifespan which will be 5 to 10 years before size outpaces usefulness anyway.

  44. People is saying that modern SSDs are lasting hundreds of TB… but that’s not the case. I bought a 120 GB Kingston SSDNow V300, because my whole C: partition would never go beyond 50 or 60 GB. It was supposed to have a 64 TB endurance… however, because of this Chrome and Firefox caching, my SSD is completely destroyed after 9.5 TB written in 13 months.

  45. The definite solution: RAMDisk for profiles and cache!
    There’s a free version from dataram that should suffice. Set cache location via about:config, and the profile using the profile.ini in AppData/Roaming/Mozilla/Firefox. It does make a difference, since FF pretty much writes a lot (take a look at the various profile files). Just make sure, the Ramdisk DOES NOT perform background updates – it would defeat the purpose. Instead, save the 1-2 GB image initially and perhaps every once in a while. (It will be saved automatically on shutdown). Saves me 500k Writes per week
    Cheers, M.

LEAVE A REPLY

Please enter your comment!
Please enter your name here