Der belebte Tisch wird nicht gesaugt

Wir verwenden Postgres 9.2 unter Windows, um Zeitreihendaten mit niedriger Frequenz zu speichern: Wir fügen 24 Stunden, 7 Tage die Woche ohne Ausfallzeiten etwa 2000 Zeilen pro Sekunde pro Sekunde ein. Es gibt eine DELETE, die etwa alle 10 Minuten auf dem Tisch ausgeführt wird, um die Länge der Tabelle auf eine feste Anzahl von Tagen zu beschränken. Dies führt zu ziemlich stabilen 900 Millionen Zeilen. (Für Interessenten SELECT, INSERT, DELETEsind alle performant).

Als solches DELETEwird beim Löschen von Zeilen kein Speicherplatz freigegeben. Dafür müssen wir VACUUMrennen.

Ich habe das abgefragt pg_stat_user_tablesund VACUUMscheint noch nie gelaufen zu sein.

Was ich aus verschiedenen Dokumenten verstehe ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

Es scheint, dass das automatische Vakuum aktiviert ist und es auf anderen Tabellen ausgeführt wird.
Auto-Vakuum läuft nicht FULLund sollte keine exklusive Sperre für den Tisch erfordern.

Hat jemand irgendwelche Gedanken, warum Auto-Vakuum nicht läuft? Liegt das nur daran, dass der Tisch ständig besetzt ist?

Und es lohnt sich in diesem Fall , VACUUMnach jedem zu laufen DELETE(der alle 10 Minuten läuft)?

Bearbeiten:

Abfrage mit SQL über den folgenden SO-Link:

-[ RECORD 2 ]---+---------------------------
schemaname      | stats
relname         | statistic_values_by_sec
last_vacuum     |
last_autovacuum |
n_tup           |    932,315,264
dead_tup        |    940,727,818
av_threshold    |    186,463,103
expect_av       | *

und Rohleistung:

-[ RECORD 3 ]-----+---------------------------
relid             | 501908
schemaname        | stats
relname           | statistic_values_by_sec
seq_scan          | 12
seq_tup_read      | 4526762064
idx_scan          | 29643
idx_tup_fetch     | 2544206912
n_tup_ins         | 1573896877
n_tup_upd         | 0
n_tup_del         | 941176496
n_tup_hot_upd     | 0
n_live_tup        | 688858417
n_dead_tup        | 940727818
last_vacuum       |
last_autovacuum   |
last_analyze      |
last_autoanalyze  | 2014-08-09 01:36:21.703+01
vacuum_count      | 0
autovacuum_count  | 0
analyze_count     | 0
autoanalyze_count | 69

postgresql vacuum

— Barry
quelle

Siehe Aggressives Autovakuum unter PostgreSQL . Es wäre auch interessant, select * from pg_stat_user_tablesfür diese Tabelle zu haben (Verwendung \xin psql für eine schön formatierte Ausgabe)

— Daniel Vérité

Dieser Link ist hilfreich und beantwortet möglicherweise die Frage: Der Tisch ist zu voll, damit das automatische Vakuum funktioniert. @ DanielVérité Ich habe die Frage mit der von Ihnen angeforderten Ausgabe aktualisiert.

— Barry

Das sind viele tote Tupel! Wenn möglich, sollten Sie die Tabelle nach Zeitstempel partitionieren und die alten Partitionen löschen, anstatt sie zu löschen. Die größte Einschränkung besteht darin, dass ein eindeutiger Index über Partitionen hinweg nicht unterstützt wird.

— Daniel Vérité

Enthält die Protokolldatei Meldungen zum automatischen Vakuum in dieser Tabelle, die abgebrochen werden?

— Jjanes

@jjanes Nein - in den Protokollen gab es keinen Hinweis darauf, dass das Autovakuum jemals gestartet wurde.

— Barry

Ich würde mich mit Partitionierung befassen . Bei einer Partitionierung nach Tag können Sie die gesamte Partition einfach löschen, sobald sie zu alt ist. Möglicherweise müssen Sie nicht mehr staubsaugen.

Außerdem kann sich die Gesamtleistung erhöhen, da Sie nicht dort einfügen, wo Sie löschen. Sie müssten nur den Code schreiben, um neue Partitionen zu erstellen und alte zu löschen.

Genau dafür ist die Partitionierung gedacht.

— SQB
quelle