UbuntuSolutions

Recently, I bought myself a nice little Acer Aspire One laptop. I swiftly got rid of the dull Fedora variant installed on it and replaced it with Ubuntu 8.04 and then 8.10. I had my share of troubles with the wireless card on the machine, especially with 8.10 and WPA2 networks, must as of now, it all works.

The AAO doesn't have a lot of system resources. 512MB memory and just 8GB of disk. This disk is actually an SSD drive, but it's the slow kind, really really slow especially when writing. As a result the laptop regularly comes to a standstill for a few seconds, with the disk light on solid, before reemerging. Annoying.

Here's what hdparm has to say about the disk:

me@aao # hdparm -i /dev/sda1
/dev/sda1:
Model=SSDPAMM0008G1EA                         , FwRev=Ver2.I0H, SerialNo=CVCP8236821U5
Config={ HardSect NotMFM Fixed DTR>10Mbs }
RawCHS=15636/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=?0?
CurCHS=15636/16/63, CurSects=15761088, LBA=yes, LBAsects=15761088
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive conforms to: Unspecified:  ATA/ATAPI-4,5

Firefox is the application where it happens the most often. Firefox loads a page, it appears to be done, but it then freezes for a few seconds with that damn disk light on.

Why is that? Let's see. First let's make sure that it's Firefox using the disk. The great "pidstat" tool, part of the sysstat package is your friend. Start it up with the -d option to let it monitor disk activity and reports every X seconds which application is reading or writing to disk:

pidstat -d 5

There are always a few applications doing some IO at any point in time. Firefox, pdflush keep showing up in the list, but it's normally less than 4KB in or out per sec and that's fine.

Now load some web pages and keep an eye on the output of pidstat.

16:26:25          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:30         6026      0.80      6.40      2.40  firefox

16:26:30          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:35          181      0.00      2.40      0.00  pdflush
16:26:35         6026      5.60     41.60      0.80  firefox

16:26:35          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:40          181      0.00      5.60      0.00  pdflush
16:26:40         6026     51.20      8.80      0.00  firefox

16:26:40          PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16:26:45          181      0.80      1.60      0.00  pdflush
16:26:45         4540      0.00      2.40      0.00  syslogd
16:26:45         5441      0.00      0.80      0.00  wpa_supplicant
16:26:45         6026      3.20    107.20      1.60  firefox

Here you go, the page finishes loading and firefox starts writing to disk making the system unresponsive for a few seconds. It doesn't happen on every page and I noticed the high reading rates are not as bad as the lower write rates. 30KS/s write for 3 seconds is enough to make you feel the pain.

Now, let's find out what Firefox is writing. For that task, strace is what you need. First find the firefox pid. Once you have it, attacch to firefox using strace. strace will pring all the system calls the application makes including IO. What I want to know is what file is opened after a page finishes loading and how much data is written to it. Since there is a crazy amount of noise around the interesting data, I have to filter out of strace all the system calls I don't care about.

strace -p 6026 2>&1 | egrep -v "gettimeofday|poll|EAGAIN|itimer|sigaction|recvmsg|socket|bind|sendto|futex|select"

I try to start that command right when a page finishes loading and the disk light turns solid green and turn it off right after it goes black again.

What I see during those few seconds are a lot of writes to a couple of file descriptors (29 and 44):

write(44, "\r\r\374\0\t\t\244\0\16\302\16,\r\217\fy\v\304\v$\nu\n"..., 4096) = 4096
write(29, "\n\0\0\0\235\3o\0\0040\4E\4Z\4o\4\204\4\231\4\256\4\303"..., 4096) = 4096

Now to find what those file descriptors are:

me@aao # lsof -p 6026 | egrep " 29| 44"
firefox 6026 me   29uw  REG        8,1  1892352 467957 /home/me/.mozilla/firefox/kuz6twft.default/places.sqlite
firefox 6026 me   44u   REG        8,1    94904 467854 /home/me/.mozilla/firefox/kuz6twft.default/places.sqlite-journal

Firefox is writing to 2 sqlite database files. The places database is described at Mozilla Dev Center.
Places is the database where all of your history and bookmarks go. The history can grow very big thus getting the database to several MB or even several tens of MB. It seems every link you ever download, of any kind, text, js, images, everything goes in. That's a lot if inserts and as the database grows, each insert takes more time.

You can't turn off using that database AFAIK, nor limit the number of entries that goes in it. There are other databases that Firefox writes into and that also slow things down: the anti-phishing one and the cookies one. You can, although I don't recommend it, turn off the anti-phishing one: go to about:config, search for safebrowsing.enabled to change it to false.

That leaves you with few options to improve the situation. Here are the options sorted by order of effectiveness:

• change history expiration setting: Go to about:config and reduce browser.history_expire_days
• compact the database from times to times. When Firefox is off:

  sqlite3 "path to database" 'VACUUM;'

• move the mozilla files including the databases to a memory partition. Create a tmpfs partition at /home/yourself/.mozilla. Make a copy of the directory you have on disk at the moment. Create a script to start firefox. This script will start by copying the on disk .mozilla to the on memory .mozilla. Then it starts firefox. When firefox shuts down, the script copies the daata from meemory to disk.

Note that I haven't tried that last option as I'm afraid it would need too much memory on a computer where this resource is already scarce.

But the first option that requires reducing "reduce browser.history_expire_days" is simple and works quite well. I set it to 7, that drastically reduces the size of the sqlite database and delays displaying web pages are now rarely above 2 seconds.