I/O Probleme mit digikam

Meinen Rechner verwende ich seit dem Kauf eines Tablets vorwiegend für die Verwaltung meiner Fotos mit digikam.

Schon seit mehreren Kubuntu Versionen ärgere ich mich über die schlechte Performance meines Rechners. Als Flaschenhals bei der Performance habe ich den Disk-I/O ausgemacht.

Die Platte ist (insbesondere beim Arbeiten in Digikam) ständig am arbeiten, top und iotop zeigen, dass das System auf I/O wartet.

Ich war schon fast so weit mir eine SSD Platte zuzulegen, das war mir allerdings dann doch zu teuer. Zudem kam es mir komisch vor, dass so einfache Aufgabe, wie z.B. das EXIF-Rotate mehrerer  Bilder in digikam meinen Rechner lahmlegen können. Ich habe deshalb das Problem etwas näher analysiert.

Informationen zu meinem System:

– Kubuntu 12.04

– LVM + LUKS + EXT4

– Intel(R) Core(TM)2 Duo 2 Ghz

– 2 Gb RAM

– Sata Disk: Hitachi Travelstar 5K

Hier die Ergebnisse meiner Analyse:

iotop zeigt während dem arbeiten in digikam, dass der jbd2/dm-6-8 (Journaling Prozess vom EXT4) Prozess den größten Teil der IO-Last verursacht:

Total DISK READ:      19.19 K/s | Total DISK WRITE:       2.08 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                 
 1121 be/3 root        0.00 B/s    0.00 B/s  0.00 % 83.57 % [jbd2/dm-6-8]
 2915 be/4 volker      0.00 B/s   61.42 K/s  0.00 % 27.76 % digikam -caption digiKam --icon digikam
   11 be/4 root        0.00 B/s    0.00 B/s  0.00 % 11.43 % [kworker/0:1]
   54 be/4 root        3.84 K/s    0.00 B/s  0.00 % 11.06 % [kworker/0:2]

Meine Recherche im Netz ergab,  dass es evtl. helfen könnte den Interval zu vergrößern, mit dem das EXT4 Dateisystems seine Metadaten auf die Platte schreibt. Der default ist 5 Sekunden. Ich habe Testweise das Interval auf 30 Sekunden erhöht (mount -o,remount,commit=30 /home). Leider hatte dies keine fühlbaren Verbesserungen gebracht.

Im Netz bin ich dann auf die Möglichkeit gestoßen, das EXT4 Dateisystem zu tracen und zwar folgendermaßen:

# starten des Kernel trace
echo 1 > /sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable

# auslesen des traces
cat /sys/kernel/debug/tracing/trace

Der obige Trace zeichnet auf, wenn ein fsync auf einem EXT4 Dateisystem ausgeführt wird. Folgendes lieferte der Trace während des Arbeitens in digikam:

[...]
# mehrere hundert Zeilen folgender Art:
digikam-2898  [000]   167.651034: ext4_sync_file_enter: dev 252,6 ino 3019998 parent 2228273 datasync 0 
digikam-2898  [000]   167.651685: ext4_sync_file_enter: dev 252,6 ino 3019257 parent 3019998 datasync 0 
digikam-2898  [001]   167.653826: ext4_sync_file_enter: dev 252,6 ino 3020412 parent 3019998 datasync 0 
digikam-2898  [000]   167.665824: ext4_sync_file_enter: dev 252,6 ino 3019259 parent 3019998 datasync 0 
digikam-2898  [001]   167.674035: ext4_sync_file_enter: dev 252,6 ino 3019998 parent 2228273 datasync 0
digikam-2898  [001]   167.674691: ext4_sync_file_enter: dev 252,6 ino 3019259 parent 3019998 datasync 0 
[...]

Mit find habe ich mir dann bei den häufig auftretenden Inode Nummern die dazugehörigen Dateien herausgesucht: z.B.:

find /home -inum 3019257
/home/neuntoeter/Fotos/thumbnails-digikam.db

Ich habe dann festgestellt, dass die sqlite Datenbanken digikam4.db und thumbnails-digikam.db die Auslöser für die fsyncs sind.

Nach ein wenig Recherche habe ich herausgefunden, dass bei sqlite Datenbanken diese fsyncs bei jeder Datenbankänderung normal sind (zumindest bei journal_mode=delete).

Digikam verwendet standardmäßig den Journal Mode “Delete”:

sqlite3 digikam4.db 
sqlite> pragma journal_mode;  
delete

Es gibt allerdings für sqlite Datenbanken ab Version 3.7 die Möglichkeit den journal_mode “WAL” zu verwenden. Mit diesem werden deutlich weniger fsync Aufrufe ausgeführt.

Ich habe nun mal den Journal Mode von digikam4.db und thumbnails-digikam.db auf WAL umgestellt:

sqlite3 digikam4.db  
sqlite> pragma journal_mode=WAL;

Und siehe da! Die Performance ist deutlich besser und es gibt deutlich weniger Festplattenaktivität.

Hier die Vergleichswerte mit journal_mode=wal und journal_mode=delete beim EXIF-Rotate von 4 Bildern in digikam:

Journal_mode=delete:

• Dauer EXIF-Rotate: 12 Sekunden
• Anzahl fsyncs von digikam: 171

Journal_mode=wal:

• Dauer EXIF-Rotate: 7 Sekunden
• Anzahl fsyncs von digikam: 32