[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: