I/O Probleme mit digikam

June 21, 2012

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


Advertisements

Digikam 1.0.0-beta5 verwendet Openstreetmap Karten

November 3, 2009

Digikam kann schon ein ganze Weile Fotos auf einer Karte darstellen. Hierfür gibt es die Geolocation Ansicht, welche auf marble aufsetzt. Bisher wurde an dieser Stelle eine ungenaue und wenig detailierte Karte angezeigt. In der aktuellen Version können die Fotos nun auch auf der Openstreetmap Karte dargestellt werden.

digikam_with_osm

Beim herauszoomen aus der Karte werden nebeneinander liegende Bilder zu einem einzelnen zusammengefasst. Auf diesem wird wiederum die Anzahl der zusammengefassten Bilder angezeigt.  Somit wirkt die Karte auch dann nicht überladen, wenn sehr viele Fotos in einem kleinen Gebiet geschossen wurden.

Besonders praktisch finde ich, dass man das Feature mit der digikam Suche kombinieren kann. So kann man sich ganz einfach anzeigen lassen, wo man an einem bestimmten Tag gewandert ist (siehe Screenshot) oder sich z.B. alle mit “Strand” getaggten Fotos auf der Karte anzeigen lassen.

digikam_osm_search

Ein Feature vermisse ich leider noch in der Kartenansicht: Praktisch fände ich es, wenn beim Klick auf ein Foto in der Karte das Foto vergrößert dargestellt würde. Leider passiert beim Klicken auf ein Bild im Moment gar nichts.
Ich werde gleich mal auf kde.org einen Feature Request eintragen (http://bugs.kde.org/show_bug.cgi?id=212967).


%d bloggers like this: