Universal Search CPU-Last: Verursacht durch BTRFS-Replizierung

WilliW

Benutzer
Mitglied seit
17. Jan 2013
Beiträge
28
Punkte für Reaktionen
1
Punkte
3
Hallo zusammen,

ich habe auf meiner DS218 (DSM 6.2.4-25556 Update 3, bleibe bei der 6er Version, da ich den Logitech Media Server nutze) ein Problem mit Universal Search: Es bewirkt dauerhaft tagsüber mit den Prozessen fileindexd und synolelasticd eine Vollauslastung der CPU. Hier ein paar Infos:
  • Ich habe genau einen einzigen Ordner als zu indizierende angegeben. In bzw. unterhalb dieses Ordners sind etwa 20.000 Dateien mit 30GB, sehr viele große PDFs, denn genau für diese Volltextsuche möchte ich Universal Search nutzen. Wichtig: Der zu indizierende Ordner ist eine Unterordner eines per NFS freigegebenen "gemeinsamen Ordners".
  • In dem zu indizierenden Ordner findet nicht allzu viel Bewegung statt. Während des unten dargestellten Zeitverlaufs war eigentlich alles vollständig stabil. Über viele neue Dateien ist die ständige Indiziererei also nicht zu erklären.
  • Daran wird es liegen: Zu dem im nächsten Spiegelstrich gezeigten CPU-Verlauf mit der Pause zwischen 23:00 Uhr und 8:00 Uhr und der manchmal vor der vollen Stunden runtergehenden CPU-Last passt als einziges die BTRFS-Replizierung, die genau von 8:00 Uhr bis 22:00 Uhr einen stündlichen Snapshot macht. WICHTIG: Die Snapshots mache ich im Ordner #snapshot sichtbar, aber da der zu indizierende Ordner ein Unterordner ist, liegt der #snapshot-Ordner nicht im zu indizierenden Ordner. Sonst wäre natürlich klar, dass Universal Search immer wieder erneut den #snapshot-Ordner indizieren würde.
  • Hier sieht man die Auslastung der CPU über einen Tag. Die starke CPU-Last geht jeden morgen um 8:00 Uhr los und endet gegen 23:00 Uhr. Ein Durchlauf der Indizierung dauert etwa eine Stunde.
    1642755898200.png
  • Ich bin der Frage nachgegangen, was denn nun Universal Search veranlassen könnte, nach jeder Replizierung neu zu indizieren: Offenbar ändert jede Replizierung das Datei-Attribut "Change", obwohl der Inhalt ("Modify") der gleiche geblieben ist. Hier die Ansicht einer beliebigen Datei im Dateimanager und mit dem Kommando "stat":
    1642758134943.png
    1642758165696.png
    Modifiziert wurde Datei letztes Jahr, also kein Grund zur Neu-Indizierung. Der Change-Zeitpunkt liegt allerdings gute 6 Minuten nach der letzten stündlichen Replizierung, deshalb wohl das ständige Indizieren. "Change" bedeutet, dass irgendwelche Metadaten (z.B. permissions, owner, group) bei der Datei geändert wurden. Offenbar macht das die Replizierung bei jedem Durchlauf, so dass permanent alles neu indiziert werden muss :-(
Ich bin ein wenig ratlos, was ich da tun kann? Mir fallen dazu folgende Fragen ein:
  • Bin ich der einzige, der das Problem hat? Müsste doch schon anderen aufgefallen sein? Wenn nicht, habe ich etwas falsch konfiguriert? Wüsste nicht, wo....
  • Dass die Attribute aller Dateien bei der Replizierung geändert werden, ist ja eigentlich unnötig. Kann man das ändern? Ist das eine Eigenschaft des BTRFS-Systems oder hat da Synology etwas eigenes gebaut?
  • Wenn sich das Problem nicht lösen lässt, wäre ich auch mit folgendem Ansatz zufrieden: Indizierung immer nur nachts, wenn nicht repliziert wird (bzw. genau einmal, z.B. um 0:00 Uhr). Kann man das bei Universal Search einstellen, dass der Index nur einmal am Tag erstellt wird?
Die CPU-Auslastung macht die DSM zwar nicht unbenutzbar, aber es fühlt sich nicht gut an, sehr schade das Ganze. Da ich unter Linux arbeite, scheidet Copernic Desktop Search aus, Recoll legt unter Mint LMDE leider auch das System lahm.

Ich hoffe, jemand hat eine gut Idee! :)
 

geimist

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
04. Jan 2012
Beiträge
5.387
Punkte für Reaktionen
1.201
Punkte
234
Also bei mir wird durch die Snapshoterstellung das 'change' Datum nicht geändert.
Kannst du das eindeutig auf die Snapshots eingrenzen?
Wie verhält es sich, wenn du die Snapshots testweise deaktivierst?
Mich wundert, dass der Change-Zeitpunkt 6 Minuten nach der Snapshoterstellung liegt - das passt meiner Meinung nicht zusammen.
 

WilliW

Benutzer
Mitglied seit
17. Jan 2013
Beiträge
28
Punkte für Reaktionen
1
Punkte
3
Oh Mann...

Vielen Dank für den Hinweis, da hätte ich selbst auch noch einmal weiterschauen müsse. Habe es gerade gefunden: Eine nicht von mir stammende "Altlast" ändert per cron in den gemeinsamen Ordnern die group auf eine gemeinsame Gruppe, so dass alle Schreiben und Lesen können. Leider wird dabei nicht geschaut, ob die Dateien vielleicht vorher schon zu der entsprechenden Gruppe gehörten, sondern jede Datei wird mit chgrp "beglückt"...

Das werde ich dann mit einem find etwas selektiver gestalten, dann sollte das erledigt sein.

Vielen Dank und sorry für den Traffic.
 
  • Like
Reaktionen: geimist

Synchrotron

Benutzer
Sehr erfahren
Mitglied seit
13. Jul 2019
Beiträge
4.729
Punkte für Reaktionen
1.694
Punkte
214
Sorry for nothing - dafür ist das Forum doch da.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat