Generelle Erfahrungen mit VACUUM

Hallo zusammen,

vorweg möchte ich sagen, das ich ein mehr oder weniger Postgres Neuling bin und meine stärken eher bei mysql liegen. Nun nutze ich aber seit ca. 6 Monaten Postgres und habe einige Fragen zum Thema VACUUM.

Ich habe eine Datenbank in der in einer “files” Tabelle ca. 900.000 Einträge vorhanden sind. Über den Tag verteilt passieren eine Menge updates auf diese Tabelle und in der Nacht wird durch ein Aufraumscript eine Menge an Daten gelöscht.

Nun weiß ich das Postgres beim löschen die Dateien nur intern als gelöscht markiert und update eine Kopie der Daten anlegt und die alten als gelöscht markiert.

Autovacuum läuft auch, aber laut log Datei wird die files Tabelle nie angefasst.
Dazu kommt, dass wenn ich zum Beispiel einen meiner SQL Statements mit EXPLAIN anschaue und dann ein VACUUM files mache und danach erneut ein EXPLAIN die cost steigt, anstatt zu fallen.


Könnte mich einer der Experten vielleicht in die tiefen Geheimnisse von Vacuum einführen und mir sagen, was da falsch läuft?

Es dauert ungefähr einen bis zwei Monate und die DB ist nicht mehr zu nutzen. Ein dump und wieder einspielen der Daten hilft dann. Was mir eindeutig erscheint, da im Dump die als gelöscht markierten Datensätze nicht vorhanden sind.

Also warum fasst das auto vacuum die files Tabelle nicht an, warum wir die cost beim explain höher? Sollte ich, was ich gerade versuche, nachts nach dem Aufraumscript noch mal ein VACUUM machen? VACUUM FULL soll lange dauern aber besser sein, hat jemand Erfahrungen wie lange es mit einer so großen Tabelle dauern kann.

Postgress 7.4.x
Dual Intel® Xeon™ CPU 2.80GHz
2GB RAM

Grüße
the_sisko
aka cdk

Hallo the_sisko, aka cdk (?),

na ja, nach 6 Monaten sollte man ein alter Hase sein, zumal man schon Erfahrungen mit anderen Datenbanken gesammelt hat.



Und dabei wird viel “Müll” produziert!



Genau, so wird Müll produziert. Andere Datenbanken arbeiten aber auch so! Das Problem: Wie wird man den Müll wieder los?



Warum die Autovacuum die Tabelle nicht anfasst ist schon eigenartig. Werden denn andere Tabellen von Autovacuum angefasst? Ist Autovacuum aktiviert? Aber darüber würde ich mir im Augenblick die wenigsten Sorgen machen.

Warum die cost gerade bei großen Tabellen auch steigen kann, dazu gibt es einige Info in der Doku.



Muss man kein Experte sein! Vacuum ist eine Art von Müllentsorger, besser beschrieben, ein Defragmetierer



Dann wird es höchste Zeit etwas zu tun.

  1. Den Befehl Vacuum studieren. Es hat mehrere Modes.
  2. Kurz Autovacuum anschauen, damit man versteht, was dieser genau (nur!) macht.
  3. Das Kapitel 22 “Routine Database Maintenance Tasks” genau durchlesen.
  4. Seine Hausaufgaben als DBA machen. Notwendige Schritte sind in Kapitel 22 beschrieben.



Um einen Crasch zu vermeiden und um zeitlich Luft zu bekommen, sollte als erstes ein VACUUM FREEZE durchgeführt werden. Diese wird auch keine Ewigkeit dauern. Für große Aktionen ist am Wochenende auch immer Zeit genug vorhanden. Vorher sollte aber das Backup erfolgen!

Die Strategie für die Zukunft sollte nach dem Studium des Kapitels 22 festlegt werden. Diese ist auch von der Applikation abhängig.



Vielleicht ist ein Update auf die aktuelle Version angesagt. Bezüglich Autovacuum gibt da auch einige Neuerungen!



mfg

fristo

Danke schon einmal für die ausführliche Antwort. Ich bin nun ein wenig am Testen und Scripte für die Nacht schreiben.

Eine kurze zwischen Frage hätte ich jedoch. Ich habe auf dem Backupsystem etwas mit vacuumdb gespielt und bekomme bei -v öfters eine Zeile wie diese:

DETAIL: 7530 tote Zeilenversionen können noch nicht entfernt werden.

Was heißt das? Werden die erst bei einem FULL (-f) gelöscht oder so nach und nach bei den nächsten durchlaufen?

Hallo the_sisko,

warum diese Zeilen nicht entfernt werden können, kann ich Dir auch nicht sagen. Mir liegt auch keine weitere Fehlerbeschreibung hierzu vor. Um dieses herauszufinden bleibt im Endefekt nur übrig, den Sourcecode des Programmes zu analysieren.

Ob es mit -f funktioniert muss Du selbst testen. Ich kann es mir aber nicht vorstellen. Um eine saubere Datenbank zu bekommen, solltest Du dann ein Dump erstellen und die Datenbank wieder neu aufbauen. Meistens hilft das.

Da die Datenbank z.Z. Probleme hat , ist es wichtig sie zu täglich zu beobachten, d.h die Protokolle zu analysieren, um die Ursache herauszufinden. Dies kann dauern.

Desweitern solltest Du die Release Notes (mehr als 20) von PostgreSQL mal analysieren. Eventuell war ein Bug vorhanden, der zwischenzeitlich behoben wurde. Ein Update auf die aktuelle Version wäre dann mit Sicherheit angesagt.


mfg

fristo

Ein Update auf die 8.8.X ist auch schon geplant, jedoch erst ende nächsten Monats.
Ich bin fleißig am lesen und optimieren. Noch bin ich optimistisch das ganze in den Griff zu bekommen.

Ich melde mich die Tage über mit meinen Ergebnissen.

Hi,

ich hatte mir damals für die 8.0er das Initskript gemacht:

#! /bin/bash

PGVAC_BIN=/usr/bin/pg_autovacuum
PGVAC_LOG=/var/log/postgresql_autovac.log
PGVAC_COSTDELAY=0
PGVAC_PAGEHIT=6
PGVAC_COSTPAGEMISS=10
PGVAC_COSTPAGEDIRTY=20
PGVAC_COSTLIMIT=100
PGVAC_SLEEP=10
PGVAC_DEBUG=0                                  
PGVAC_BTHRES=400
PGVAC_SFACTOR=0.4
PGVAC_ABTHRES=100
PGVAC_ASFACTOR=0.3

PG_HOST=localhost
PG_PORT=5432
PG_USER=postgres

test -x $PGVAC_BIN || exit 5

. /etc/rc.status

rc_reset

case "$1" in
    start)
        echo -n "Starting pg_autovacuum daemon"
        startproc $PGVAC_BIN -H ${PG_HOST} -a ${PGVAC_ABTHRES} -A ${PGVAC_ASFACT
OR} -v ${PGVAC_BTHRES} -V ${PGVAC_SFACTOR} -d ${PGVAC_DEBUG} -D -c ${PGVAC_COSTD
ELAY} -C ${PGVAC_PAGEHIT} -m ${PGVAC_COSTPAGEMISS} -n ${PGVAC_COSTPAGEDIRTY} -l 
${PGVAC_COSTLIMIT} -s ${PGVAC_SLEEP} -p ${PG_PORT} -U ${PG_USER} -L ${PGVAC_LOG}
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down pg_autovacuum daemon"
        killproc -TERM $PGVAC_BIN
        rc_status -v
        ;;
    try-restart)
        $0 status >/dev/null &&  $0 restart
        rc_status
        ;;
    restart)
        $0 stop
        $0 start
        rc_status
        ;;
    status)
        echo -n "Checking for pg_autovacuum daemon: "
        checkproc $PGVAC_BIN
        rc_status -v
        ;;
    *)
        echo "Usage: $0 {start|stop|status|try-restart|restart}"
        exit 1
        ;;
esac
rc_exit

Und dann ab und an mal ein “vacuum analyze” gestartet. “vacuum full analyze” habe ich bisher nicht sehr oft benutzt. Nur wenn die Performance wirklich am Ende war.

pg_autovacuum ist ab postgres 8.1 im Hauptkern als Modul. Da fällt das Init-Skript weg. Ich möchte nächsten Monat auf die 8.1.3 umsteigen :slight_smile: . Bin schon ganz gespannt darauf!

Viele Grüße,

pingufreak

p.s.: warst du schon bei powerpostgresql.com ? hast du die wal’s auf eine andere platte ?