Schlagworte: performance

15.09.11

Disable disk cache in Chromium / Google Chrome

There is no user interface in Google's browser Chrome yet to disable the disk cache, or control its size (version 14 appears to have something in the developer tools section).

But it can be done using command line options when starting the browser, and you can configure this globally for Ubuntu.

The following command line flags will use /dev/null ("the sink") as cache dir, and additionally limits it to 1 byte:

--disk-cache-dir=/dev/null --disk-cache-size=1

(I have tried just --disk-cache-size=0 or 1, but it did not appear to work as expected)

On Ubuntu/Debian, you can just add these flags to the CHROMIUM_FLAGS variable in /etc/chromium-browser/default and it will be used every time when starting Chromium.

The motivation to do this comes from me using a local (intercepting) HTTP proxy with its cache on a RAM disk. Therefore I do not want Chromium to store quite the same retrieved files on disk again.
Additionally, this is a SSD, which is not that happy about being written to in general.
Therefore /tmp is a tmpfs mount already, and the same should be the case for temporary browser files.

By Daniel in Ubuntu, Debian, Snippets2011-09-15 English (EU) Email

15.12.10

SuperSchnelleDisk (SSD)

Habe mir ein Solid State Drive gegönnt: eine OCZ Vertex 2, 120GB.

Seit längerem schon als Performance-Upgrade angedacht, und um meine doch sehr "nervig knatternde" Raptor-Platte abzulösen.

Ich habe nun meine "root"-Partition (wo das System drauf liegt) und die "home"-Partition (wo Benutzerdaten liegen) dorthin verschoben: das System startet viel schneller, ebenso wie sich Programme merklich schneller starten lassen.

Einfach ein sehr sinnvolles Upgrade!

Von Daniel in hardware15.12.10 German (DE) E-Mail

18.12.09

Convert etckeeper repository from Bazaar to Git

Quite a while ago I've installed etckeeper and changed the configuration to use Bazaar as its backend for myself (and sponsored/helped with a patch to change the default in Ubuntu).

However, already the first comment asked me why I would be using you Bazaar, if Git was that much faster (and required less space).

At that time I've thought, that Bazaar would catch up, and they (luckily) have done so in some areas, but Git is still a lot faster.

Therefore I've decided to change the repository from bzr to git. I've done so on my home machine and will do so on my dedicated server boxes in the next days, so it's a not only a recommendation but also documentation.

Howto convert a bzr repository to git (etckeeper)

Open a root shell, then you should export $GIT_DIR first:

export GIT_DIR=/etc/.git

The following will then convert /etc from a bzr to a git repository ("fast-export" is included in bzr-fastimport - you may have to install this first):

bzr fast-export --export-marks=$GIT_DIR/bzr.mark /etc | git fast-import --export-marks=$GIT_DIR/git.mark

After this (which will take a while depending on your history) you want to adjust the VCS setting in etckeeper.conf  (uncomment VCS=git and comment VCS=bzr):

sed -i -r -e s/'#\s*(VCS="git)"'/'\1'/ -e s/'VCS="bzr"'/'# \0'/ /etc/etckeeper/etckeeper.conf

I don't remember correctly, but the Git repository was not really setup correctly in the end - but the following fixed it:

etckeeper init

Benchmarks

I've done some benchmarking, comparing "$DVCS status" against each other. This will look if there are any files modified in the current tree, and it's what etckeeper does before and after upgrading (IIRC).
The following shows the commands with cold and warm caches (I've cleared the disk caches when changing to a new set).

What you can see is not only that "git status" is twice as fast with a cold cache (and even more with a warm one), but also that bzr takes even more time to print a single line of "It sure does!".

$ sudo time git st
0.01user 0.04system 0:05.61elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
29232inputs+688outputs (113major+1605minor)pagefaults 0swaps
$ sudo time git st
0.02user 0.02system 0:00.06elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k
16inputs+688outputs (0major+1716minor)pagefaults 0swaps

$ sudo time bzr st
0.14user 0.06system 0:11.74elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
17840inputs+8outputs (36major+3750minor)pagefaults 0swaps
$ sudo time bzr st
0.16user 0.03system 0:00.32elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3787minor)pagefaults 0swaps

$ sudo time bzr rocks
It sure does!
0.20user 0.05system 0:08.19elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
17392inputs+8outputs (34major+3422minor)pagefaults 0swaps
$ sudo time bzr rocks
It sure does!
0.16user 0.01system 0:00.20elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3458minor)pagefaults 0swaps

I'll update this post when scripting for the update of my various OpenVZ containers, but the basic information should stand.

From now on, I will save 5+ seconds on any "aptitude safe-upgrade". Hopefully this multiplies somehow, so the time investment into this post pays back.. ;)

08.05.09

Improving dpkg/apt performance

Thanks to Antti-Juhani Kaijanaho I could improve the performance of dpkg/apt on my old Ubuntu system (upgraded since I've started using Linux/Ubuntu in 2005):

I've written a small script, according to Antti-Juhani's post:

#!/bin/sh
# via http://antti-juhani.kaijanaho.fi/newblog/archives/521

if [ "$(id -u)" != "0" ]; then
echo "You must be root."
exit 1
fi

dpkg --clear-avail
dpkg --forget-old-unavail
sync-available

My results show that /var/lib/dpkg has gone from 195M down to 154M and calling apt-get upgrade (not a good test probably) went down from 10.024s to 5.764s (after dropping all caches, of course - "echo 3 | sudo tee /proc/sys/vm/drop_caches").

Thanks.

This should get considered to be done during Ubuntu upgrades.

By Daniel in Ubuntu, Snippets2009-05-08 English (EU) Email

06.12.08

Launchpad.net could be faster

Link: https://bugs.launchpad.net/launchpad/+bug/305630

Since Ubuntu uses Launchpad a lot, it is really frustrating, if this web application is quite slow.

Therefore I've filed a bug about it.

As I write in the report, there are bugs about particular issues already, but I'd like to put some attention to this: a lot of Ubuntu developers (and those from other projects using Launchpad) are using this website a lot and therefore it should be as snappy as possible.

14.09.06

WD1500AHFD aka Raptor

Habe mir eine neue Festplatte gegönnt. 10000 Umdrehungen pro Minute und dadurch sehr schnell. Wohl momentan die schnellste nicht-SCSI-Festplatte.

Aufgrund der Lieferbarkeit habe ich die Version gewählt, die eine Plexiglasscheibe hat, wodurch man den (obersten) Schreibkopf sehen kann. In einem Festplattenkäfig sieht man davon aber nicht sehr viel:

Eingebaute Raptor-Festplatte

Ausserdem ist das Tower-Gehäuse natürlich nicht durchsichtig.. ;)

Bevor ich mein bestehendes Ubuntu-System auf die neue Platte kopiert habe, wurde die Partition mit ReiserFS formatiert.

Benchmarks:

$ sudo hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   2716 MB in  2.00 seconds = 1357.92 MB/sec
 Timing buffered disk reads:  248 MB in  3.01 seconds =  82.44 MB/sec

Sehr zu empfehlen und nicht übermässig laut - jedenfalls nicht lauter als mein Grafikkartenlüfter, der wohl als nächstes ersetzt werden sollte.

Derzeit bin ich unter Ubuntu Karmic mit cryptsetup+RAID+LVM bei weitaus weniger:

/dev/sda:
 Timing cached reads:   1252 MB in  2.00 seconds = 625.58 MB/sec
 Timing buffered disk reads:  202 MB in  3.01 seconds =  67.11 MB/sec
Von Daniel in hardware14.09.06 German (DE) E-Mail
Seitenleiste