Sări la conţinut

Speed up Firefox by mounting the profile in tmpfs [Linux only]

4 ianuarie, 2009

tmpfs is a virtual, RAM-backed filesystem. It’s lightning-fast, but since it’s RAM-backed, any file written to tmpfs uses precious memory while it’s there, and the entire contents of the virtual partition are lost on shutdown or crash. The good news is that these detriments can be minimized, making tmpfs a viable choice for your profile directory. This document gives some tips on how to mount your Firefox profile in a tmpfs partition while minimizing the downsides of tmpfs.

Step 1. Reduce the size of your profile directory.


tmpfs is RAM-backed, so we want to conserve memory by trimming the fat from the profile. I recommend making the following config changes (enter ‘about:config’ in the Firefox address bar):

set browser.cache.disk.capacity to 20000 or thereabouts
set browser.safebrowsing.enabled to false
set browser.safebrowsing.malware.enabled to false

The first one reduces the size of the disk cache to about 20 MB, down from 50MB. It might be tempting to turn disk cache off entirely, but I’ve encountered poor performance doing that in the past; I think that the caching algorithm has to be able to push things into disk cache for best performance, even if they won’t stay there long.

The last two disable the collection of the information in the ‘urlclassifier*.sqlite’ files. These hold Firefox’s database of suspected malware or phishing sites, and while most users will feel comfortable turning this off, it does in theory leave you more vulnerable to these types of attacks. There’s a known bug in Firefox which can make these files grow quickly; on my system, they were 70MB total.

After you’ve changed these settings, clear the cache in Firefox and delete the urlclassifier*.sqlite files from your profile directory. (SQLite will recreate empty databases but they’ll stay at 32k.)

Step 2. Edit the fstab and prepare the backup tarball.

First, create a tarball of your profile as it currently stands.

Code:
$ cd
$ cd .mozilla/firefox
$ tar cpf packed.tar abcd1234.default

abcd1234.default should be replaced by your profile directory name here and below.

Now edit /etc/fstab and add a line like this:

Code:
firefox /home/steven/.mozilla/firefox/abcd1234.default tmpfs size=128M,noauto,user,exec,uid=1000,gid=100 0 0

You’ll have to adjust path components, uid and gid.

Step 3. Set up a backup and restore script.

This is an example, but is by no means the only way to do it. I’ll assume you’ve named the script “${HOME}/.pack_ffox.sh” in future commands, so replace that with whatever you decide to do.

Code:
#!/bin/bash# Change this to match your correct profile
PROFILE=”abcd1234.default”cd “${HOME}/.mozilla/firefox”if test -z “$(mount | grep -F “${HOME}/.mozilla/firefox/${PROFILE}” )”
then
mount “${HOME}/.mozilla/firefox/${PROFILE}”
fiif test -f “${PROFILE}/.unpacked”
then
tar –exclude ‘.unpacked’ -cpf packed.tmp.tar “$PROFILE”
mv packed.tar packed.tar.old
mv packed.tmp.tar packed.tar
else
tar xpf packed.tar &&\
touch “${PROFILE}/.unpacked”
fi

This script will load your firefox profile if it hasn’t been loaded, and save it otherwise (keeping one backup copy from a few minutes ago in case of file corruption or the like). Once you’ve got it saved, you’ll need to quit Firefox for this next step. Open in links, copy and paste to a text editor, or just remember the steps.

Step 4. Switch over.

With Firefox closed, you need to empty your profile directory. Either move the files currently in there to a new folder, or simply erase them (remember, a copy is in packed.tar as well). Be sure to leave the empty profile directory there for the tmpfs mount point.

Now, run the script:

Code:
$ “${HOME}/.pack_ffox.sh”

Verify that your profile directory is now mounted on tmpfs, that your files got correctly unpacked, and that the file .unpacked exists inside of your profile directory.

Now run the script again, exactly as before. This time, it will detect that your profile’s been unpacked and is ready to use, and create a new packed.tar. If it worked, you should now have the file “.mozilla/firefox/packed.old.tar” as well.

If both of those things checked out, you’re clear to start Firefox again.

I recommend adding the command to your .xinitrc or desktop-environment-specific startup settings, so that it’s ready to go when you log in. It’s also critical that you run it again before you shut down your computer, or you’ll lose all changes. One of the safest ways for users on media that doesn’t have limited write-cycles is to simply add an entry to the crontab which runs the script every five minutes. Run this command to edit the crontab:

Code:
# crontab -u USERNAME -e

which will bring up your editor. Add a line akin to this one:

Code:
*/5 * * * * $HOME/.pack_ffox.sh

Check in five minutes to make sure the mtime of packed.tar has changed, indicating that the script is working [just right click the tarball and look when it was last modified].

Notes:

I use Ubuntu, and for me some of the steps above had to be changed a little. For example, my FF profile was much bigger because of the many extensions i have installed, so i change the partition size to 200, so you can change the size to your needs as well.

To set up the crontab in Ubuntu, i just wrote: “crontab -e” in a terminal and added the line “*/5 * * * * $HOME/.pack_ffox.sh” [without the quotes]

I found this on the gentoo.org forum.

See also:

How to install Firefox 3.1 beta 2 in Ubuntu from repositories
Export your Firefox 3.0 full profile to Firefox 3.1 (including all addons, themes, cookies, passwords, etc)

Other articles tagged with:

-Firefox
-Linux

About these ads
10 comentarii
  1. Delta permalink
    4 ianuarie, 2009 22:43

    This is a great article; I have one question, though: what happens if you have some sort of power failure after mounting your FF profile as tmpfs? Seeing as it is mounted in RAM, would you not lose a lot of information?

  2. 4 ianuarie, 2009 22:50

    If you do everything as above, there is a backup made every 5 minutes in home/.mozilla/firefox called packed.tar. That backup is also used to populate your Firefox profile folder after each restart (since ram is cleared after shutdown/restart).

    Oh, and also the old packed.tar is saved: packed.tar.old

  3. Delta permalink
    4 ianuarie, 2009 23:22

    Ah, I got you. How would the browser’s speed compare if you were to mount your FF profile as a loopback FS (to save RAM)? I know it wouldn’t be AS fast as tmpfs, since the file would still be mounted on your HDD, but would its speed be noticeably improved?

  4. 5 ianuarie, 2009 1:15

    ok… that i do not know, but here is what i found:

    Firefox 3 is a significant stride forward in features, but it carries with it an equally significant stride backward in performance. The stats are much better – better memory usage both at startup and over time, faster JavaScript execution, less CPU time – but the browser just felt sluggish, even when it shouldn’t. Thought that your system with a terabyte of RAM and 256 cores could make Firefox soar? It turns out that, for most users, Firefox is actually I/O-bound, in large part because of the switch to SQLite databases.

    SQLite is designed to be portable and highly reliable, and it pulls this off with amazing success. However, it does this at the cost of speed. SQLite implements its own journaling system, lock contention procedures, multi-process access, and more. Since SQLite is a portable library, the only way to pull these complex feats off is through standard file I/O. As the volume of data that Firefox stores in SQLite databases grow – and as the number of tabs concurrently trying to access those databases on your system do as well – the time spent by Firefox on secure, hardware-backed I/O grows as well. And since SQLite is so cautious about synchronization, even gobs of RAM and a fast CPU can’t help; the process becomes entirely I/O-bound, particularly at the moments where it should be the most responsive (typing a URL, opening or switching tabs, and the like).

    But how attached are you to the last five minutes of your browsing history, really? SQLite’s agonizingly slow access times can destroy performance – and, because of the high volume of writes, it can also destroy sectors on SSDs, USB drives, or other flash media if your profile is on one of these devices. To me, it’s worth accepting a little volatility in the event of a crash for a noticeable and welcome increase in responsiveness.

    it seems the SQLite is the main issue for speed and i don’t think it would make any difference using the HDD, but you can try…

  5. iggykoopa permalink
    5 ianuarie, 2009 19:13

    the powersaving gui I’m working on has something similar to this. It copies your firefox folder to a backup and /dev/shm then symlinks the old folder to the copy in /dev/shm, then it uses rsync every five minutes to sync the backup. If you want to check it out instructions are here http://ubuntuforums.org/showthread.php?t=988309 .(I included it in the gui because it also helps keep your disk spun down, firefox is horrible with disk writes)

  6. 5 ianuarie, 2009 22:07

    Wow. Nice. Tre’ sa-i dau o incercare zilele urmatoare.

  7. 22 august, 2010 2:41

    web director

Trackbacks

  1. Speed Up Firefox (Linux Only)
  2. HowtoMatrix » Speed up Firefox by mounting the profile in tmpfs [Linux only]
  3. [Linux] Firefox performance tip « In Arid Glamor (IceHot)

Comentariile nu sunt permise.

Follow

Get every new post delivered to your Inbox.

Join 44 other followers

%d bloggers like this: