User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 Firefox/3.0.10 (not sure of exact version - the standard in Ubuntu 8.10 on 5 May 09) When using Firefox heavily on Ubuntu 8.10 it will lock up (become unresponsive - cannot scroll, switch tabs or anything) for periods of up to 30 seconds. This appears to always be started when Firefox is in a state of "log_wait_commit". After 5-10 seconds in log_wait_commit there will be a huge storm of disk activity and then Firefox will become available again. I've tried moving the Firefox cache to a RAM. This may have made the lock-ups slightly less frequent, but hasn't solved it. Reproducible: Sometimes Steps to Reproduce: 1. Run firefox with roughly 10tabs open 2. Actively browse, opening new tabs, clicking on links 3. After an hour or so of activity Firefox will stop responding for between 10 and 30 seconds. 4. Repeat

You may be hitting the famous fsync issue (bug 421482). You can try watching the firefox process with strace and check what system call it is doing when the lock-up occurs.

Thanks for the reply. To be clear I should try something like: strace -p <pid of firefox> 2>&1 | grep -i fsync and then if I get a lot of fsync's when the problem occurs I could try setting toolkit.storage.synchronous to the integer 0 (and be aware of the risk of losing history and/or bookmarks).

The above command assumes you are looking for fsync calls, so you may not see relevant results if another system call is pending while firefox locks up. Instead, you could use the command: strace -f -tt -T -p <pid of firefox-bin> And maybe redirect to a file. This will show you the starting time of the system call and the time spent in the system call on the right of the line. When firefox locks up, note the time and check what system call was done at that moment and how long it took. (stracing a process on my system sometimes freezes the Xserver, so be warned if that happens. The solution is to use Xephyr or something like that). setting toolkit.storage.synchronous to the integer 0 can help, but there may still be some fsync system calls (there also are fsync calls when saving the session restore file for instance).

Thanks. I gave it a go and sure enough saw a heap of fsync calls. Changed toolkit.storage.synchronous to 0 and couldn't replicate the problem. I'm marking this as resolved.