Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Autovacuum

Schon mit Version 8.1 hat PostgreSQL Autovacuum eingeführt und für jedes weitere Release daran gefeilt. Autovacuum führt bei Bedarf automatisch »VACUUM« und »ANALYZE« im Hintergrund durch. Autovacuum lässt sich für alle Datenbanken und Tabellen in der »postgresql.conf« konfigurieren. Da es jedoch schwierig ist, für alle Tabellen gemeinsame Bedarfskriterien zu ermitteln, lassen sich die Parameter für Autovacuum beim Anlegen einer Tabelle mit »WITH (Storage-Parameter [= WERT [, ... ] )« dem »CREATE TABLE« mitgeben oder später durch »ALTER TABLE ... SET (Storage-Parameter = Wert [, ... ] )« ändern. Damit Autovacuum überhaupt läuft, sollte der Parameter »autovacuum = on« gesetzt sein. Autovacuum ist abhängig von den Statistiken. Es braucht die Anzahl geänderter, gelöschter und neuer Zeilen, um den Bedarf für »VACUUM« beziehungsweise »ANALYZE« herauszufinden. Damit die für Autovacuum interessanten Statistiken gesammelt werden können, muss der Parameter »track_count = on« gesetzt sein. Beide Parameter sind per Default eingeschaltet.

Mit eingeschaltetem Autovacuum erscheint in der Prozessliste der Prozess: »autovacuum launcher process« . Der Launcher startet die Autovacuum-Arbeitsprozesse (»autovacuum worker process« ) aller Datenbanken. Hierbei wird ein Worker (Arbeiter) losgeschickt, der sich jede Tabelle in der Datenbank anschaut und bei Bedarf »VACUUM« und/oder »ANALYZE« ausführt.

Der Launcher startet alle »autovacuum_naptime« Sekunden pro Datenbank je einen Worker. Per Default ist »autovacuum_naptime = 1min« . Gibt es n Datenbanken, dann wird alle »(autovacuum_naptime/N)« Sekunden ein Worker pro Datenbank in Gang gesetzt. Die maximal zeitgleich laufende Anzahl an Workern wird in »autovacuum_max_workers« festgelegt. Der Defaultwert ist 3. Gibt es mehr Datenbanken als »autovacuum_max_workers« , dann nimmt sich der Worker, der als Erstes fertig ist, die nächste Datenbank vor. Die Defaultwerte der Parameter »autovacuum_naptime« und »autovacuum_max_workers« sind normalerweise ausreichend.

Wichtig sind hier die Regeln, die den Bedarf für »VACUUM« beziehungsweise »ANALYZE« festlegen, was gar nicht so einfach ist. Es gibt Sonderfälle, auf die hier nicht weiter eingegangen wird, in denen Autovacuum immer ein »VACUUM« ausführt. Im Normalfall führt Autovacuum ein »VACUUM« durch, wenn seit dem letzten Mal die Anzahl toter Tupel einen Schwellwert (»vacuum threshold« ) überschritten hat.

Komplizierte Regeln

Der Schwellwert errechnet sich aus:

Basisschwellwert (autovacuum_vacuum_threshold) +Prozentfaktor (autovacuum_vacuum_scale_factor) * pg_class.reltuples

Der Basisschwellwert (»autovacuum_vacuum_threshold« ) steht für die Mindestanzahl toter Tupel einer Tabelle. Seit Release 8.3 ist der Defaultwert 50. Für kleine Tabellen und Tabellen mit wenigen Änderungen kann dieser Wert zu hoch sein. Für große Tabellen und Tabellen mit vielen Änderungen kann dieser Wert jedoch schnell zu klein sein. Daher wird zu dem Basisschwellwert noch ein Wert addiert, der in einem Verhältnis zu den nicht-toten Tupeln der Tabelle steht. Seit Release 8.2 ist der Defaultwert für »autovacuum_vacuum_scale_factor« »0.2« (PostgreSQL akzeptiert hier nur die englische Schreibweise mit Punkt statt Komma). »0.2« steht für 20 Prozent. Autovacuum führt also ein Vacuum durch, wenn die Anzahl toter Tupel mindestens 20 Prozent der nicht toten Tupel plus 50 ist. Auch für die Ausführung von »ANALYZE« hat Autovacuum einen Schwellwert:

Basisschwellwert (autovacuum_analyze_threshold) + Prozentfaktor (autovacuum_analyze_scale_factor) * pg_class.reltuples

Der Defaultwert für »autovacuum_analyze_threshold« ist ebenfalls 50. Der Defaultwert für »autovacuum_analyze_scale_factor« ist 0.1.

Kleine Tabellen fallen hier eventuell ganz durch das Raster. Auch Tabellen mit zwar wenigen, aber speicherintensiven Änderungen, könnten hier jedoch auch unerkannt bleiben. Für Tabellen mit sehr vielen Änderungen, könnten die Werte daher zu klein sein, sodass Vacuum im Hintergrund dauernd ausgeführt wird. Es ist nicht einfach hier einen guten Mittelweg zu finden. Selbst bei einer einzigen Datenbank können die Tabellen sehr unterschiedlich ausfallen und unterschiedliche viele Datenänderungen aufweisen. Daher lassen sich die Werte beim »CREATE TABLE« und mit »ALTER TABLE« tabellenspezifisch überschreiben.

Gängige Praxis, um wirklich sicherzugehen, dass alle Tabellen regelmäßig »VACUUM« und »ANALYZE« durchlaufen, ist nach wie vor einmal pro Tag, zur Zeit des geringsten Traffic (meist nachts) »VACUUM« und auch »ANALYZE« via Cronjob auszuführen. PostgreSQL kennt daher speziell für die Shell auch das Kommando »vacuumdb« dem der Administrator zusätzlich verschiedene Optionen mitgegeben kann.

Mit dem Parameter »log_autovacuum_min_duration« lassen sich Autovacuum-Aktivitäten mitlogen. Per Default ist das Mitschreiben abgeschaltet (-1). Wird »log_autovacuum_min_duration = 0« gesetzt, dann werden alle Aktivitäten gelogt. Wird eine Zahl größer » « eingestellt, so werden nur die Autovacuum-Aktivitäten gelogt, die diese Anzahl in Millisekunden länger brauchen.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019