Ubuntus gwibber ist schrott!

Ich benutze häufig (vor allem, wenn ich an ubuntu-kisten sitze) gwibber, um meist eher bedeutungslose textstummel auf twitter und identi.ca zu posten. Wenn man einmal davon absieht, dass dieses programm für einen recht kleinen anwendungsfall einen recht großen speicherabdruck hinterlässt, ist es an sich ganz brauchbar.

Es ist vermutlich leicht vorstellbar, dass ich dieses stück softwäjhr oft sehr lange im hintergrund mitlaufen lasse. Genau dafür scheint mir so eine softwäjhr auch gemacht zu sein, dass sie ähnlich wie ein IRC-klient oder ein IM-programm gut im hintergrund laufen kann. Wenn mein nick erwähnt wird, bekomme ich eine kleine einblendung auf dem desktop, die mich zur aufmerksamkeit ruft.

So weit das gute.

Und nun das miese, also die art, wie dieses gwibber seine daten speichert. Und natürlich, wie dieses gwibber programmiert wurde.

Fange ich mal damit an, wie ich das problem entdeckt habe. Mir ist aufgefallen, dass einer der rechner, an denen ich häufig sitze, in regelmäßigen abständen in die knie ging. Es ist ein für meine verhältnisse ausgesprochen gut ausgestatteter rechner mit einer zweikern-CPU und 4 GiB RAM. Dennoch stand dieser rechner regelmäßig so sehr unter last, dass ich bei der audiobearbeitung probleme mit aussetzern bekam und es sogar zu rucklern beim abspielen von 720p-videos gekommen ist.

Natürlich empfand ich das als untragbar. Die video-probleme sind für mich eher untergeordnet, aber wenn ich keine klänge bearbeiten kann, ist ein kompjuter für mich kastriert. Ich benutze kompjuter verdammt noch mal zum musikmachen, und ich konnte das schon in den neunziger jahren mit meinem amiga machen, ohne mich mit derartigen aussetzern herumschlagen zu müssen.

Und deshalb habe ich mir dieses problem näher angeschaut.

Dabei ist mir schnell aufgefallen, dass der rechner in regelmäßigen abständen für mehrere sekunden eine CPU-auslastung von 100 prozent hat. Genauer gesagt: er wurde alle fünf minuten für ungefähr fünfzehn bis zwanzig sekunden unter so große last gesetzt, dass andere prozesse nicht mehr rund liefen.

Alle fünf minuten… schnell fiel mir ein, dass das genau die frekwenz war, mit der sich gwibber automatisch aktualisiert. Genauer gesagt: mit der sich ein hintergrund-prozess, der übrigens auch noch läuft, wenn man gwibber beendet hat, die fiepser und die statusmeldungen von identi.ca abholt, um sie lokal zu speichern. Ein aufruf von top an der kommandozeile brachte gewissheit, es war der prozess gwibber-service, der mir hier den spaß am rechner verdarb.

„Aber das ging doch früher“, habe ich mir gedacht.

Und dann bekam ich einen verdacht, dass gwibber wohl unmengen alter daten irgendwo gespeichert hatte und inzwischen probleme haben könnte, neue daten einzufügen.

Zeit, sich das einmal anzuschauen.

Zum glück speichert gwibber seine daten wie erwartet unter ~/.config/gwibber. In diesem verzeichnis liegt eine sqlite3-datenbank mit dem namen gwibber.sqlite herum. Ein schnelles ls -l führte dann dazu, dass mir einen kurzen moment lang die gesichtszüge entgleisten:

$ ls -l
-rw-r--r-- 1 elias elias 684362752 Apr 26 15:39 gwibber.sqlite
$ _

Dieses… ähm… tolle programm hat also im laufe der zeit 652,7 MiB an daten gespeichert. Kein wunder, dass das einfügen von daten in diese übergroße datei, das aktualisieren der indizes, und das anschließende benachrichtigen des GUI-prozesses gwibber, der aus dieser datei dann die neue ansicht ermittelt, ein bisschen last verursacht.

Ich dachte einen moment lang, dass gwibber niemals alte nachrichten löschen würde und dass die programmierer hirnlose vollpfosten seien, die ihre eigene softwäjhr gar nicht nutzen. Dieser gedanke erwies sich allerdings als halber trugschluss, denn in gwibber befindet sich sehr wohl etwas kohd, der die datenbank von alten einträgen befreit. In einer etwas obskuren SQL-anweisung mit zwei unter-SELECTs werden für jeden dienst alle nachrichten bis auf die letzten 2000 entfernt. Dies gilt allerdings nur für normale nachrichten. Gwibber hält… moment…

*tipptipptipp* SELECT stream, count(*) from messages group by 1;

…aber neben den „messages“ auch noch „images“, „links“, „lists“, „private“, „profile“, „replies“, „search“, „send_private“, „send_thread“, „user“ und „videos“ — und moment…

*tipptipptipp* SELECT operation, count(*) from messages group by 1;

…neben den empfangenen nachrichten („receive“) auch ein paar weitere nachrichtentypen, die als „lists“, „private“, „receive“, „responses“, „search“, „send“, „send_private“, „send_thread“ und „user_messages“ ausgewiesen sind. Was das alles bedeutet? Ich kann es in einigen fällen sicher erraten, und in anderen ist es mir eigentlich egal.

Entscheidend ist nur eines: alles, was gwibber davon selbst löscht, sind einträge, bei denen operation = "receive" und stream = "message" ist.

Und alles andere sammelt sich im laufe der zeit in einer datenbank an, über deren relationales desein ich an dieser stelle lieber den gnädigen schleier des schweigens senke, um nicht an einem akuten mangel unflätiger wörter zu verenden. Nur so viel sei hierzu noch angemerkt: Damit die datenbank auch schön moppelig werde und nicht gar zu viel platz auf der festplatte unbelegt bleibe, steht zu jedem eintrag einer nachricht auch noch das vollständige json-format, in dem er vom gwibber-service empfangen wurde, in der datenbank. Was die programmierer sich dabei gedacht haben? Ich weiß es nicht. Vielleicht wollten sie einfach eine möglichkeit der wiederherstellung haben, wenn einmal eine spalte mit daten verdampft. :mrgreen:

Nun gut, wenn gwibber das selbst nicht besser kann, muss ich das problem halt ein bisschen „spanabhebend“ lösen. Zum Beispiel, indem ich mit einer SQL-anweisung alle einträge lösche, die älter als dreißig tage sind. Und weil zu erwarten ist, dass ich diese wartungsaufgabe noch etwas häufiger vor mir haben werde, und weil andererseits nicht zu erwarten ist, dass die im auftrage canonicals meinen kompjuter unbrauchbar machenden gwibber-programmierer in der kommenden monaten etwas gegen dieses problem tun werden, ist es wohl am günstigsten, hierfür ein ganz schnelles skript zu hacken, dass man bei bedarf ausführt. Zum beispiel dieses hier:

#!/bin/bash

db_dir=~/.config/gwibber
db_name=gwibber.sqlite
db_keepdays=30

db_path=$db_dir/$db_name
db_keepsecs=$(($db_keepdays * 24 * 60 * 60))
db_deletebefore=$((`date +%s` - $db_keepsecs))

sqlite3 "$db_path" <<EOF
delete from messages where time < $db_deletebefore;
vacuum;
EOF

Eine kommentierte versjon des skriptes kann bei pastebin angeschaut und heruntergeladen werden — es ist also nicht nötig, hier bei bedarf die zwischenablage zu bemühen…

Nach aufruf dieses skriptes (und etlichen sekunden intensivens kratzens auf der festplatte) befanden sich bei mir nur noch die einträge der letzten dreißig tage in der datenbank. Wer ein anderes zeitfenster wünscht, kann für $db_keepdays einen anderen wert setzen.

Die größe der datenbank hat sich in meinem fall auf 83,5 MiB reduziert. Das ist zwar eine menge, aber es sind nur noch 13 prozent der ursprünglichen größe — die speicherverschwendung liegt an der stark redundanten datenhaltung. Und ich kann gwibber immer noch so benutzen, wie ich das will: ich kann meine timeline lesen und meine textstummel auf twitter und identi.ca veröffentlichen. Welchen vorzug der gespeicherte datenmüll aus anwendersicht haben sollte, ist mir auch nach kurzem lesen der gwibber-kwelltexte nicht aufgegangen.

Dabei fühlt sich gwibber jetzt deutlich schneller an. Und die systemlast bei aktualisieren ist so sehr reduziert, dass es nicht mehr zu derart üblen aussetzern kommt, wie ich sie weiter oben beschrieben habe.

Warum canonical seinem ubuntu eine derartige müllanwendung ausliefert, die den rechner in einer weise unbrauchbar macht, die „normale anwender“ einfach nur vor rätsel stellt (das ging doch vor ein paar wochen auch noch), gehört zu den fragen, mit denen man sich bitte an canonical wendet. Mein verdacht ist ja, dass die „zielgruppe“ canonicals leute sind, die niemals mit ihrem kompjuter arbeiten.

2 Antworten zu “Ubuntus gwibber ist schrott!

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.