Monday, December 22, 2008

Firefox 3, Leakish And CPU Heavy?

We are still using Firefox 2.0 organizationally and it's very stable. We still have some sites that are not certified for 3.X, which I am monitoring closely. Like any forward thinking Admin, I have been running 3.0 and the 3.1 betas. I have found them to render faster, and they seem to scroll faster; however it seems to have come at great expense. CPU and memory usage is substantially higher. Can anyone else confirm this? I remember there was great debate concerning file handles and sqlite databases. Are these issues resolved? Right now, Firefox seems like it will be hard for me to scale to hundreds of people.

Here is a snapshot of my session on the server, with moderate usage for a few hours:

17 comments:

alexlauni said...

I've had the exact opposite experience, ff3 uses less memory, and less cpu while rendering faster.

Anonymous said...

I'd have to agree with your other commenter - I've noticed a massive improvement from FF2 in terms of overall memory usage and performance.

Dave Richards said...

I need to spend some time thinking about what could be different than all of yours. It shouldn't know about the fact that it's being run over remote display. It just seems to crank a LOT during the day. If this turns out to because of Flash 10, /me will not be happy.

Anonymous said...

As a user, it definitely *seems* faster. But when we switched our Selenium testbeds from FF2 to 3, we did notice a definite slowdown, though we didn't look too closely into why.

One thing I have found is that FF3 is occasionally problematic when it's profile is in an NFS-mounted directory, maybe because of the whole sqlite/fsync thing. But only occasionally - most of the time it seems fine.

Anonymous said...

Are you running a 64-bit firefox 3.0/3.1 and a 32-bit 2.0? There seems to be a good deal of difference in memory usage between 32/64 bit builds.

Larry Reaves said...

Firefox is consistently the number one app on my box for both memory and cpu usage. My current process has been running for about 3 days and has racked up nearly 14 hours of cpu time. Top shows it is almost always using between 15-20% cpu. catting /proc/firefoxpid/status shows a crap ton of memory usage:
VmPeak: 983884 kB
VmSize: 861144 kB
VmLck: 0 kB
VmHWM: 538668 kB
VmRSS: 295776 kB
VmData: 792832 kB
VmStk: 228 kB
VmExe: 28 kB
VmLib: 50136 kB
VmPTE: 568 kB


but then again, I do have 23 tabs open :) Trimming that down do 13 tabs doesn't help much (at least not immediately, it may free things up eventually), just 1 MB difference in VmSize:
VmPeak: 983884 kB
VmSize: 860824 kB
VmLck: 0 kB
VmHWM: 538668 kB
VmRSS: 297052 kB
VmData: 792832 kB
VmStk: 228 kB
VmExe: 28 kB
VmLib: 50136 kB
VmPTE: 568 kB

If you ask me, I'd rather have it free up my memory than allow me to reopen a closed tab without reloading it (except maybe if that page was the result of a post request).

Johan Dahlin said...

Firefox 3 should be leaking a lot less than 2. However, the cache sizes has increased, you have the quick back/forward support by pre-renderered pages cache which takes up quite some memory.

There's plenty on information on this on the web, just blog around a bit.

marko said...

Actually, after a whole day running, FF3 on Ubuntu Hardy is usually around 500MB of consumed RAM.

Larry Reaves said...

update: it's a few hours later and I've only seen memory usage go up.. I'm currently looking to see if I can somehow tell firefox not to keep so much crap lying around. I've only got 1 GB of ram on this box, so I don't really appreciate it forcing me to swap as this laptop has a horrendously slow hd.

Anonymous said...

With regard to memory usage, FF3 seems to be as bad as FF2 for me. It might be the extensions I am using, but they are pretty standard and updated regularly. It does render faster, but that's not everything to me.

Larry Reaves said...

I made the following changes and I'm slightly happier with my cpu/memory usage:

network.prefech-next: false
lowered cpu usage to 5-10% from 15-20%

browser.sessionstore.max_tabs_undo: 3 (default 10)
how many tabs you want to be able to reopen that you accidentally close
this saved about 30 MB

browser.sessionhistory.max_total_viewers: 2 (default -1 lets firefox pick... for my 1 GB this is 8 pages)
this is how many pages are kept in memory for instant back functionality. If I'm going back more than 2 pages I'm ok with reloading them.
This saved about 10 MB.

so, not a whole lot of savings, but this process is brand new... I'll see if it grows any slower

Anonymous said...

Dave, not sure what version you are using, but the Firefox 3.1 most certainly uses less system resources than 3.0 or 2.0.

2.0 invoked the oom-killer on my system. 3.0 never does it and 3.1 is much snappier. This is on Ubuntu and Fedora Linux.

Larry Reaves said...

Final Update:
It seems the steps I took have significantly helped. I can't get my memory usage over 400 MB, even with 34 tabs open. One or more of those settings I changed has done the trick. BTW, this is with firefox 3.0.5 as packaged for Ubuntu 8.10

Anonymous said...

The main problem with Firefox 3 on Linux is that it tends to stall for about a second pretty much every time you follow a link. That's so annoying that I seriously consider going to back to FF2.

Anonymous said...

Some time ago I had massive performance problems with Firefox. Things improved a lot if I disabled "attack site" and "forgery" detection in Firefox' security preferences and removed the associated, big (more than 30 MB IIRC) sqlite database file which contains the database with spoofing URLs from the users profile profile.

Anonymous said...

In about:buildconfig, also check wheter your Firefox has been built with --enable-jemalloc

James Henstridge said...

It is quite possible that Firefox 3 has a different app/X server memory split than Firefox 2.

What we're all seeing as an improvement (where the app and X server draw from the same memory pool) might be a negative if the app and display are on separate machines.

Furthermore, if less image data is being stored on the X server, then you'd probably see more network transfers when updating the screen which might account for the performance differences you're seeing (another case that won't really show up for local rendering).