Tabelle nicht exportierbar, nicht vacuumbar!

Hallo,
ich hab ein dickes Problem.
Ich habe eine Tabelle mit über 650.000 Einträgen. Meines Wissens nach wurde nie vacuum auf diese Tabelle ausgeführt. Es sind Indexe angelegt, die aber schon lange nicht mehr gewartet wurden (a la ReIndex).

Nun muss ich einen DB-Serverumzug vollziehen und von all den Tabellen lässt sich diese eine NICHT exportieren. Der Export VOrgang durch pg_dump bleibt bei dieser Tabelle hängen. Auch ein simples “select count(*) from tabelle” lässt mein PGAdmin hängen (über Count Befehl auf Tabelle oder eigene SQL). Auch geht kein vacuum, kein analyze. ABER dennoch funktioniert die Webseite die auf einzelne Einträge dieser Tabelle zugreift. Nur ich muss diese Tabelle exportieren.

Kann mir jemand helfen? Kennt sich einer mit solch einem Problem aus?

Danke und Gruß

Du könntest mal schauen, wie groß die Tabelle effektiv ist:

table size, database size - ads’ corner


Was sagt ein VACUUM FULL ANALYZE VERBOSE für diese Tabelle?

650.000 Einträge sind nicht sonderlich viel … das sollte an sich keine Probleme bereiten. Ich denke eher, das du sehr viele gelöschte Daten in der Tabelle hast und diese dadurch auf ein mehrfaches der notwendigen Größe aufgebläht ist.

Deine Webseite kann darum darauf zugreifen, weil eventuell immer nur einzelne Einträge abgefragt werden.

Hallo, danke für die schnelle Antwort.
Leider kann ich diese Abfragen nicht machen, da diese Funktionen nicht existieren.
Es handelt sich um PostgreSQL 7.4 auf Debian. vielleicht eine “zu alte” Version. Gibts da eine Möglichkeit?

Und VACUUM FULL ANALYZE VERBOSE auf diese Tabelle lässt eine Zeile erzeugen:

INFO: vacuume >public.spez<

Danach kommt nichts mehr. Das hatte ich schonmal versucht. Es passiert lange nichts. Da ich diesen Befehl auf dem Server direkt in der Console eingebe, lässt dieser die CPU auf 99.99% ansteigen durch ein Prozess “Perl”.

Die Befehle für die Objektgröße gibt es erst auf neueren PG Versionen, da wirst du Pech haben.

Und zur CPU-Last:

PostgreSQL: Documentation: Manuals: PostgreSQL 7.4: VACUUM

Ich würde sagen, das VACUUM hat einfach viel zu tun. Kann es sein, das deine I/O Last im gleichen Atemzug auch auf 100% gestiegen ist? Lass das einfach mal laufen, wenn du die Tabelle allerdings für den laufenden Betrieb brauchst, darfst du kein FULL benutzen.

Du kannst das VACUUM auch jederzeit abbrechen, aber da das wie du selber sagtest nie genutzt wurde, musst du wohl jetzt in den sauren Apfel beissen und die Zeit dafür aufbringen. Wenn das durchgelaufen ist, bin ich mal an dem Text interessiert, der da ausgegeben wird. Es gibt einen CODE Button über dem Eingabefeld des Forums, das alles einfach mal da hinein pasten.

Über die Nacht ist das noch OK.
Dann lass ich über Putty den vacuum verbose full analyze befehl an die tabelle geben und lass den output von putty abfangen.

Ich ging davon aus das der Server einfach immer abstürzt. Mal sehen. Hoffe das hilft. Danke dir. Melde mich dann “morgen”. :slight_smile:

Für solche Aktionen empfehle ich, die Datenbank Konsole in einem screen zu öffnen. Dann läuft selbige auch weiter, wenn dein Putty aus irgendwelchen Gründen (Netzwerkprobleme, 24h DSL Disconnect) unterbrochen wird.

Wie meinst du das genau? Mit Putty kenn ich das nicht. Wenn meine Verbindung weg ist, ist ja somit die SSH Session hin und wohl auch der vacuum prozess.

Ich kenne diese Screen Art nur von RemoteDesktop (aus dem Hause Microsoft). Wie mach ich das mit Putty?

Auskennen? Wie das, wenn man selbst solche Probleme nie hatte?

Aber ein Ratschlag: erhöhe die Speicherwerte für maintenance_work_mem und auch work_mem.

Andreas

Du machst ein Putty->SSH. Wenn Du auf der Shell bist, tippst Du ein: ‘screen’. Dann noch mal ENTER IIRC. Nun arbeitest Du ganz normal. Falls die Verbindung wegbrichst, tippst Du nach dem nächsten Login ‘screen -x’ ein und wunderst Dich…


Screen ist ein ‘muß man haben’ - Tool:
GNU screen

Andreas

Ok, leider funktioniert aus irgendeinem Grund vacuum ohne full nicht ganz.
Jedenfalls kam zumindest bei der FULL Variante ein bißchen Output nach ein paar Minuten.

Ich werde aber mit dem Screen Befehl mal heute Nacht die Full Variante laufen lassen. Denn die DB muss tagsüber auf jeden Fall erreichbar sein.

Ich habe übrigens per “du” Befehl das DATA Verzeichnis untersucht.

Ganze 46,6 GIGABYTE groß. Ohaaa.

Ohne FULL sollte es auch funktionieren, aber nicht so umfangreich aufräumen. Dabei bleibt halt etwas mehr verbrauchter Platz übrig.

Du kannst mal die Parameter anpassen, die akretschmer genannt hat.

Der verbrauchte Platz sagt erst mal gar nichts aus, weil wir nicht wissen, wieviel du an effektiven Daten in der DB hast. Welchen Platzverbrauch hättest du denn erwartet?

Da mir ja die DB bekannt ist, erwarte ich eine Maxima von 1GB.

Aber ich bin mittlerweile gespannt was die volle vacuum heute nacht bringt.

Danke euch nochmals. Werde mich melden (mit verbose ausgabe :-D)

Hallo nochmal,

ich habe doch noch ein Vacuum ohne FULL gemacht.

Hier die Ausgabe:
PS: PostgreSQL Version 7.4 auf Debian

postgres@loki:/root$ vacuumdb -d main -t spez_seite -z -v
INFO:  vacuume »public.spez_seite«
INFO:  Index »fki_spez_seite_anwendung_id« enthält 626881 Zeilenversionen in 3168 Seiten
DETAIL:  1788 Indexseiten wurden gelöscht, 1788 sind gegenwärtig wiederverwendbar.
CPU 0.15s/0.04u sec elapsed 2.81 sec.
INFO:  Index »spez_seite_pkey« enthält 626881 Zeilenversionen in 11280 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.63s/0.12u sec elapsed 48.38 sec.
INFO:  Index »spez_seite_domain_ind« enthält 626881 Zeilenversionen in 3163 Seiten
DETAIL:  1781 Indexseiten wurden gelöscht, 1781 sind gegenwärtig wiederverwendbar.
CPU 0.09s/0.03u sec elapsed 4.45 sec.
INFO:  Index »spez_seite_auto_gen_ind« enthält 626881 Zeilenversionen in 3173 Seiten
DETAIL:  1792 Indexseiten wurden gelöscht, 1792 sind gegenwärtig wiederverwendbar.
CPU 0.03s/0.03u sec elapsed 4.89 sec.
INFO:  Index »spez_seite_id_ind« enthält 626881 Zeilenversionen in 3431 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.12s/0.02u sec elapsed 13.71 sec.
INFO:  »spez_seite«: 0 entfernbare, 626881 nicht entfernbare Zeilenversionen in 5379363 Seiten gefunden
DETAIL:  0 tote Zeilenversionen können noch nicht entfernt werden.
Es gibt 113693787 unbenutzte Itemzeiger.
0 Seiten sind vollkommen leer.
CPU 100.58s/23.48u sec elapsed 2318.58 sec.
INFO:  vacuume »pg_toast.pg_toast_19658«
INFO:  Index »pg_toast_19658_index« enthält 18 Zeilenversionen in 2 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  »pg_toast_19658«: 0 entfernbare, 18 nicht entfernbare Zeilenversionen in 2 Seiten gefunden
DETAIL:  0 tote Zeilenversionen können noch nicht entfernt werden.
Es gibt 24 unbenutzte Itemzeiger.
0 Seiten sind vollkommen leer.
CPU 0.00s/0.00u sec elapsed 0.02 sec.
INFO:  analysiere »public.spez_seite«
INFO:  "spez_seite": 5379363 Seiten, 3000 Zeilen ausgewählt, 3787 geschätzte Zeilen insgesamt
VACUUM

“Es gibt 113693787 unbenutzte Itemzeiger.” Ist das nicht irgendwie ein bißchen viel?

Nachtrag: Der Speicherverbrauch von 46,6GB ist nicht weniger geworden.

Der Platzverbrauch wird erst wirklich geringer, wenn du FULL anwenden (kannst). Durch VACUUM werden die Plätze nur zur Wiederbenutzung markiert, sprich, in nächster Zeit dürfte sein Platzverbrauch (zumindest für diese Tabelle) nicht sonderlich steigen.

Mit VACUUM FULL wird der Platz weitgehend wieder freigegeben (mit der Option FREEZE noch agressiver).

Wie lange hat dieser VACUUM Lauf gebraucht? Wenn du die Anmerkungen von akretschmer noch einbaust, dürfte die Laufzeit noch mal geringer werden. Dann kannst du noch mal irgendwann einen VACUUM FULL laufen lassen.


Eine Alternative ist, die Tabelle zu dumpen, zu löschen und neu aus dem Dump einzuspielen. Hat den gleichen Effekt, funktioniert aber nur, wenn keine Foreign Keys betroffen sind.

Was ist Freeze? Hat das Nachteile? Da sowieso der Server über die Nacht wegen der Full nicht erreichbar sein wird, wird Freeze nicht weiter stören.
Kann aber dabei was schief gehen?

Ich habe mal vacuumdb --help eingegeben, da gibt es kein FREEZE. Wie wende ich das an. Hoffe das gibts in 7.4

Hier die Ausgabe von vacuumdb --help:

loki:~# vacuumdb --help
vacuumdb cleans and analyzes a PostgreSQL database.

Usage:
  vacuumdb [OPTION]... [DBNAME]

Options:
  -a, --all                       vacuum all databases
  -d, --dbname=DBNAME             database to vacuum
  -t, --table='TABLE[(COLUMNS)]'  vacuum specific table only
  -f, --full                      do full vacuuming
  -z, --analyze                   update optimizer hints
  -e, --echo                      show the commands being sent to the server
  -q, --quiet                     don't write any messages
  -v, --verbose                   write a lot of output
  --help                          show this help, then exit
  --version                       output version information, then exit

Connection options:
  -h, --host=HOSTNAME       database server host or socket directory
  -p, --port=PORT           database server port
  -U, --username=USERNAME   user name to connect as
  -W, --password            prompt for password

Read the description of the SQL command VACUUM for details.

Report bugs to <pgsql-bugs@postgresql.org>.

Muss noch etwas hinzufügen: du hast das “Problem”, das 7.4 bereits sehr alt ist. Es gibt zwar immer noch Support und Updates dafür, aber nächstes Jahr wird auch das zu Ende sein.

Als Debian oldstable (Sarge) herauskam, war die 7.4 auch bereits hinfällig und 8.0 “auf dem Markt”.

VACUUM wurde immer wieder optimiert, mit neueren Versionen gibt es da weniger Probleme.

Schaust du hier :wink:

PostgreSQL: Documentation: Manuals: PostgreSQL 7.4: VACUUM


Du brauchst also:
VACUUM FULL FREEZE ANALYZE VERBOSE tabellenname

Hallo,
ich habe die volle freeze der Tabelle nun durchgeführt. Die gesamte DB hat jetzt nur noch eine Größe von 2,6 GB. Das ist super.
Leider konnte ich den Output nicht lesen, war alles irgendwie falsch encodiert.

Ich habe nochmals analzye gemacht was jetzt natürlich ruck zuck ging.

INFO:  vacuume »public.spez_seite«
INFO:  Index »fki_spez_seite_anwendung_id« enthält 626881 Zeilenversionen in 3201 Seiten
DETAIL:  1397 Indexseiten wurden gelöscht, 1397 sind gegenwärtig wiederverwendbar.
CPU 0.10s/0.03u sec elapsed 7.06 sec.
INFO:  Index »spez_seite_pkey« enthält 626881 Zeilenversionen in 11322 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.35s/0.09u sec elapsed 45.41 sec.
INFO:  Index »spez_seite_domain_ind« enthält 626881 Zeilenversionen in 3206 Seiten
DETAIL:  1397 Indexseiten wurden gelöscht, 1397 sind gegenwärtig wiederverwendbar.
CPU 0.09s/0.07u sec elapsed 8.27 sec.
INFO:  Index »spez_seite_auto_gen_ind« enthält 626881 Zeilenversionen in 3208 Seiten
DETAIL:  1399 Indexseiten wurden gelöscht, 1399 sind gegenwärtig wiederverwendbar.
CPU 0.15s/0.03u sec elapsed 7.00 sec.
INFO:  Index »spez_seite_id_ind« enthält 626881 Zeilenversionen in 3440 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.12s/0.01u sec elapsed 12.92 sec.
INFO:  »spez_seite«: 0 entfernbare, 626881 nicht entfernbare Zeilenversionen in 31391 Seiten gefunden
DETAIL:  0 tote Zeilenversionen können noch nicht entfernt werden.
Es gibt 266113 unbenutzte Itemzeiger.
0 Seiten sind vollkommen leer.
CPU 1.26s/0.40u sec elapsed 89.98 sec.
INFO:  vacuume »pg_toast.pg_toast_19658«
INFO:  Index »pg_toast_19658_index« enthält 18 Zeilenversionen in 2 Seiten
DETAIL:  0 Indexseiten wurden gelöscht, 0 sind gegenwärtig wiederverwendbar.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  »pg_toast_19658«: 0 entfernbare, 18 nicht entfernbare Zeilenversionen in 1 Seiten gefunden
DETAIL:  0 tote Zeilenversionen können noch nicht entfernt werden.
Es gibt 3 unbenutzte Itemzeiger.
0 Seiten sind vollkommen leer.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  analysiere »public.spez_seite«
INFO:  "spez_seite": 31391 Seiten, 3000 Zeilen ausgewählt, 749868 geschätzte Zeilen insgesamt
VACUUM

Interessant ist das die Anzahl unbenutzter Itemzeiger gut gesunken ist. Dennoch sind da über 200000.

Es gibt 266113 unbenutzte Itemzeiger.

Nun, wie gesagt, ältere Datenbank.
Neuere Versionen können dabei besser aufräumen.

Aber im Endeffekt hast du ja erreicht, was du wolltest und deinen Speicherplatz wiederbekommen.

Eine Frage, die ich mir noch stelle: wenn das eine Debian Maschine ist, wieso ist der Cronjob deaktiviert, den es für VACUUM gibt?