PostgreSQL Long VACUUM

Question

Ich bereite gerade eine Tabelle mit 2 Indizes und 250 Millionen aktiven Zeilen und etwa so viele tote Zeilen (oder mehr). Ich gab den Befehl VACCUM FULL ANALYSE von meinem Client-Computer (Laptop) an meinen Server aus. Es ist in den letzten 3-4 Tagen oder so seinen Geschäften nachgegangen; Ich frage mich, ob es bald zu Ende sein wird, denn ich habe viel zu tun!

Der Server verfügt über einen Quad-Code-Prozessor Xeon 2.66 GHz, 12 GB oder RAM und einen RAID-Controller mit 2 x 10K rpm SAS-Festplatten mit 146 GB in einer RAID 1-Konfiguration; Es läuft Suse Linux. Ich frage mich ...

Nun scheint erstens der VACUUM Postmaster-Prozess nur einen Kern zu nutzen. Zweitens sehe ich kein sehr hohes E/A-Schreib-zu-E/A-Leerlaufzeitverhältnis. Drittens kann ich vom Aufruf procinfo extrapolieren, dass der VACUUM-Prozess die meiste Zeit (88%) auf I/0 wartet.

Also warum nutzt es nicht mehr Kerne über Threads, um den RAID-Controller zu überlasten (hohe E/A-Schreibvorgänge im Leerlaufverhältnis)? Warum wartet es auf E/A, wenn die E/A-Last nicht hoch ist? Warum geht es nicht schneller mit all dieser Kraft/Ressourcen an seinen Fingern? Es scheint mir, dass VACUUM Multithreaded sein kann und sollte, besonders wenn es an einem riesigen Tisch arbeitet und es der einzige ist, der funktioniert!

Ist es auch eine Möglichkeit, postgresql.conf zu konfigurieren, damit es solche VACUUMs multithread? Kann ich es töten und trotzdem von seiner teilweisen Säuberung profitieren? Ich muss an diesem Tisch arbeiten.

[Ich bin mit PostgreSQL 8.1]

Thx wieder

Answer 1

Sie sagen nicht, welche Version von PostgreSQL Sie verwenden. Ist es möglich, dass es vor 8.0 ist?

Ich hatte genau dieses Szenario. Ihre beste besten:

• töten das Vakuum
• wieder auf den Tisch mit pg_dump Option -t
• den Tisch fallen
• Wiederherstellen der Tabelle

Wenn Sie 8.x verwenden , schau dir die Autovacuum-Optionen an. Vakuum ist single-threaded, es gibt nichts, was Sie tun können, um mehrere Threads zu verwenden.

Answer 2

Einige schnelle Tipps:

• Run VACUUM FULL VERBOSE so können Sie sich, was los ist.
• Alle Indizes vor dem VACUUM löschen. Es ist schneller, sie wieder aufzubauen, als sie zu saugen. Sie müssen sie auch hin und wieder neu aufbauen, da VACUUM FULL nicht gut genug ist (besonders bei solch einem alten PosgreSQL wie 8.1).
• Setzen Sie die Maintenance_work_mem wirklich hoch.
• Verwenden Sie einen neueren PostgreSQL. Btw, 8.4 wird eine große Verbesserung im Staubsaugen haben.

Eine Alternative zu VACUUM ist das Dump und Restore.

Edit: Seit 9.0 VACUUM FULL schreibt die ganze Tabelle neu. Es ist im Grunde dasselbe wie ein Dump + Restore, also ist REINDEX nicht notwendig.

Answer 3

Sind Sie sicher, dass Sie nichts haben, was Tabellen sperren und verhindern könnte, dass Vakuum läuft?

(Wie auch immer, ist es am besten vacuum_cost_delay zu verwenden, so dass das Vakuum bis zur Produktion nicht störend ist.)

Answer 4

Old VACUUM FULL ein Fossil ist. Es ist auch ziemlich langsam, und du bist danach zu REINDEX gekommen. Benutze es nicht. Wenn Sie wirklich eine Tabelle, verwenden CLUSTER, oder diese defragmentieren wollen:

Lettssay haben Sie einige Speicherplatz links, das ist viel schneller als & Reload-Dump:

CREATE TABLE newtable AS SELECT * FROM oldtable; 
CREATE INDEX bla ON newtable(...); 
ALTER TABLE oldtable RENAME TO archive; 
ALTER TABLE newtable RENAME TO oldtable; 

Hinweis: Das wird Ihre Zwänge nicht kopieren. Sie können CREATE TABLE LIKE ... verwenden, um sie zu kopieren.

Warum also nicht ist es mehr Kerne durch Fäden verwendet

pg dies nicht unterstützt.