dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
5243

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

4 edits

OutOfMem

Premium Member

Make Firefox 3.x more responsive with a "simple" trick

After a solution for a different problem, found in the following thread, I now have a very "quick" Firefox on my laptop, which I am in love with: »[SOLVED] Have a script run when a program is closed?

Ah, success! Which on Linux is a very rare thing, indeed! (Just a joke, everyone. A harmless jab.)

Thank you for your help, once again, pablo See Profile! For the sake of documentation, in case anyone else is interested, I'll write down what I did to speed up Firefox 3.x and minimize the number of times that it reads/writes to the hard disk (or even to the SSD, for those special netbook users out there.) These steps are based on what was written in the ArchWiki page as well as pablo's help.

I really recommend anyone who is using a netbook, especially one equipped with an SSD, to try this out for yourself. I've read around that Firefox 3.x (using SQlite database files for bookmarks, history, etc) can freeze up and feel "sticky" and "slow" on an SSD disk. Make sure you have enough RAM to spare before trying this trick. (My laptop has 2 GB, and my netbook has 1 GB total RAM.)

STEP 1) Re-locate Firefox's Cache folder to the built-in RAMdisk folder (optional, see discussion below, or use STEP 4 instead)
* Open up Firefox and clear your temporary files
* In the URL bar, type about:config and create a new string called browser.cache.disk.parent_directory and make its value /dev/shm/ff-cache
* This means your Firefox Cache contents will now be saved in /dev/shm/ff-cache/Cache with the same permissions as before
* Anytime you shutdown or reboot the system, these files will disappear, which to me is fine, since I empty my browser cache more often than I reboot. Besides, these are unimportant files that are not critical to save between reboots
* The amount of RAM taken up will not exceed whatever you limited Firefox's cache to in your preferences. (Edit > Preferences > Advanced > Network)

STEP 2) Backup your profile folder, just in case
* Your Firefox profile folder (which houses all of your settings, bookmarks, history, add-ons, etc) is located at: ~/.mozilla/firefox/ and will be named xxxxxxxx.default, where xxxxxxxx will be a unique random string of characters
* ArchWiki provides a simple solution of backing up this folder to a .tar.gz archive in your home folder by running the following command in a terminal: tar zcvfp ~/firefox_profile_backup.tar.gz ~/.mozilla/firefox/xxxxxxxx.default
* Replace xxxxxxxx with the correct string of characters

STEP 3) Create an fstab entry for the profile RAMdisk
* Edit /etc/fstab and add a line at the bottom that reads like this: firefox /home/username/.mozilla/firefox/xxxxxxxx.default tmpfs size=128M,noauto,user,exec,uid=1000,gid=1000 0 0
* Replace username with your actual username
* Replace xxxxxxxx with the actual profile string of characters
* Replace 128M with your desired size of the RAMdisk. The more available RAM you have, the more liberal you can be with this value. I found that 100M is more than plenty, especially since my Cache is no longer saved in my profile, anymore. (I am using 20 MB in the RAMdisk, as we speak)
* Replace uid=1000 and gid=1000 with your respective user and group numbers, or even with your actual username and group name. For example: uid=dave,gid=users
* Remove the option noauto if you wish for this mount to take place upon booting up your machine. This also helps if your user account does not have sudo privileges for the mount command

STEP 4) Create a separate fstab entry for the Firefox cache (use this if STEP 1 was skipped)
* Edit /etc/fstab and add a line at the bottom that reads like this: ff-cache /tmp/ff-cache tmpfs noexec,nosuid,nodev,noatime,size=50M 0 0
* Change size=50M to match the setting in Edit > Preferences > Advanced > Network
* As root, mount the new RAMdisk: mount /tmp/ff-cache
* Open up Firefox, and in the URL bar, type about:config and create a new string called browser.cache.disk.parent_directory and make its value /tmp/ff-cache
* You now have your Firefox cache mounted in RAM
* To check the available space / used space on the /tmp/ff-cache RAMdisk, type: df -h | grep Filesystem && df -h | grep /tmp/ff-cache

STEP 5) Create the sync script, which syncs the profile in the RAMdisk (volatile) to one on your hard disk (permanent)
* In a text editor, create a file called ramdisk_firefox_sync.sh and save it somewhere convenient, such as a Scripts folder in your home directory
* Make it executable: chmod +x ramdisk_firefox_sync.sh
* Paste the following into the file, and make sure to replace xxxxxxxx with the actual string of characters for your Firefox profile folder:
#!/bin/bash
# Change this to match your correct profile folder name
PROFILE="xxxxxxxx.default"
 
cd "${HOME}/.mozilla/firefox"
 
if test -z "$(mount | grep -F "${HOME}/.mozilla/firefox/${PROFILE}" )"
then
    mount "${HOME}/.mozilla/firefox/${PROFILE}"
fi
 
if test -f "${PROFILE}/.unpacked"
then
    rsync -a --delete --exclude .unpacked ./"$PROFILE"/ ./permanent_profile/
else
    rsync -a ./permanent_profile/ ./"$PROFILE"/
    touch "${PROFILE}/.unpacked"
fi
 
exit
 

STEP 6) Prepare the permanent profile folder
* Copy everything stored in the current profile folder to a new folder called permanent_profile: cp -av ~/.mozilla/firefox/xxxxxxxx.default ~/.mozilla/firefox/permanent_profile
* Delete everything in the current profile folder (which will become the mount point of your RAMdisk profile): rm -rfv ~/.mozilla/firefox/xxxxxxxx.default/*
* Make sure to replace xxxxxxxx once again, with the proper string of characters

STEP 7) Mount the RAMdisk for the first time
* Make sure your user has sudo mount privileges
* In a terminal, run the ramdisk_firefox_sync.sh script: ~/Scripts/ramdisk_firefox_sync.sh
* Now you have a mirrored copy of your profile loaded into a mounted RAMdisk. This step does not need to be repeated, as simply running Firefox will do this automatically from now on

STEP 8) Create a new launcher for Firefox
* In the same Scripts folder as before, create a new file called firefox_ramdisk_profile.sh
* Make it executable: chmod +x firefox_ramdisk_profile.sh
* Paste the following into the file:
#!/bin/bash
# Before launching Firefox, sync hard disk profile to RAMdisk profile, via the ramdisk_firefox_sync.sh script
 
~/Scripts/ramdisk_firefox_sync.sh
 
# After syncing, launch Firefox
 
firefox &
 
# Wait for Firefox to exit
 
wait
 
# Upon exiting Firefox, sync the RAMdisk to hard disk, once again
 
~/Scripts/ramdisk_firefox_sync.sh
 
exit
 

STEP 9) Change the value of your menu's Firefox entry to point to your new script, rather than just the command firefox
* Open up your menu editor (in GNOME this is done with the command alacarte or running Main Menu / Menu Editor from your menu)
* Find the entry for Firefox, and replace the command firefox with /home/username/Scripts/firefox_ramdisk_profile.sh
* Make sure to replace username with your actual username

You should be all set now. I cannot say how well this will work out for you, since I have only tried it on two computers. (One running openSUSE, and the other running Linux Mint. I will soon try it on Ubuntu on my netbook, which needs this trick the most!) You will notice I didn't bother to include the additional steps of creating cron jobs or system startup scripts, since I feel they are not needed anymore. All the syncing is done when opening and closing Firefox, so the extra scripts would be redundant.

To summarize, every time you launch Firefox, your entire profile will be loaded into RAM. (Using this trick, your profile safely sits in a folder called ~/.mozilla/firefox/permanent_profile, which gives you a permanent copy of your profile that survives between reboots.) Since your entire profile is completely loaded into RAM, operations are quicker, such as browsing through your bookmarks and history, as well as sorting items, and using the URL bar (which is noticeably slower in Firefox 3.x, compared to Firefox 2.x) due to the use of SQlite database files. After exiting Firefox, the sync process happens once again, and any changes made in your RAMdisk profile (bookmarks, history, cookies, settings, etc) will be saved to the hard drive, for safe-keeping.

If you have an SSD drive, this should eliminate the hiccups associated with Firefox 3.x. Even if you do not use SSD, this decreases the number of reads and writes to the disk (since there is no disk activity while using Firefox; only when launching it or exiting it.) If you try this trick out, let us know how well it works for you, or if there are any tweaks that can be made!

If you find any mistakes in this post, don't be shy to correct them! I am not very technically savvy, so I might have made a boo-boo in my train of logic.

Here is the ArchWiki page I used as a reference: »wiki.archlinux.org/index ··· ng_tmpfs

UPDATE: Fixed a typo in STEP 9.

UPDATE: Added an additional step (now STEP 4) on configuring another RAMdisk exclusively for Firefox's cache, rather than using the (optional) /dev/shm location.

UPDATE: I removed the -v (verbose) argument from the sync script in STEP 5, since it is pointless in a GUI launcher. (There is nowhere for it to output, since it is not being run from a terminal, but rather from your menu shortcut.)

UPDATE: I recommend creating a cron job or script that periodically makes a backup copy of your Firefox profile folder. This is not required, but it is highly recommended, just in case something goes wrong. At least you will have a working copy of your Firefox profile and bookmarks, rather than nothing at all. I also recommend the Xmarks addon for Firefox, which allows you to backup and sync your bookmarks on their server (or your own WebDAV server).

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

2 recommendations

jdong

Premium Member

The caveats, of course, are:

(1) If your system crashes or X zaps, you will lose every modification to your browser session since your last clean shutdown of Firefox.

(2) If your system crashes, right when or shortly after the sync of the profile back to disk, you may trash the entire profile (the writeback isn't done synchronously, you could lose entire database files in write cache)

(3) However much space your Firefox profile takes on disk, you need that much more virtual memory now to run Firefox. Netbooks tend to already have a limited amount of RAM to begin with. Compcache might be a good workaround and exercise for the reader

Other than that, indeed this will speed up Firefox because everything is done in RAM or virtual memory.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

4 edits

OutOfMem

Premium Member

Oh, my. I replaced my entire reply with something else.

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

jdong to OutOfMem

Premium Member

to OutOfMem
Thanks for your well thought out posts! I just wanted to get the point across that there still is no free lunch. I've done very similar hacks before. I've even used unionfs to shadow my entire system into ram like a livecd directly from GRUB.

One benefit you forgot to note is possibly 1-2W power savings from less IO traffic which can easily translate to a half hour of battery life.

I do recommend as the OP clearly stated to back up your FF profile regularly.

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

Selenia to OutOfMem

Premium Member

to OutOfMem
I tried it with Swiftfox(modifying some scripts to adapt to this) and it works very well. Firefox was missing some things like history when I first executed this(probably my bad), but nothing really important(not enough to use my backup). Otherwise, great idea. I want to see what kind of gains a slower computer might get, but there is a small improvement on a faster pc it seems. Even if there were no gain, the point jdong brought up of less I/O is always a great thing if you have RAM that generally just sits there, like the desktop I tried this on. I can't see borking anything badly with this. At worst, you may have to restore your profile and original shortcut paths. Give it a shot. Will be interesting to see how much is observed for results from others, too.

Smitedogg
Uzbekikitty
Premium Member
join:2000-11-11
Pueblo, CO

Smitedogg to OutOfMem

Premium Member

to OutOfMem
I've been under the impression that /dev/shm ought be mounted noexec for security?

pH1
Rawr
join:2001-12-31
Canada

pH1 to OutOfMem

Member

to OutOfMem
/dev/shm shouldn't be used directly. This is just for POSIX shared memory usage, is it not? Everything should be in its own tmpfs mount. Also, just because you have something mounted in tmpfs which would "normally" be stored in RAM, it's fully possible it will be swapped during memory pressure.
SUMware2
Premium Member
join:2002-05-21

1 edit

SUMware2 to OutOfMem

Premium Member

to OutOfMem
I run /tmp directly in RAM at boot via fstab. All browser cache is directed into /tmp (so it actually is in RAM), locked down with nodev,nosuid,noexec. Mighty fast and secure.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

3 edits

OutOfMem

Premium Member

said by SUMware2:

I run /tmp directly in RAM at boot via fstab. All browser cache is directed into /tmp (so it actually is in RAM), locked down with nodev,nosuid,noexec. Mighty fast and secure.
I, too, have /tmp configured as a 128 MB RAMDisk, but I noticed using the noexec option can cause some issues with some installers.

Is it true that anything mounted in RAM as a tmpfs, such as /tmp and the Firefox profile folder, will be swapped to disk under certain conditions? I just assumed they would be "regarded" as tiny file systems, in which they are "already" on the "disk".

Technically, if your /home partition is mounted as noexec, then the same would apply to anything redirected to /dev/shm, which formerly resided somewhere within your user's home directory, right?

Would a better alternative be to mount Firefox's cache as its own tmpfs filesystem (50 MB as the default size), and avoid /dev/shm altogether?
OutOfMem

OutOfMem

Premium Member

Could someone check the new STEP 4 that I added to the walk-through? I'm fairly certain it should work out fine, but it can be disastrous if someone messes up on it, or if I wrote out inaccurate steps.

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

Selenia to OutOfMem

Premium Member

to OutOfMem
/dev/shm should work. I don't see a security issue. These scripts reference files owned by the user in a folder under /dev/shm. Most important stuff in /dev/shm is owned by root. Firefox does not have permission to write root-owned files, even with this hack. I did it the first way and will keep it that way. There are other things that write directly to /dev/shm, as well. The old fglrx control panel comes to mind. I actually had to muck with some permissions(using safe practices, of course) there on 1 system to get fglrx to work.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

1 edit

OutOfMem

Premium Member

said by Selenia:

/dev/shm should work. I don't see a security issue. These scripts reference files owned by the user in a folder under /dev/shm. Most important stuff in /dev/shm is owned by root. Firefox does not have permission to write root-owned files, even with this hack. I did it the first way and will keep it that way. There are other things that write directly to /dev/shm, as well. The old fglrx control panel comes to mind. I actually had to muck with some permissions(using safe practices, of course) there on 1 system to get fglrx to work.
What caught my attention about the /dev/shm method is that it is simple to do (no editing /etc/fstab or creating static mounts) and the amount of RAM used will grow and shrink dynamically. If you only have 10 MB in Firefox'x cache, only 10 MB of RAM/virtual memory will be used up.

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

jdong to OutOfMem

Premium Member

to OutOfMem
Nowadays /dev/shm is simply a tmpfs mounted directory. It's just as legit to use as mounting your own tmpfs somewhere else.
jdong

jdong to OutOfMem

Premium Member

to OutOfMem
As for step #4, I do not recommend mounting anything over /tmp in its entirety; if some application starts using a massive amount of temporary space it's prone to flood out your tmpfs.

Instead, consider mounting it in a subdirectory of tmp, or even a subdirectory of your home directory, or something like /var/firefox_tmp or something like that.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

1 edit

OutOfMem

Premium Member

said by jdong:

As for step #4, I do not recommend mounting anything over /tmp in its entirety; if some application starts using a massive amount of temporary space it's prone to flood out your tmpfs.

Instead, consider mounting it in a subdirectory of tmp, or even a subdirectory of your home directory, or something like /var/firefox_tmp or something like that.
Modified and fixed. I think STEP 4 is fairly safe now. (Remember, STEP 4 is only used if STEP 1 is skipped, and vice versa.)

UPDATE: Turns out that both /dev/shm and the tmpfs filesystem will grow and shrink dynamically, depending on how much space is in use. Good news, since you will not be using up all the RAM specified in the mount options. This means that even though up to 50 MB is allowed for the Firefox cache, even on a mounted tmpfs, the only RAM taken up is that which populates /tmp/ff-cache. The same is true in the case of the RAMdisk for the Firefox profile folder.

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

1 recommendation

jdong

Premium Member

said by OutOfMem:

UPDATE: Turns out that both /dev/shm and the tmpfs filesystem will grow and shrink dynamically, depending on how much space is in use. Good news, since you will not be using up all the RAM specified in the mount options. This means that even though up to 50 MB is allowed for the Firefox cache, even on a mounted tmpfs, the only RAM taken up is that which populates /tmp/ff-cache. The same is true in the case of the RAMdisk for the Firefox profile folder.
Correct; tmpfs to the kernel's memory manager acts no differently than a program using up memory -- its data can be stored in RAM, swap, or a combination of the two depending on the same algorithm Linux uses to decide whether or not to swap out your applications.

By default tmpfs will balloon to a maximum of 1/2 your physical RAM size, but the mount option that you used can override that to a more specific limit.
SUMware2
Premium Member
join:2002-05-21

1 recommendation

SUMware2 to OutOfMem

Premium Member

to OutOfMem
said by OutOfMem:

said by SUMware2:

I run /tmp directly in RAM at boot via fstab. All browser cache is directed into /tmp (so it actually is in RAM), locked down with nodev,nosuid,noexec. Mighty fast and secure.
I, too, have /tmp configured as a 128 MB RAMDisk, but I noticed using the noexec option can cause some issues with some installers.
Yes, that's called Linux security at work.

For example, when installing updated nVIDIA drivers I need to permit 'exec' otherwise the install will not be permitted. A simple temporary change to fstab compensates. Otherwise no other issues with 'noexec' here.
said by OutOfMem:

Is it true that anything mounted in RAM as a tmpfs, such as /tmp and the Firefox profile folder, will be swapped to disk under certain conditions? I just assumed they would be "regarded" as tiny file systems, in which they are "already" on the "disk".
It's technically possible I suppose. I limit the maximum size and tmpfs manages immediate size requirements. The Firefox cache actually loads as '/tmp/CACHE'. At shutdown everything is nominally gone without leaving a HDD trace. Good for privacy concerns, too.

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

Selenia to OutOfMem

Premium Member

to OutOfMem
This trick has tested out beautifully on a 1 GHz Pentium 3 with 256 MB RAM and 11 MB shared integrated intel video controller with a very slow hard disk. It runs Xubuntu. I chose this one because of it somewhat low I/O performance as the next victim for this. All my settings but my addons carried over this time. The result is awesome. I used 32 MB for the cache size, setting that in Firefox, as well. I also set Firefox for 32 MB in its own memory cache. It almost doesn't touch the hard disk and runs almost as if it's on a newer pc. So, as I suspected, the older the hardware, the more the benefit.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

1 edit

OutOfMem

Premium Member

I also went ahead and tried this out on my netbook (1 GB of RAM, Intel Atom CPU, Ubuntu 9.04, soon to be changed to Xubuntu 9.10).

I noticed a performance boost while using Firefox. I kept an eye on my hard disk activity light, and it would not show hard drive activity, save for a few background processes (such as laptop-mode), which are unrelated to Firefox. With this trick, my netbook isn't quite as fast as my laptop or desktop, but that is expected, since it is an under-powered device, after all. It did, however, respond a little better than how it originally was before. (I have a crappy Fujitsu hard drive in my netbook, but it's not an SSD, so I cannot say how effective this trick is on SSD drives.)

I am pleased with this myself, but at the same time, I also have an ominous feeling about all of this. I am afraid that, as jdong See Profile indicated, the unpredictable might happen in which a crash/freeze occurs at the same time of the sync process, which could spell disaster for your Firefox profile (and more importantly, your bookmarks.)

On a completely unrelated note: I am somewhat frustrated at my Fujitsu drive, since it doesn't play so nice with laptop-mode. Even on an "Advanced Power Management" setting of 128, it just LOVES to go on standby/resume, over and over and over and over, unless I disable it with a setting of 254.

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

jdong

Premium Member

said by OutOfMem:

On a completely unrelated note: I am somewhat frustrated at my Fujitsu drive, since it doesn't play so nice with laptop-mode. Even on an "Advanced Power Management" setting of 128, it just LOVES to go on standby/resume, over and over and over and over, unless I disable it with a setting of 254.
Yep, this is one of the nightmares that we had with the whole "Ubuntu kills your disk drive" fiasco. A lot of the times we weren't even doing anything, or we were specifying fairly reasonable hdparm values and the drive would have a mind of its own to interpret it in a self-mutilating manner.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

OutOfMem

Premium Member

said by jdong:

said by OutOfMem:

On a completely unrelated note: I am somewhat frustrated at my Fujitsu drive, since it doesn't play so nice with laptop-mode. Even on an "Advanced Power Management" setting of 128, it just LOVES to go on standby/resume, over and over and over and over, unless I disable it with a setting of 254.
Yep, this is one of the nightmares that we had with the whole "Ubuntu kills your disk drive" fiasco. A lot of the times we weren't even doing anything, or we were specifying fairly reasonable hdparm values and the drive would have a mind of its own to interpret it in a self-mutilating manner.
I also had the same problem on my laptop (which came with a Fujitsu hard drive), on Linux Mint 7 (Ubuntu 9.04). However, after switching it out for a Western Digital hard drive, I no longer have same issue with laptop-mode, while still using the same distro as before. Using a setting of 128 does not cause the Western Digital hard drive to go on a standby/resume berserker spree.

That's where I get confused. I'm not sure if it's a fault of laptop-mode, Ubuntu (or any other distro for that matter), or the model of the hard drive itself.
OutOfMem

OutOfMem

Premium Member

I wonder, for the second script (which contains the wait command), does a Firefox "crash" constitute an "exit"? Will the rsync script be execute if the firefox process is closed, either way?

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

Selenia

Premium Member

No, the script would exit. Seems all that would happen is losing changes made in the session that crashed.

OutOfMem
openSUSE 11.4
Premium Member
join:2001-05-11

1 edit

OutOfMem

Premium Member

said by Selenia:

No, the script would exit. Seems all that would happen is losing changes made in the session that crashed.
Technically, now that I think about it, in this case you wouldn't lose any changes made, as long as you do not lose power before you start Firefox again (or run the sync script again.) The changes would still be stored in the Firefox profile folder tmpfs / RAMdisk.

Simply running Firefox again (or the sync script) before you shutdown or lose power will save the changes to your permanent_profile folder. I guess this would also be a good reason to have the sync script automatically run before shutting down.

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

Selenia

Premium Member

said by OutOfMem:

said by Selenia:

No, the script would exit. Seems all that would happen is losing changes made in the session that crashed.
Technically, now that I think about it, in this case you wouldn't lose any changes made, as long as you do not lose power before you start Firefox again (or run the sync script again.) The changes would still be stored in the Firefox profile folder tmpfs / RAMdisk.

Simply running Firefox again (or the sync script) before you shutdown or lose power will save the changes to your permanent_profile folder. I guess this would also be a good reason to have the sync script automatically run before shutting down.
And we have a winner. Sufficient backups with restores are also made in your procedure in case of the remote worst case scenario that the sync script actually got interrupted on a non-journalling filesystem or the RAMDisk got corrupted somehow, which seems a very remote worst case scenario. A journalling filesystem would recover what was to be written and restore the state of the files(causing only the config changes for the session to be lost, rather than the whole configuration). Everyone should be using journalling anyways =) Which brings me to say this trick should probably be marked as safe if followed correctly. Even though fstab is modified, the writable mount made is run by user level, so no security breaches either. I have seen a tremendous gain in Swiftfox on lower end machines and a decent gain as I played around more on faster machines. A+

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

jdong to OutOfMem

Premium Member

to OutOfMem
Which journaling filesystem in Linux guarantees transactional atomicity again in the way that you specified? Reiser4? Oh right that is an abandoned project. btrfs at some point in time will....

Metadata journaling like you find in ext3, ext4, XFS, JFS, etc will not protect against partial writes failing. What does for ordinary Firefox on-disk profiles is sqlite's carefully timed fsync's of its database file.

rexbinary
MOD King
Premium Member
join:2005-01-26
Plano, TX
·Frontier FiberOp..

rexbinary to OutOfMem

Premium Member

to OutOfMem
Another Firefox tweak is disabling IPv6 support. I always thought this trick was more of a urban legend then anything, but it does produce noticeable improvement for me with Firefox on Fedora.

»techxplorer.com/2007/02/ ··· -ubuntu/

jdong
Eat A Beaver, Save A Tree.
Premium Member
join:2002-07-09
Rochester, MI

jdong to OutOfMem

Premium Member

to OutOfMem
I believe that tweak is still an urban legend; On my Ubuntu machine it makes no difference. As I understand, glibc now sends out ipv4 and ipv6 resolutions in parallel?

rexbinary
MOD King
Premium Member
join:2005-01-26
Plano, TX
·Frontier FiberOp..

rexbinary

Premium Member

said by jdong:

I believe that tweak is still an urban legend; On my Ubuntu machine it makes no difference. As I understand, glibc now sends out ipv4 and ipv6 resolutions in parallel?
Could be. I made this change when Fedora 11 was new which 5 months ago. That's a long time in Fedora development time hehe, many updates have been out since then. I'll try re-enabling it and see if I see any difference.

uucp
@teksavvy.com

uucp to OutOfMem

Anon

to OutOfMem
I wouldn't recommend this for most users because it is quite dangerous. Instead I would suggest you disable your disk cache in firefox if IO is the problem (browser.cache.disk.enable), or tweak the VM settings for buffer size, etc (google laptop mode). Another trick I use is abusing prelink and dd to prep the FS cache before you actually start Firefox (strace is nice here to find what libs / files firefox is looking for).

Disabling autoupdate checking, live bookmarks, etc. will also help enormously because they all fire off at the same time when you start ff.

Using /dev/shm is also likely to severely piss your administrator off because that memory is not swapped out.

Regarding ipv6, it really depends on the local resolver.. If you are using your ISP's DNS servers for example, they may not be replying at all to the request which is causing your system to timeout, versus getting a rejection.

Instead of disabling ipv6 in individual applications, if you don't have a reason for it, remove the kernel module (varies by distro, google it). If you run a local caching name server (bind, djb, dnsmasq, etc.), you can also have it outright reject _Any_ V6 requests.

cheers