#Proxmox ubpdatedb.mlocate verursacht D-State Prozess und frist Resourcen#Proxmox updatedb.mlocate much D-State Processes – use much Resources#Proxmox updatedb.mlocate – mucho D-State Processes y bajo de Velocidad

ACHTUNG: Nicht nur ein Problem unter Proxmox!

Von Tag zu Tag wurde der Resourcen-Verbrauch immer größer und vServer litten unter massig D-State-Prozessen, die unter anderem durch updatedb.mlocate verursacht wurden! Dies hatte die Folge, daß die IO-Wait-Time von Tag zu Tag drastisch stieg!

Läuft updatedb.mlocate zu lange, dann liegt dies sicher an einer ungünstigen Konfiguration, nicht jedoch, ist an einen Fehler von updatedb.mlocate zu denken!

Wir haben vorher geprüft mit htop und Sortierung nach S, welche D-State Prozesse lange liefen und immer wieder fanden wir hier updatedb.mlocate. Nach einem kill (ohne -9), ging die IO-Wait-Time drastisch wieder runter! Also klar und eindeutig ein Indiz, daß updatedb.mlocate unsere Resourcen gefressen hat!

Hier unsere Tricks für Analyse und Abhilfe:

Was macht updatedb.mlocate überhaupt?

updatedb.mlocate erstellte eine Datenbank und aktualisiert diese täglich, um Dateien auf dem Server schneller finden zu können. Befehle, die verwendet werden, um zu suchen sind z.B. find und locate. Das generelle Abschalten ist also KEINESFALLS sinnvoll!

Wir konnten 12 Stunden updatedb.mlocate – Laufzeit auf knapp 30 Minuten täglich reduzieren! Wollen wir also mal genauer analysieren:

In htop ermitteln wir in der Zeile, wo updatedb.mlocate auftaucht, erst einmal die Proess-ID (pid). Diese merken wir uns und verlassen htop oder machen eine 2. ssh-Session auf.

Wir geben dann ein, wobei Sie [pid] durch die Prozess-ID (pid) ersetzen:

lsof -p [pid]

És werden nun alle geöffneten Dateien, die von updatedb.mlocate geöffnet sind, angezeigt. Rufen Sie die Abfrage mehrfach auf und Sie sehen sicherlich Dateien, die gescannt werden, die unnötig sind, für eine Suche, so z.B. Backup-Verzeichnisse – Zwischenspeicherungen etc.

Lesen Sie nachfolgend, wie wir das Problem in den Griff bekommenBeenden Sie nun den ubdatedb.mlocate – Prozess, indem Sie folgendes eingeben – bitte aber ohne -9 !!!

kill [pid]

Schauen Sie sich nun in htop die Auslastung an und sowie updatedb.mlocate aus htop verschwindet, geht die IO-Wait-Time runter!

Also hat sich Ihr Host überwiegend mit teilweise überflüssigen Aufgaben beschäftigt! Daß wollen Sie nun ändern, denn „Ich bin Dein Herr und Meister!“

Wie oft läuft nun eigentlich updatedb.mlocate?

Der Job wird täglich einmal gestartet und läuft mit ionice -c3 – Das bedeutet, daß updatedb.mlocate eigentlich nur laufen sollte, wenn KEIN Lese und Schreibzugriff auf der/den Platten erfolgt, aber daß ist leider wohl nicht ganz richtig, so wie man es in vielen Linux-Derivaten feststellen kann – die Probleme tauchen nämlich überall auf!

Erfolgen dann auch noch Sicherungen, wie Backups, die meist auch mit inonice -c3 laufen, so bauen sich dann immer mehr D-State-Prozesse auf und die vServer bekommen so wenig Plattenzugriff, daß sie immer langsamer werden ….., insbesondere dann, wenn z.B. Backups nicht kompremiert werden, sondern unausgepackt gespeichert werden (um die Server noch weiter zu beschleunigen – dies ist dann ein anderes Thema – sollte der Link hier übermorgen noch fehlen, bitte via Kommentar danach fragen!)

Wir haben sicherlich festgestellt, daß mit updatedb.mlocate überflüssige Verzeichnisbäume gescannt werden, was natürlich wahnsinnig viel Zeit und Disk-IO  kostet. Um das abzustellen, editieren Sie nun folgende Datei mit

vi /etc/updatedb.conf

Hier können Sie ganze File-Systeme als nicht zu scannen eintragen in PRUNEFS und auch ganze Verzeichnisbäume in PRUNEPATHS einfügen, wie z.B. /vz/backup dann mit korrektem Eintrag /vz/lib/vz/backup. Die Datei sieht dann ca. wie folgt aus:

PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media /var/lib/vz/backup1 /var/lib/vz/backup2 /var/lib/vz/backup3 /var/lib/vz/backup4 /var/lib/vz/backup5 /var/lib/vz/backup6 /var/lib/vz/backup7 /var/lib/vz/backup8 /var/lib/vz/backup9 /var/lib/vz/ezvzdump"
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs"

Speichern Sie die Datei.

Nun wollen wir probieren, ob so richtig Performance sparen, indem wir den Job manuell aufrufen:

Wechseln Sie in folgendes Verzeichnis:

cd /etc/cron.daily

und starten Sie den Job wie folgt:

./mlocate

Prüfen Sie nun htop. Prüfen Sie in einer anderen Session mit lsof [pid] die offenen Dateien. Die Dateien, die Sie oben ausgeschlossen haben, werden nun nicht mehr gescannt. Der Vorgang wird jetzt vielleicht auch noch ein paar Minuten laufen, aber wesentlich schneller fertig werden!

Schreiben Sie uns einen Kommentar und folgen Sie uns, indem Sie auf einen folgenden Link klicken, damit Sie weiterhin tolle neue Tips erhalten!

Prüfen Sie auch, ob ionice installiert ist, indem Sie einfach mal ionice eingeben, wobei Sie ähnliche Antwort erhalten: none: prio 4

und ob im Script /etc/cron.daily/mlocate ziemlich am Ende, updatedb.mlocate mit ionice aufgerufen wird!

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert