21 ms·

Heavy SSD Writes from Firefox

477 points by kungfudoi 10y ago

HorizonXP 10y ago
Wow, that's really unfortunate. I just built a new PC with SSDs, and switched back to Firefox. Even with 16GB of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or try to scroll. This new issue of it prematurely wearing out my SSDs will just push me to Chrome. Hopefully it doesn't have the same issues.
- overcast 10y ago
  You need to enable multiprocess in Firefox, so the thing doesn't shit the bed on you constantly. https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis
  - theandrewbailey 10y ago
    Look out for addons. Electrolysis will still not work with many of them. I force enabled it a few weeks ago, and discovered that it's disabled for good reasons.
    - overcast 10y ago
      Have about ten plugins, no issues here. It's worth actually having a browser that doesn't consume all available resource.
  - joecool1029 10y ago
    Heh. Tried that out and while it didn't affect stability it made switching tabs take 2-3s on a haswell system. By disabling all extensions with it I was able to somewhat match performance of non-multiprocess.
  - anexprogrammer 10y ago
    Nice idea but a load of useful extensions don't work with it. Of extensions I use noscript and 1password were the main ones, but around half were tagged as not compatible.
- __jal 10y ago
  My home desktop is an i5-1620 with 64G RAM running Ubuntu 16.04, and Firefox just hiccups and lags, period. It is sad. I need to find time to experiment with Chrome while blocking all the Google chatter to see how functional it remains without being able to tattle to the mothership (otherwise I won't use it).
  - SubiculumCode 10y ago
    Hiccups and lags are seen in all browsers and is due to bloated websites. Also, Chrome will write just as much to your SSD as Firefox
  - brianwawok 10y ago
    Why not Chromium?
    - CaptSpify 10y ago
      I personally wouldn't recommend chromium because they've been known to do some shady things: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 I'd imagine someone like the above poster would be concerned about that. At least I know I am
  - rasz_pl 10y ago
    Try Vivaldi.
- wodenokoto 10y ago
  I have an old dual core with 4 gigs of ram and Firefox runs better than chrome.
- superkuh 10y ago
  Try out the Pale Moon firefox forks. I'm running it on an old core2duo 6400 (2.13 GHz) with 8 GB ram. I have over 700 tabs in my session right now with at least 300 of them fully loaded. It's using less than 3GB ram. And it's fast/snappy with smooth scrolling.
- Manishearth 10y ago
  According to the blog post Chrome has the same issue, they just haven't investigated yet.
vesinisa 10y ago
I've already moved all my browser profiles to `/tmp` and set up a bootscripts to persist them during boot / shutdown. E.g. for Arch Linux see https://wiki.archlinux.org/index.php/profile-sync-daemon https://wiki.archlinux.org/index.php/profile-sync-daemon This is a far superior solution to fiddling with configuration options in each individual product to avoid wearing down your SSD with constant writes. Murphy's law has it such hacks will only be frustrated by next version upgrade. And no, using Chrome does not help. All browsers that use disk caching or complex state on disk are fundamentally heavy on writes to an SSD. The amount of traffic itself is not even a particularly good measure of SSD wear, since writing a single kilobyte of data on an SSD can not be achieved on HW level without rewriting the whole page, which is generally several megabytes in size. So changing a single byte in a file is no less taxing than a huge 4 MB write.
RussianCow 10y ago
Serious question: Is 12GB a day really going to make a dent in your SSD's lifespan? I was under the impression that, with modern SSDs, you basically didn't have to worry about this stuff.
- gcp 10y ago
  Samsung's low cost line is under warranty up to 40TB/year. Tests have shown that the actual drive lifetime is several times that. So basically, no, you don't have to worry about this. Essentially, people are complaining that the disks they bought are being used for their intended purpose: making sure your data doesn't disappear on a power loss.
  - dogma1138 10y ago
    Not everyone buys Samsung, there are a lot of cheap SSD's out there that are rated for only a handful of TB's a year. There is also a case of the silly SSHD's or w/e which combine a tiny SSD and a mechanical component which can die considerably faster. Overall the amount of writes an SSD can handle is tied directly to it's capacity since it determines the amount of average writes per a given time unit that each cell will experience as long as the firmware actually does it's job (in Samsung's case it may very well not do it as they had more than a few firmware screw ups in the past). This can also more severely affect you if you have a medium sized drive (say 128-256GB) but it's pretty full. A good SSD's will move things around somewhat to even out the wear but it still increases the amount of writes you have. If your SSD does have an "even wear" feature when you write 12GB to drive which is say 50% or more full it usually triggers more than 12GB of effective writes in the drive itself as the firmware would move already written data around to ensure that every cell has been written to approximately the same amount (if you say only have 20GB of free space and you write 12GB daily and delete it, your effective writes would be closer to the full capacity of the drive per day than to 12GB). You also have a lot of embedded/mobile devices which use considerably shittier storage than modern SSD's, you can easily chew through a SD card or a similarly rated flash storage with anywhere between a few 100's of gigs to only a handful of TB's (or a only few times the capacity of the card if buy bargain bin memory cards). Since these machines are more commonly used these days it's not a feature that should be so quickly obfuscated from the user since it doesn't seem like there is an "intelligence" behind how conservative or not the browser is with writes to local storage. If you install firefox on an SBC/netbook/microcomputer or even a mobile phone (if this affects the mobile version also) with eMMC/MMC only rated storage 12 gigs a day can and will kill it rather quickly.
blinkingled 10y ago
Even better just disable session restore entirely - Browser.sessionstore.enabled - Since Firefox 3.5 this preference is superseded with setting browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0. As I understand this feature is there so if the browser crashes it can restore your windows and tabs - I don't remember having a browser crash on me since the demise of Flash.
- gcp 10y ago
  It'll also cover OS crashes or power failures. Agreed that those aren't very common either.
- LukeShu 10y ago
  Other things than a browser crash can cause the browser to unexpectedly quit. For example, a battery dying, or the power going out.
  - blinkingled 10y ago
    Right but that doesn't happen quite often either. Also if it does how important is restoring the tabs and windows? Probably not to a lot of people other than serious creators that use a web editor of some sort that'll lose work if the browser disappears. Even then it is flaky to rely on something like this. Much better to have periodic backups of whatever you're doing.
    - froydnj 10y ago
      You say "doesn't happen quite often", which I'm assuming means something like "doesn't happen quite often to me". But if you consider hundreds of millions of users using Firefox every day, then even a relatively rare event is happening to multiple users every single day. It is absolutely worth it to them that Firefox does its best to preserve their data.
      - Dylan16807 10y ago
        You have a point, but power outages are very correlated.
lighttower 10y ago
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. [1] https://launchpad.net/~graysky/+archive/ubuntu/utils https://launchpad.net/~graysky/+archive/ubuntu/utils [2] https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon EDIT: Add link, grammar EDIT2: Add link to source
- pawadu 10y ago
  What is the typical memory usage of this for normal web browsing?
  - lighttower 10y ago
    `mount -l` shows a filesystem of type `overlay` for each browser (in my case, chromium, chrome, firefox). Range from 50MB to 200MB. I have it to sync to disc every 15min - so I reckon it empties out the ram whenever it syncs. I've never had a problem (8GB of ram on the machine I initially installed it on) so I haven't watched to see what the max size is. The developer [1] is great - issues are resolved very quickly. [1] https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon
  - codemac 10y ago
    Mine uses the following with firefox: overlaid 2.0G 128M 1.9G 7% /run/user/1000/codemac-firefox-3ckuo4v7.default
- lucb1e 10y ago
  Launchpad is such a shitty website, aimed at Ubuntu and only Ubuntu, links to source code or more information are nowhere to be found... Searching on Github, this seems to be it. Turns out, there's releases for Arch, Debian, etc. and it's even in the repositories. No need to add a ppa. https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon For Debian and co: $ apt-cache show profile-sync-daemon $ sudo apt-get install profile-sync-daemon
dogma1138 10y ago
heh https://news.ycombinator.com/item?id=12437309 https://news.ycombinator.com/item?id=12437309
leeoniya 10y ago
i'm not seeing these numbers, using I/O columns in Process Explorer. i'm running Nightly Portable with maybe 80 tabs open/restored.
- gcp 10y ago
  Nightly Portable might have this particular setting changed, because the lifetime of random USB sticks is surely going to be much less than a real SSD.
  - leeoniya 10y ago
    i thought that too but the interval setting is at 15000 in the config, so maybe something else is optimizing it out?
- mrpopo 10y ago
  I'm not seeing these numbers either and I'm running Firefox 49. In the resource monitor, I see firefox writing to disk 10kB every 15 sec. I bet there is something else to the story of this guy.
- deleted 10y ago
  [deleted]
rayiner 10y ago
Doing all this work is also probably burning battery life. An SSD can use several watts while writing, versus as low as 30-50 milliwatts at idle (with proper power management).
- eikenberry 10y ago
  +1. This is why I use PSD (mentioned above) to mitigate this. A RAM cache will use much less power than constant disk writes.
- dclowd9901 10y ago
  Can confirm closing chrome typically doubles my battery life.
kordless 10y ago
I seriously dislike Firefox, but must use it at work due to browser incompatibility issues with Chrome and sites I use heavily. Anything that makes the experience better is much appreciated.
- tonmoy 10y ago
  If is perfectly valid for you to dislike Firefox. But in the context of this post it seems that you assume Chrome is better than FF in terms of disc usage. Do you have any data to back that claim up?
deleted 10y ago
[deleted]
rsync 10y ago
I continue to be impressed with the content and community at servethehome - it's slowly migrated its way into my daily browsing list.
raverbashing 10y ago
Are these writes being sync'd to disk? Because FF may die but the OS will save it later. That's fine Not every write to a file means a write to disk
- holygoat 10y ago
  sessionstore does not fsync.
aylons 10y ago
In Linux where should this be written? Inside the home folder? Maybe moving this folder to a HDD should suffice.
- expression 10y ago
  Or ramdisk if you have a stable system.
  - marcosdumay 10y ago
    That would lose the point of a recovery system. I'd rather just turn it off.
    - onnoonno 10y ago
      I have easily more than 100 firefox crashes for each kernel crash, and I guess that is similar for other people(?) So I think the session restore is almost always used in a case where firefox crashed, but the system is fine.
- gcp 10y ago
  Why would you not want to use your SSD for what it's meant for?
  - CaptSpify 10y ago
    Maybe because they would rather not have their ssd constantly being hit? Seems reasonable to me to move this is you have concerns about the longevity, or maybe IO bottlenecks.
  - aylons 10y ago
    Some things are in the SSD, others on the HDD. This seems to wear the SSD while being seldomly used. Looks like a good case for HDD.
alyandon 10y ago
Yep, I have a brand new SSD drive that over the course of a few months accumulated several TERAbytes (yes - TERA) of writes directly attributable to the default FF browser session sync interval coupled with the fact I leave it open 24/7 with tons of open tabs. Once I noticed that excessive writes were occurring, it was easy for me to identify FF as the culprit in Process Hacker but it took much longer to figure out why FF was doing it.
caiob 10y ago
That goes to show how space/memory hungry and bloated browsers have become.
robin_reala 10y ago
It’s always annoying when an issue like this is reported yet no bugzilla reports are mentioned. Has anyone else filed this already, or shall I?
- tekacs 10y ago
  If it's not already listed there, please do (and post the URL here!) I was thinking the same and will do so myself, if no-one else reports doing so.
- gcp 10y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=1304389 https://bugzilla.mozilla.org/show_bug.cgi?id=1304389
CoryG89 10y ago
Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? Seems like it should only write after a user action or if the open page writes to storage? Even if it was necessary to write continually while idle, how could it possibly consume so much data in such a short period of time?
- gcp 10y ago
  Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? This is very much the feature working as intended: Firefox captures webpage state every 15 seconds, so a crash, power outage, accidentally closing the browser etc will not result in data loss for the user. For storing the data persistently, it uses the persistent storage, i.e. your harddrive. For the HN crowd, that's going to be an SSD. The SSD can easily deal with the resulting write traffic with negligible effect on its lifetime - I have no idea why people even think this is an issue. Seems like it should only write after a user action or if the open page writes to storage Webpages can change their contents or state without user interaction. Webpages are also big and bloated. Storing a little data, all the time, 24/7, adds up over time to a surprisingly large number.
  - CoryG89 10y ago
    I understand that pages can change their state without user interaction, but shouldn't the browser only write to disk when that actually happens? The browser has to be able to detect when these changes happen right? I understand that it's probably not an issue for most users/SSDs. However, if I open just a static HTML file and leave it idle, I don't think the browser should be continually writing to disk. If it is, then to me that is a bug. EDIT: Also, it seems like when I remember restoring a browser session after a crash, all the tabs get reloaded, not restoring the page state, just the tabs/URLs (ie. browser makes new request(s) for each restored tab). I usually use Chrome though, not sure if this has happened to me on Firefox.
amq 10y ago
Observed similar behavior with Skype.
deleted 10y ago
[deleted]
tsukikage 10y ago
The interesting question here is, why is the browser writing data to disk at this rate? If it's genuinely receiving new data at this rate, that's kind of concerning for those of us on capped/metered mobile connections. The original article mentions that cookies accounted for the bulk of the writes, which is distressing. If it's not, using incremental deltas is surely a no-brainer here?
- gcp 10y ago
  If it's not, using incremental deltas is surely a no-brainer here? Might be surprisingly hard or inefficient given that you're trying to capture "webpage state". Think about React sites etc.
zbuf 10y ago
I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. I feel it's little antisocial for regular desktop apps to assume it's for them to do this. Chrome is also a culprit, a similar sync'ing caused us problems at my employer's, inflated pressure on an NFS server where /home directories are network mounts. Even where we already put the cache to a local disk. At the bottom of these sorts of cases I have on more than one occasion found an SQLite database. I can see its benefit as a file format, but I don't think we need full database-like synchronisation on things like cookie updates; I would prefer to lose a few seconds (or minutes) of cookie updates on power loss than over-inflate the I/O requirements.
- jstimpfle 10y ago
  > I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. For completeness, this is probably the eatmydata command.
- robbles 10y ago
  Would you be willing to post a how-to or example of doing this? I'm curious about how this trick works!
  - necessity 10y ago
    It's probably best to just disable sessionstore if you don't want it, as overwriting fsync would disable it for all operations Firefox might use, not just sessionstore.
    - zbuf 10y ago
      That's exactly what I wanted to achieve; I didn't have the time or inclination to work out exactly which part of Firefox is responsible. In my case it was not SSD wear I wanted to reduce, but the short pauses during interactive use.
  - zbuf 10y ago
    Take a look at libeatmydata. I'm doing something practically identical
Nursie 10y ago
Firefox has been terrible for disk access for many years. I remember I had a post install script (to follow, I never actually automated) that I would run through in my linux boxes back in about 2003 that would cut down on this and speed up the whole system. Basically chattr +i on a whole bunch of its files and databases, and everything's fine again...
- gcp 10y ago
  There's been some development the last 13 years. Chrome was also pretty crappy in 2003. /s
  - Klathmon 10y ago
    well, i'd say it was crappy in 2003, it wouldn't even exist for another 5 years ;)
  - Nursie 10y ago
    Oh there's been lots. Looks like it's still incredibly write-happy though.
rackforms 10y ago
Putting aside how this may not be all that bad for most SSD's, does anyone know when this behavior started? Firefox really started to annoy me with its constant and needless updates a few months back; the tipping point being breaking almost all legacy extensions (in 46, I believe). This totally broke the Zend Debugger extension, the only way forward would be to totally change my development environment. I'm 38 and now, and apparently well beyond the days when the "new and shiny" hold value. These days I just want stability and reliability. Firefox keeps charging forward and, as far as I can tell, has brought nothing to the table except new security issues and breaking that which once worked. I haven't updated since 41 and you know what, it's nearly perfect. It's fast, does what I need it to do, and just plain old works. Firefox appears to have become a perfect example of developing for the sake of.
- Freestyler_3 10y ago
  This has been the case for a long time, I just googled and first hit was an article from 2008. source: http://www.ghacks.net/2008/07/09/change-the-session-store-interval-in-firefox/ http://www.ghacks.net/2008/07/09/change-the-session-store-in...
  - ashark 10y ago
    Wikipedia claims the session restore features was added with 2006's 2.0 release. That's what I would have guessed, since that release was (famously) a giant step backwards in performance, which was never really addressed except by waiting for hardware to improve. I'm holding out hope that whoever's responsible for Firefox abandoning "good, light, cross-platform web browser" as its differentiator stays away from Servo, at least for a while. That's a niche that's unserved currently, AFAIK.
- gcp 10y ago
  Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox. If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
Freestyler_3 10y ago
I use Opera on windows, No idea how to check or change the session storage interval. Anyone got ideas on that?
PaulHoule 10y ago
The whole "restore your session" thing is the one of the most user hostile behaviors there is.
justinrstout 10y ago
Theodore Ts'o wrote about a similar Firefox issue back in 2009: https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
Yoric 10y ago
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. I hope we can get around to doing it someday. Of course, as usual in an open-source project, contributors welcome :)
- nograpes 10y ago
  What would an updated version of Session Restore look like? I mean, what would be your vision for a new version?
  - Yoric 10y ago
    I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant for this scale of data; - we wouldn't need to rewrite x Mb of data every 15 seconds, just a per-tab update; - if we're using a relational database, it would be easier to trust the code to not screw up with the data; - we wouldn't need to load the entire Session Restore upon startup. (On the minus side, this might make backups a bit more complicated.) On the front-end, we would need a high-level API for Session Restore, which would let us do things such as accessing per-tab data, (de)hibernating tabs, etc. Oh, and it would need to be accessible by WebExtensions. In the middle, we would need to re-engineer Session Restore to make sure that we don't need to maintain this huge object representing the entire state of the session. We would also need improvements e.g. to cookie management, to avoid having to re-collect cookies so often.
    - Dylan16807 10y ago
      How does that much data get into Session Restore? Mine are only about 3KB per tab, and Firefox starts melting at more than a thousand tabs.
Sami_Lehtinen 10y ago
uBlock also keeps writing "hit counts" to disk all the time, as well as for some strange reason they've chose database page size to be 32k so each update writes at least 32kB.
- gcp 10y ago
  Smaller block sizes caused large performance issues. SQLite isn't very good at keeping its data unfragmented, and not everyone has SSDs.
T3RMINATED 10y ago
How about just switching to Chrome.
weatherlight 10y ago
Spotify does some pretty evil I/O as well. https://community.spotify.com/t5/Desktop-Linux-Windows-Web-Player/Why-does-Spotify-use-such-a-ridiculous-amount-of-disk-I-O-Writes/td-p/1130146 https://community.spotify.com/t5/Desktop-Linux-Windows-Web-P...
zx2c4 10y ago
I have fixed this issue forever. I got a Thinkpad P50 with 64 gigs of ram. So, I just mount a tmpfs over ~/.cache. I actually use a tmpfs for a few things: $ grep tmpfs /etc/fstab tmpfs /tmp tmpfs nodev,nosuid,mode=1777,noatime 0 0 tmpfs /var/tmp/portage tmpfs noatime 0 0 tmpfs /home/zx2c4/.cache tmpfs noatime,nosuid,nodev,uid=1000,gid=1000,mode=0755 0 0
- Yoric 10y ago
  Fwiw, Session Restore doesn't hit ~/.cache at all. (Afaict, I'm the last person who changed how Session Restore writes its files).
- saynsedit 10y ago
  Are these writes happening in ~/.cache?
yashafromrussia 10y ago
Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?
yashafromrussia 10y ago
Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?
yashafromrussia 10y ago
Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?
nashashmi 10y ago
On a related note: also see http://windows7themes.net/en-us/firefox-memory-cache-ssd/ http://windows7themes.net/en-us/firefox-memory-cache-ssd/ Just another firefox ssd optimization. Edit: And see bernaerts.dyndns.org/linux/74-ubuntu/212-ubuntu-firefox-tweaks-ssd It talks about sessionstore.
Someone 10y ago
12GB/day is about 140kB/second, or one Apple 2 floppy disk every second. It also is about single CD speed (yes, you could almost record uncompressed stereo CD quality audio all day round for that amount of data) All to give you back your session if your web browser crashes or is crashed. Moore's law at its best.
towerbabbel 10y ago
I observed something similar several years ago: http://www.overclockers.com/forums/showthread.php/697061-Where-those-writes-to-the-SSD-comes-from http://www.overclockers.com/forums/showthread.php/697061-Whe... I still think the worry about it wearing out an SSD is overblown. The 20GB per day of writes is extremely conservative and mostly there to avoid more pathological use cases. Like taking a consumer SSD and using it as the drive for some write heavy database load with 10x+ write amplification and when you wear it out demand a new one on warranty. Backing up the session is still sequential writes so write amplification is minimal. After discovering the issue I did nothing and just left Firefox there wearing on my SSD. I'll still die of old age before Firefox can wear it out.
Animats 10y ago
Firefox is relying too much on session restore to deal with bugs in their code. Firefox needs to crash less. With all the effort going into multiprocess Firefox, Rust, and Servo, it should be possible to have one page abort without taking down the whole browser. About half the time, session restore can't restore the page that crashed Firefox anyway.
- Manishearth 10y ago
  IIRC per-tab e10s already exists, just isn't enabled by default yet because it has some rough edges. The Rust part of your comment is irrelevant. There is Rust code shipping in Firefox, but nowhere near the amount needed for observable changes in behavior. Work is being done to put larger components in but nothing is shipping yet. Also, IME most crashes are asserts (in all browsers) and that's not a problem Rust fixes. If you get a segfault-based crash please report it, it could be exploitable. (report normal crashes too, really)
  - Animats 10y ago
    If process-per-tab is enabled, can each tab crash separately, or does the whole browser still have to go down?
    - Manishearth 10y ago
      They should crash separately. I'm not sure of the details.
    - Manishearth 10y ago
      It seems like the dom.ipc.processCount setting sets the total number of content processes to use. Note that this means that tabs will share content processes, so a crash in one tab may crash a few others. You can reduce this by ramping up the number of processes, though that can lead to bloat. No idea how stable this is right now. For me, on Dev Edition with regular multiprocess mode enabled, things work fine and I don't get crashes.
- c3833174 10y ago
digi_owl 10y ago
I do wonder if their mobile version have a similar problem. I have noticed it chugs badly when opened for the first time in a while on Android, meaning i have to leave it sitting or a while so it can get things done before i can actually browse anything.
- darkhorn 10y ago
  I've disabled images and JavaScript on mobile Firefox. When I'm only interested on reading I use Firefox. Otherwise I use Google Chrome.
  - digi_owl 10y ago
    Thats the thing, it has nothing to do with page rendering. It kicks in about 10-15 seconds after initial launch of the browser, and basically churns it to a near halt for at least 30 seconds before it becomes usable. Could be that this tablet of mine provokes the behavior by having a slow emmc that is nearly full, but it has resulted in me minimizing my use of a browser i have been using for close to a decade across various computers and operating systems. And no, it has nothing to do with extensions. I still see it with no extensions active. Heck, i even see it with guest mode active.
    - holygoat 10y ago
      Do you have Sync enabled? If you can grab an adb log, come post it in #mobile on irc.mozilla.org.
      - digi_owl 10y ago
        Yep, i have sync enabled. Grabbing a adb log may be a bit out of my league though.
iask 10y ago
So Firefox is also expensive to run in terms of energy consumption. No wonder the fans on my MacBook Pro always sound like a jet engine whenever I have several tabs open. Seriously! Disclaimer: I dual boot (camp) windows 7 on my mac.
- cwillu 10y ago
  I doubt the cpu load of session restore is responsible for the fans kicking in...
  - iask 10y ago
    Well I must say, I certainly changed my settings to 45 minutes and OMG! fans haven't spin up loudly since. Wow!
falsedan 10y ago
Using a display font for body text--
joosters 10y ago
Does firefox sync() the data? If not, these continuous overwrites of the same file may not even hit the disk at all, as it could all end up being cached. Even if some data is being written, it could still be orders of magnitude lower than the writes executed by the program. There are legitimate pros/cons of using sync() or not. Missing it out could mean that the file data is lost if your computer crashes. But if firefox crashes by itself, the data will be safe.
- holygoat 10y ago
  sessionstore does not sync.
- cwillu 10y ago
  fsync() is a very different thing from sync(), and it's the former that is relevant here. ext3 configured in a manner that used to be popular had a side effect of making fsync() require nearly as much io as sync, which is probably where the confusion comes from.
tesla23 10y ago
I'am sorry if I drop it, but it seems not many people know about cache poisoning. I have always kept the suggested settings since the age of javascript.
vamur 10y ago
Using private mode and a RAM disk is a quick solution for this issue. Easy to setup on Linux and there is a free RAM disk utility on Windows as well.
gcb0 10y ago
> goes to the point of installing weird programs to be "pro" about their ssd life > failed to read the very first recommendation on every single guide for ssd life: use ram disk cache for browser temp files. yeah, let's upvote this
bikamonki 10y ago
Can this be avoided in FF and Chrome with private tabs?
Falkon1313 10y ago
I checked my system - Firefox wasn't writing much and what it is writing is going to my user directory on the hard drive instead of the program directory on the SSD, so that's nice. But still, I don't want my browser cluttering up my drive with unnecessary junk - history, persistent caching from previous sessions, old tracking cookies, nevermind a constant backup of the state of everything. I try to turn all that off, but there's always one more hidden thing like this. If I want to save something, I'll download it. If I want to come back, I'll bookmark it. Other than those two cases and settings changes, all of which are triggered by my explicit choice & action, it really shouldn't be writing/saving/storing anything. Would be nice if there were a lightweight/portable/'clean' option or version. When I tried Spotify, it was pretty bad about that too - created many gigabytes of junk in the background and never cleaned up after itself. I made a scheduled task to delete it all daily, but eventually just stopped using spotify.
- db48x 10y ago
  It's overwriting a few files when the data they contain changes; it's not leaving a huge pile of unused data to clutter up your disk.
waldbeere 10y ago
Simple solution change save time to 30s Windows file compression cookies.sqlite => 1MB => 472KB sessionstore-backups => 421 KB => 204 KB Move TMP cach folder to ram drive ie ImDisk
rasz_pl 10y ago
For comparison ancient Opera Presto stores about 500 bytes per tab in Session file.
known 10y ago
https://wiki.archlinux.org/index.php/Firefox_tweaks https://wiki.archlinux.org/index.php/Firefox_tweaks is worth skimming
deleted 10y ago
[deleted]

477 points by kungfudoi 10y ago

Wow, that's really unfortunate. I just built a new PC with SSDs, and switched back to Firefox. Even with 16GB of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or try to scroll. This new issue of it prematurely wearing out my SSDs will just push me to Chrome. Hopefully it doesn't have the same issues.

overcast 10y ago
You need to enable multiprocess in Firefox, so the thing doesn't shit the bed on you constantly. https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis
- theandrewbailey 10y ago
  Look out for addons. Electrolysis will still not work with many of them. I force enabled it a few weeks ago, and discovered that it's disabled for good reasons.
  - overcast 10y ago
    Have about ten plugins, no issues here. It's worth actually having a browser that doesn't consume all available resource.
- joecool1029 10y ago
  Heh. Tried that out and while it didn't affect stability it made switching tabs take 2-3s on a haswell system. By disabling all extensions with it I was able to somewhat match performance of non-multiprocess.
- anexprogrammer 10y ago
  Nice idea but a load of useful extensions don't work with it. Of extensions I use noscript and 1password were the main ones, but around half were tagged as not compatible.
__jal 10y ago
My home desktop is an i5-1620 with 64G RAM running Ubuntu 16.04, and Firefox just hiccups and lags, period. It is sad. I need to find time to experiment with Chrome while blocking all the Google chatter to see how functional it remains without being able to tattle to the mothership (otherwise I won't use it).
- SubiculumCode 10y ago
  Hiccups and lags are seen in all browsers and is due to bloated websites. Also, Chrome will write just as much to your SSD as Firefox
- brianwawok 10y ago
  Why not Chromium?
  - CaptSpify 10y ago
    I personally wouldn't recommend chromium because they've been known to do some shady things: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 I'd imagine someone like the above poster would be concerned about that. At least I know I am
- rasz_pl 10y ago
  Try Vivaldi.
wodenokoto 10y ago
I have an old dual core with 4 gigs of ram and Firefox runs better than chrome.
superkuh 10y ago
Try out the Pale Moon firefox forks. I'm running it on an old core2duo 6400 (2.13 GHz) with 8 GB ram. I have over 700 tabs in my session right now with at least 300 of them fully loaded. It's using less than 3GB ram. And it's fast/snappy with smooth scrolling.
Manishearth 10y ago
According to the blog post Chrome has the same issue, they just haven't investigated yet.

vesinisa 10y ago

I've already moved all my browser profiles to `/tmp` and set up a bootscripts to persist them during boot / shutdown. E.g. for Arch Linux see https://wiki.archlinux.org/index.php/profile-sync-daemon https://wiki.archlinux.org/index.php/profile-sync-daemon This is a far superior solution to fiddling with configuration options in each individual product to avoid wearing down your SSD with constant writes. Murphy's law has it such hacks will only be frustrated by next version upgrade. And no, using Chrome does not help. All browsers that use disk caching or complex state on disk are fundamentally heavy on writes to an SSD. The amount of traffic itself is not even a particularly good measure of SSD wear, since writing a single kilobyte of data on an SSD can not be achieved on HW level without rewriting the whole page, which is generally several megabytes in size. So changing a single byte in a file is no less taxing than a huge 4 MB write.

RussianCow 10y ago

Serious question: Is 12GB a day really going to make a dent in your SSD's lifespan? I was under the impression that, with modern SSDs, you basically didn't have to worry about this stuff.

gcp 10y ago
Samsung's low cost line is under warranty up to 40TB/year. Tests have shown that the actual drive lifetime is several times that. So basically, no, you don't have to worry about this. Essentially, people are complaining that the disks they bought are being used for their intended purpose: making sure your data doesn't disappear on a power loss.
- dogma1138 10y ago
  Not everyone buys Samsung, there are a lot of cheap SSD's out there that are rated for only a handful of TB's a year. There is also a case of the silly SSHD's or w/e which combine a tiny SSD and a mechanical component which can die considerably faster. Overall the amount of writes an SSD can handle is tied directly to it's capacity since it determines the amount of average writes per a given time unit that each cell will experience as long as the firmware actually does it's job (in Samsung's case it may very well not do it as they had more than a few firmware screw ups in the past). This can also more severely affect you if you have a medium sized drive (say 128-256GB) but it's pretty full. A good SSD's will move things around somewhat to even out the wear but it still increases the amount of writes you have. If your SSD does have an "even wear" feature when you write 12GB to drive which is say 50% or more full it usually triggers more than 12GB of effective writes in the drive itself as the firmware would move already written data around to ensure that every cell has been written to approximately the same amount (if you say only have 20GB of free space and you write 12GB daily and delete it, your effective writes would be closer to the full capacity of the drive per day than to 12GB). You also have a lot of embedded/mobile devices which use considerably shittier storage than modern SSD's, you can easily chew through a SD card or a similarly rated flash storage with anywhere between a few 100's of gigs to only a handful of TB's (or a only few times the capacity of the card if buy bargain bin memory cards). Since these machines are more commonly used these days it's not a feature that should be so quickly obfuscated from the user since it doesn't seem like there is an "intelligence" behind how conservative or not the browser is with writes to local storage. If you install firefox on an SBC/netbook/microcomputer or even a mobile phone (if this affects the mobile version also) with eMMC/MMC only rated storage 12 gigs a day can and will kill it rather quickly.

blinkingled 10y ago

Even better just disable session restore entirely - Browser.sessionstore.enabled - Since Firefox 3.5 this preference is superseded with setting browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0. As I understand this feature is there so if the browser crashes it can restore your windows and tabs - I don't remember having a browser crash on me since the demise of Flash.

gcp 10y ago
It'll also cover OS crashes or power failures. Agreed that those aren't very common either.
LukeShu 10y ago
Other things than a browser crash can cause the browser to unexpectedly quit. For example, a battery dying, or the power going out.
- blinkingled 10y ago
  Right but that doesn't happen quite often either. Also if it does how important is restoring the tabs and windows? Probably not to a lot of people other than serious creators that use a web editor of some sort that'll lose work if the browser disappears. Even then it is flaky to rely on something like this. Much better to have periodic backups of whatever you're doing.
  - froydnj 10y ago
    You say "doesn't happen quite often", which I'm assuming means something like "doesn't happen quite often to me". But if you consider hundreds of millions of users using Firefox every day, then even a relatively rare event is happening to multiple users every single day. It is absolutely worth it to them that Firefox does its best to preserve their data.
    - Dylan16807 10y ago
      You have a point, but power outages are very correlated.

lighttower 10y ago

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. [1] https://launchpad.net/~graysky/+archive/ubuntu/utils https://launchpad.net/~graysky/+archive/ubuntu/utils [2] https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon EDIT: Add link, grammar EDIT2: Add link to source

pawadu 10y ago
What is the typical memory usage of this for normal web browsing?
- lighttower 10y ago
  `mount -l` shows a filesystem of type `overlay` for each browser (in my case, chromium, chrome, firefox). Range from 50MB to 200MB. I have it to sync to disc every 15min - so I reckon it empties out the ram whenever it syncs. I've never had a problem (8GB of ram on the machine I initially installed it on) so I haven't watched to see what the max size is. The developer [1] is great - issues are resolved very quickly. [1] https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon
- codemac 10y ago
  Mine uses the following with firefox: overlaid 2.0G 128M 1.9G 7% /run/user/1000/codemac-firefox-3ckuo4v7.default
lucb1e 10y ago
Launchpad is such a shitty website, aimed at Ubuntu and only Ubuntu, links to source code or more information are nowhere to be found... Searching on Github, this seems to be it. Turns out, there's releases for Arch, Debian, etc. and it's even in the repositories. No need to add a ppa. https://github.com/graysky2/profile-sync-daemon https://github.com/graysky2/profile-sync-daemon For Debian and co: $ apt-cache show profile-sync-daemon $ sudo apt-get install profile-sync-daemon

dogma1138 10y ago

heh https://news.ycombinator.com/item?id=12437309 https://news.ycombinator.com/item?id=12437309

leeoniya 10y ago

i'm not seeing these numbers, using I/O columns in Process Explorer. i'm running Nightly Portable with maybe 80 tabs open/restored.

gcp 10y ago
Nightly Portable might have this particular setting changed, because the lifetime of random USB sticks is surely going to be much less than a real SSD.
- leeoniya 10y ago
  i thought that too but the interval setting is at 15000 in the config, so maybe something else is optimizing it out?
mrpopo 10y ago
I'm not seeing these numbers either and I'm running Firefox 49. In the resource monitor, I see firefox writing to disk 10kB every 15 sec. I bet there is something else to the story of this guy.
deleted 10y ago
[deleted]

rayiner 10y ago

Doing all this work is also probably burning battery life. An SSD can use several watts while writing, versus as low as 30-50 milliwatts at idle (with proper power management).

eikenberry 10y ago
+1. This is why I use PSD (mentioned above) to mitigate this. A RAM cache will use much less power than constant disk writes.
dclowd9901 10y ago
Can confirm closing chrome typically doubles my battery life.

kordless 10y ago

I seriously dislike Firefox, but must use it at work due to browser incompatibility issues with Chrome and sites I use heavily. Anything that makes the experience better is much appreciated.

tonmoy 10y ago
If is perfectly valid for you to dislike Firefox. But in the context of this post it seems that you assume Chrome is better than FF in terms of disc usage. Do you have any data to back that claim up?

deleted 10y ago

[deleted]

rsync 10y ago

I continue to be impressed with the content and community at servethehome - it's slowly migrated its way into my daily browsing list.

raverbashing 10y ago

Are these writes being sync'd to disk? Because FF may die but the OS will save it later. That's fine Not every write to a file means a write to disk

holygoat 10y ago
sessionstore does not fsync.

aylons 10y ago

In Linux where should this be written? Inside the home folder? Maybe moving this folder to a HDD should suffice.

expression 10y ago
Or ramdisk if you have a stable system.
- marcosdumay 10y ago
  That would lose the point of a recovery system. I'd rather just turn it off.
  - onnoonno 10y ago
    I have easily more than 100 firefox crashes for each kernel crash, and I guess that is similar for other people(?) So I think the session restore is almost always used in a case where firefox crashed, but the system is fine.
gcp 10y ago
Why would you not want to use your SSD for what it's meant for?
- CaptSpify 10y ago
  Maybe because they would rather not have their ssd constantly being hit? Seems reasonable to me to move this is you have concerns about the longevity, or maybe IO bottlenecks.
- aylons 10y ago
  Some things are in the SSD, others on the HDD. This seems to wear the SSD while being seldomly used. Looks like a good case for HDD.

alyandon 10y ago

Yep, I have a brand new SSD drive that over the course of a few months accumulated several TERAbytes (yes - TERA) of writes directly attributable to the default FF browser session sync interval coupled with the fact I leave it open 24/7 with tons of open tabs. Once I noticed that excessive writes were occurring, it was easy for me to identify FF as the culprit in Process Hacker but it took much longer to figure out why FF was doing it.

caiob 10y ago

That goes to show how space/memory hungry and bloated browsers have become.

robin_reala 10y ago

It’s always annoying when an issue like this is reported yet no bugzilla reports are mentioned. Has anyone else filed this already, or shall I?

tekacs 10y ago
If it's not already listed there, please do (and post the URL here!) I was thinking the same and will do so myself, if no-one else reports doing so.
gcp 10y ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1304389 https://bugzilla.mozilla.org/show_bug.cgi?id=1304389

CoryG89 10y ago

Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? Seems like it should only write after a user action or if the open page writes to storage? Even if it was necessary to write continually while idle, how could it possibly consume so much data in such a short period of time?

gcp 10y ago
Maybe I am not understanding this right, but is this saying that Firefox will continually keep writing to the disk while idle? Does anyone know more about this? Why would this be needed to restore session/tabs? This is very much the feature working as intended: Firefox captures webpage state every 15 seconds, so a crash, power outage, accidentally closing the browser etc will not result in data loss for the user. For storing the data persistently, it uses the persistent storage, i.e. your harddrive. For the HN crowd, that's going to be an SSD. The SSD can easily deal with the resulting write traffic with negligible effect on its lifetime - I have no idea why people even think this is an issue. Seems like it should only write after a user action or if the open page writes to storage Webpages can change their contents or state without user interaction. Webpages are also big and bloated. Storing a little data, all the time, 24/7, adds up over time to a surprisingly large number.
- CoryG89 10y ago
  I understand that pages can change their state without user interaction, but shouldn't the browser only write to disk when that actually happens? The browser has to be able to detect when these changes happen right? I understand that it's probably not an issue for most users/SSDs. However, if I open just a static HTML file and leave it idle, I don't think the browser should be continually writing to disk. If it is, then to me that is a bug. EDIT: Also, it seems like when I remember restoring a browser session after a crash, all the tabs get reloaded, not restoring the page state, just the tabs/URLs (ie. browser makes new request(s) for each restored tab). I usually use Chrome though, not sure if this has happened to me on Firefox.

amq 10y ago

Observed similar behavior with Skype.

deleted 10y ago

[deleted]

tsukikage 10y ago

The interesting question here is, why is the browser writing data to disk at this rate? If it's genuinely receiving new data at this rate, that's kind of concerning for those of us on capped/metered mobile connections. The original article mentions that cookies accounted for the bulk of the writes, which is distressing. If it's not, using incremental deltas is surely a no-brainer here?

gcp 10y ago
If it's not, using incremental deltas is surely a no-brainer here? Might be surprisingly hard or inefficient given that you're trying to capture "webpage state". Think about React sites etc.

zbuf 10y ago

I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. I feel it's little antisocial for regular desktop apps to assume it's for them to do this. Chrome is also a culprit, a similar sync'ing caused us problems at my employer's, inflated pressure on an NFS server where /home directories are network mounts. Even where we already put the cache to a local disk. At the bottom of these sorts of cases I have on more than one occasion found an SQLite database. I can see its benefit as a file format, but I don't think we need full database-like synchronisation on things like cookie updates; I would prefer to lose a few seconds (or minutes) of cookie updates on power loss than over-inflate the I/O requirements.

jstimpfle 10y ago
> I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op. For completeness, this is probably the eatmydata command.
robbles 10y ago
Would you be willing to post a how-to or example of doing this? I'm curious about how this trick works!
- necessity 10y ago
  It's probably best to just disable sessionstore if you don't want it, as overwriting fsync would disable it for all operations Firefox might use, not just sessionstore.
  - zbuf 10y ago
    That's exactly what I wanted to achieve; I didn't have the time or inclination to work out exactly which part of Firefox is responsible. In my case it was not SSD wear I wanted to reduce, but the short pauses during interactive use.
- zbuf 10y ago
  Take a look at libeatmydata. I'm doing something practically identical

Nursie 10y ago

Firefox has been terrible for disk access for many years. I remember I had a post install script (to follow, I never actually automated) that I would run through in my linux boxes back in about 2003 that would cut down on this and speed up the whole system. Basically chattr +i on a whole bunch of its files and databases, and everything's fine again...

gcp 10y ago
There's been some development the last 13 years. Chrome was also pretty crappy in 2003. /s
- Klathmon 10y ago
  well, i'd say it was crappy in 2003, it wouldn't even exist for another 5 years ;)
- Nursie 10y ago
  Oh there's been lots. Looks like it's still incredibly write-happy though.

rackforms 10y ago

Putting aside how this may not be all that bad for most SSD's, does anyone know when this behavior started? Firefox really started to annoy me with its constant and needless updates a few months back; the tipping point being breaking almost all legacy extensions (in 46, I believe). This totally broke the Zend Debugger extension, the only way forward would be to totally change my development environment. I'm 38 and now, and apparently well beyond the days when the "new and shiny" hold value. These days I just want stability and reliability. Firefox keeps charging forward and, as far as I can tell, has brought nothing to the table except new security issues and breaking that which once worked. I haven't updated since 41 and you know what, it's nearly perfect. It's fast, does what I need it to do, and just plain old works. Firefox appears to have become a perfect example of developing for the sake of.

Freestyler_3 10y ago
This has been the case for a long time, I just googled and first hit was an article from 2008. source: http://www.ghacks.net/2008/07/09/change-the-session-store-interval-in-firefox/ http://www.ghacks.net/2008/07/09/change-the-session-store-in...
- ashark 10y ago
  Wikipedia claims the session restore features was added with 2006's 2.0 release. That's what I would have guessed, since that release was (famously) a giant step backwards in performance, which was never really addressed except by waiting for hardware to improve. I'm holding out hope that whoever's responsible for Firefox abandoning "good, light, cross-platform web browser" as its differentiator stays away from Servo, at least for a while. That's a niche that's unserved currently, AFAIK.
gcp 10y ago
Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox. If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.

Freestyler_3 10y ago

I use Opera on windows, No idea how to check or change the session storage interval. Anyone got ideas on that?

PaulHoule 10y ago

The whole "restore your session" thing is the one of the most user hostile behaviors there is.

justinrstout 10y ago

Theodore Ts'o wrote about a similar Firefox issue back in 2009: https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

Yoric 10y ago

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. I hope we can get around to doing it someday. Of course, as usual in an open-source project, contributors welcome :)

nograpes 10y ago
What would an updated version of Session Restore look like? I mean, what would be your vision for a new version?
- Yoric 10y ago
  I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant for this scale of data; - we wouldn't need to rewrite x Mb of data every 15 seconds, just a per-tab update; - if we're using a relational database, it would be easier to trust the code to not screw up with the data; - we wouldn't need to load the entire Session Restore upon startup. (On the minus side, this might make backups a bit more complicated.) On the front-end, we would need a high-level API for Session Restore, which would let us do things such as accessing per-tab data, (de)hibernating tabs, etc. Oh, and it would need to be accessible by WebExtensions. In the middle, we would need to re-engineer Session Restore to make sure that we don't need to maintain this huge object representing the entire state of the session. We would also need improvements e.g. to cookie management, to avoid having to re-collect cookies so often.
  - Dylan16807 10y ago
    How does that much data get into Session Restore? Mine are only about 3KB per tab, and Firefox starts melting at more than a thousand tabs.

Sami_Lehtinen 10y ago

uBlock also keeps writing "hit counts" to disk all the time, as well as for some strange reason they've chose database page size to be 32k so each update writes at least 32kB.

gcp 10y ago
Smaller block sizes caused large performance issues. SQLite isn't very good at keeping its data unfragmented, and not everyone has SSDs.

T3RMINATED 10y ago

How about just switching to Chrome.

weatherlight 10y ago

Spotify does some pretty evil I/O as well. https://community.spotify.com/t5/Desktop-Linux-Windows-Web-Player/Why-does-Spotify-use-such-a-ridiculous-amount-of-disk-I-O-Writes/td-p/1130146 https://community.spotify.com/t5/Desktop-Linux-Windows-Web-P...

zx2c4 10y ago

I have fixed this issue forever. I got a Thinkpad P50 with 64 gigs of ram. So, I just mount a tmpfs over ~/.cache. I actually use a tmpfs for a few things: $ grep tmpfs /etc/fstab tmpfs /tmp tmpfs nodev,nosuid,mode=1777,noatime 0 0 tmpfs /var/tmp/portage tmpfs noatime 0 0 tmpfs /home/zx2c4/.cache tmpfs noatime,nosuid,nodev,uid=1000,gid=1000,mode=0755 0 0

Yoric 10y ago
Fwiw, Session Restore doesn't hit ~/.cache at all. (Afaict, I'm the last person who changed how Session Restore writes its files).
saynsedit 10y ago
Are these writes happening in ~/.cache?

yashafromrussia 10y ago

Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?

yashafromrussia 10y ago

Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?

yashafromrussia 10y ago

Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?

nashashmi 10y ago

On a related note: also see http://windows7themes.net/en-us/firefox-memory-cache-ssd/ http://windows7themes.net/en-us/firefox-memory-cache-ssd/ Just another firefox ssd optimization. Edit: And see bernaerts.dyndns.org/linux/74-ubuntu/212-ubuntu-firefox-tweaks-ssd It talks about sessionstore.

Someone 10y ago

12GB/day is about 140kB/second, or one Apple 2 floppy disk every second. It also is about single CD speed (yes, you could almost record uncompressed stereo CD quality audio all day round for that amount of data) All to give you back your session if your web browser crashes or is crashed. Moore's law at its best.

towerbabbel 10y ago

I observed something similar several years ago: http://www.overclockers.com/forums/showthread.php/697061-Where-those-writes-to-the-SSD-comes-from http://www.overclockers.com/forums/showthread.php/697061-Whe... I still think the worry about it wearing out an SSD is overblown. The 20GB per day of writes is extremely conservative and mostly there to avoid more pathological use cases. Like taking a consumer SSD and using it as the drive for some write heavy database load with 10x+ write amplification and when you wear it out demand a new one on warranty. Backing up the session is still sequential writes so write amplification is minimal. After discovering the issue I did nothing and just left Firefox there wearing on my SSD. I'll still die of old age before Firefox can wear it out.

Animats 10y ago

Firefox is relying too much on session restore to deal with bugs in their code. Firefox needs to crash less. With all the effort going into multiprocess Firefox, Rust, and Servo, it should be possible to have one page abort without taking down the whole browser. About half the time, session restore can't restore the page that crashed Firefox anyway.

Manishearth 10y ago
IIRC per-tab e10s already exists, just isn't enabled by default yet because it has some rough edges. The Rust part of your comment is irrelevant. There is Rust code shipping in Firefox, but nowhere near the amount needed for observable changes in behavior. Work is being done to put larger components in but nothing is shipping yet. Also, IME most crashes are asserts (in all browsers) and that's not a problem Rust fixes. If you get a segfault-based crash please report it, it could be exploitable. (report normal crashes too, really)
- Animats 10y ago
  If process-per-tab is enabled, can each tab crash separately, or does the whole browser still have to go down?
  - Manishearth 10y ago
    They should crash separately. I'm not sure of the details.
  - Manishearth 10y ago
    It seems like the dom.ipc.processCount setting sets the total number of content processes to use. Note that this means that tabs will share content processes, so a crash in one tab may crash a few others. You can reduce this by ramping up the number of processes, though that can lead to bloat. No idea how stable this is right now. For me, on Dev Edition with regular multiprocess mode enabled, things work fine and I don't get crashes.
c3833174 10y ago

digi_owl 10y ago

I do wonder if their mobile version have a similar problem. I have noticed it chugs badly when opened for the first time in a while on Android, meaning i have to leave it sitting or a while so it can get things done before i can actually browse anything.

darkhorn 10y ago
I've disabled images and JavaScript on mobile Firefox. When I'm only interested on reading I use Firefox. Otherwise I use Google Chrome.
- digi_owl 10y ago
  Thats the thing, it has nothing to do with page rendering. It kicks in about 10-15 seconds after initial launch of the browser, and basically churns it to a near halt for at least 30 seconds before it becomes usable. Could be that this tablet of mine provokes the behavior by having a slow emmc that is nearly full, but it has resulted in me minimizing my use of a browser i have been using for close to a decade across various computers and operating systems. And no, it has nothing to do with extensions. I still see it with no extensions active. Heck, i even see it with guest mode active.
  - holygoat 10y ago
    Do you have Sync enabled? If you can grab an adb log, come post it in #mobile on irc.mozilla.org.
    - digi_owl 10y ago
      Yep, i have sync enabled. Grabbing a adb log may be a bit out of my league though.

iask 10y ago

So Firefox is also expensive to run in terms of energy consumption. No wonder the fans on my MacBook Pro always sound like a jet engine whenever I have several tabs open. Seriously! Disclaimer: I dual boot (camp) windows 7 on my mac.

cwillu 10y ago
I doubt the cpu load of session restore is responsible for the fans kicking in...
- iask 10y ago
  Well I must say, I certainly changed my settings to 45 minutes and OMG! fans haven't spin up loudly since. Wow!

falsedan 10y ago

Using a display font for body text--

joosters 10y ago

Does firefox sync() the data? If not, these continuous overwrites of the same file may not even hit the disk at all, as it could all end up being cached. Even if some data is being written, it could still be orders of magnitude lower than the writes executed by the program. There are legitimate pros/cons of using sync() or not. Missing it out could mean that the file data is lost if your computer crashes. But if firefox crashes by itself, the data will be safe.

holygoat 10y ago
sessionstore does not sync.
cwillu 10y ago
fsync() is a very different thing from sync(), and it's the former that is relevant here. ext3 configured in a manner that used to be popular had a side effect of making fsync() require nearly as much io as sync, which is probably where the confusion comes from.

tesla23 10y ago

I'am sorry if I drop it, but it seems not many people know about cache poisoning. I have always kept the suggested settings since the age of javascript.

vamur 10y ago

Using private mode and a RAM disk is a quick solution for this issue. Easy to setup on Linux and there is a free RAM disk utility on Windows as well.

gcb0 10y ago

> goes to the point of installing weird programs to be "pro" about their ssd life > failed to read the very first recommendation on every single guide for ssd life: use ram disk cache for browser temp files. yeah, let's upvote this

bikamonki 10y ago

Can this be avoided in FF and Chrome with private tabs?

Falkon1313 10y ago

I checked my system - Firefox wasn't writing much and what it is writing is going to my user directory on the hard drive instead of the program directory on the SSD, so that's nice. But still, I don't want my browser cluttering up my drive with unnecessary junk - history, persistent caching from previous sessions, old tracking cookies, nevermind a constant backup of the state of everything. I try to turn all that off, but there's always one more hidden thing like this. If I want to save something, I'll download it. If I want to come back, I'll bookmark it. Other than those two cases and settings changes, all of which are triggered by my explicit choice & action, it really shouldn't be writing/saving/storing anything. Would be nice if there were a lightweight/portable/'clean' option or version. When I tried Spotify, it was pretty bad about that too - created many gigabytes of junk in the background and never cleaned up after itself. I made a scheduled task to delete it all daily, but eventually just stopped using spotify.

db48x 10y ago
It's overwriting a few files when the data they contain changes; it's not leaving a huge pile of unused data to clutter up your disk.

waldbeere 10y ago

Simple solution change save time to 30s Windows file compression cookies.sqlite => 1MB => 472KB sessionstore-backups => 421 KB => 204 KB Move TMP cach folder to ram drive ie ImDisk

rasz_pl 10y ago

For comparison ancient Opera Presto stores about 500 bytes per tab in Session file.

known 10y ago

https://wiki.archlinux.org/index.php/Firefox_tweaks https://wiki.archlinux.org/index.php/Firefox_tweaks is worth skimming

deleted 10y ago

[deleted]