Re: Debian Testing KDE/Plasma 6: Baloo
Hallo.
Hierzu jetzt doch noch eine Ergänzung, weil ich zufällig über einen
Fehlerbericht gestoßen bin, wo mir jemand genau das erklärt hat:
Martin Steigerwald - 27.04.25, 14:26:36 CEST:
> Von den knapp 10 GiB nutzt Baloo laut "indexSize" angeblich weniger als
> 1 GiB. Anders als bei der SQLite3-Datenbank von Akonadi kenne ich
> derzeit keinen Weg, da drin aufzuräumen: Außer mit „purge“ den alten
> Index zu löschen und Baloo einen neuen Index aufbauen zu lassen. Das
> kann ein valider Weg sein, um etwaige Altlasten im Index aufzuräumen.
> Das habe ich in der Phase, wo es deutliche Verbesserungen an Baloo gab
> ab und zu gemacht. Je nach Hardware und Daten-Menge kann das jedoch
> sehr lange dauern. Unter bestimmten Umständen löst Baloo jedoch laut
> Quelltext offenbar auch automatisch eine Art Migration aus. Nach einem
> Neu-Aufbauen des Index kann Baloo den aber wieder aufblähen. Über 340
> GiB ist aber doch etwas arg, das hatte ich noch nicht.
Es gibt doch eine Möglichkeit, die Datei zu verkleinern. Bei mir hat
dieser Weg die Größe etwas mehr als halbiert.
Vorher:
% balooctl indexSize
File Size: 12,36 GiB
Used: 900,62 MiB
[…]
Nachher:
% balooctl indexSize
File Size: 4,89 GiB
Used: 900,62 MiB
[…]
Das geht wie folgt:
- Sicherstellen, dass Baloo nicht läuft
- Wirklich sicherstellen, dass keine Baloo-Prozesse laufen!
- Nach „balooctl6 suspend“ oder „Indizierung anhalten“ kann es meiner
Erfahrung nach lange dauern, bis Baloo tatsächlich stoppt, wenn Baloo
gerade fleißig indiziert.
- Im Zweifelsfall freundlich die Prozesse beenden
- Wechseln nach „~/.local/share/baloo“
- mdb_copy -n -c index index.new
- mv index index.bak
- mv index.new index
- Baloo wieder starten
Vielleicht hilft das, den aufgeblasenen Such-Index zu reduzieren, ohne
alles neu indizieren zu müssen. Allerdings… möglicherweise ist der Weg
über „balooctl purge“ dennoch sinnvoller. Vielleicht ist da ja auch noch
irgendetwas inkonsistent im Index.
Mehr dazu:
"balooctl status" can trigger high memory use
https://bugs.kde.org/show_bug.cgi?id=437754#c3
Und zu den komischen Prozentzahlen bei „balooctl6 indexSize“:
baloo_file_extractor consumes an ever-increasing amount memory after
upgrade to frameworks 5.80.0
https://bugs.kde.org/show_bug.cgi?id=354636#c10
Im Idealfall würden alle solche Pflege-Geschichten im Hintergrund ablaufen
oder es gäbe zumindest etwas wie „balooctl6 vacuum“. Aber auch in Akonadi
ist „akonadictl vacuum“ auf eine SQLite3-Datenbank derzeit nicht
implementiert, während das für eine MariaDB-Datenbank durchaus
funktioniert. Es geht mit dem „sqlite3“-Befehl aber sehr einfach und das
sogar im laufenden Betrieb. Und mit SQLite3-Datenbank läuft Akonadi
zumindest bei mir deutlich runder. Nicht perfekt, aber deutlich schneller
als zuvor.
Ich bin der Meinung: Ein Anwender von einer Desktop-Suche oder einem
Mail-/Kalender-/Kontakte-usw.-Programm ist kein Datenbank- oder Index-
Administrator. In Bezug auf eine PIM Suite macht es Evolution von GNOME
vor. Das habe ich auf dem beruflichen Laptop und da habe ich unter der
Ebene der grafischen Oberfläche noch nie etwas gemacht. Ich weiß nicht
mal, wie oder wo genau das die Daten speichert. Das Teil funktioniert
einfach. Ich hab zwar weniger Mails da drin als auf meinem privaten
Laptop, aber… dennoch. Von der Zuverlässigkeit scheint mir Evolution
KDEPIM mit Akonadi haushoch überlegen zu sein. Und das sage ich als
Plasma-/KDE-Anwender.
Ciao,
--
Martin
Reply to: