Postgres lange Autovakuum-Stopp-Datenbank

Ich habe eine ziemlich große Tabelle (1 Million Zeilen) und meine Datenbank befindet sich in einem Autovakuum (> 30 Minuten) in dieser Tabelle, wodurch die gesamte Datenbank blockiert wird. Die Anwendung wird jetzt nicht einmal geladen.

-00:37:31.137859 autovacuum: VACUUM public.users

SELECT n_tup_del, n_tup_upd FROM pg_stat_all_tables WHERE relname = 'users';

Dies sind meine Autovakuum-Einstellungen in meiner Benutzertabelle:

autovacuum_vacuum_scale_factor=0.0, 
autovacuum_vacuum_threshold=5000,
autovacuum_analyze_scale_factor=0.0,
autovacuum_analyze_threshold=5000

Diese vorgeschlagenen Einstellungen habe ich von Slow PostgreSQL Performance verwendet? Vergessen Sie nicht, Ihre Datenbank zu staubsaugen

Muss ich nur abwarten? Was sind meine Optionen?

Aktualisieren

Ich habe ein Upgrade auf Postgres 9.5 durchgeführt und mein RDS-IOPS auf 900 erhöht. Der Vakuumprozess maximiert immer noch das IOPS und kann nichts anderes mit der Datenbank tun. Der Prozess wurde 1 Tag vor dem Upgrade zu einem bestimmten Zeitpunkt ausgeführt.

Ich habe auch die benutzerdefinierten Autovakuum-Einstellungen entfernt, die ich hatte, und verwende jetzt nur die Standardeinstellungen.

Hier ist ein Anhang der Ergebnisse dieser Abfragen;

SELECT * FROM pg_stat_activity;
SELECT * FROM pg_stat_database;
SELECT * FROM pg_stat_user_tables;
SELECT * FROM pg_stat_user_indexes;
SELECT * FROM pg_locks;

http://www.filedropper.com/output_5

— Andrew Cetinic
quelle

1G aktualisierte Tupel in einer 1M-Zeilentabelle? Sie führen einige umfangreiche Updates durch. Es besteht die Möglichkeit, dass Ihr Problem besser angegangen wird, unabhängig davon, um was es sich handelt.

— Dekso

@dezso yea Ich denke, die Hauptursache des Problems sind einige wichtige Updates, die ich in der Tabelle mache, um sie zu aktualisieren, wenn Benutzer online sind. Ich habe beschlossen, dies in eine Redis-Datenbank zu verschieben, um die Probleme hoffentlich zu beheben.

— Andrew Cetinic

Wenn das Autovakuum lange dauert, drosselt es sich vermutlich von selbst und Sie sollten sich vacuum_cost_limitauf etwas Höheres einstellen , aber schwer zu sagen, wie das mit dem IOPS-Problem zusammenhängt, das Sie sehen

— jberryman

VACUUM Prozesse, die durch Autovakuum gestartet werden, können sicher beendet werden mit:

SELECT pg_terminate_backend(PID_of_backend);

Tatsächlich können alle Clientprozesse in Postgresql auf diese Weise beendet werden. Nicht festgeschriebene Arbeiten von diesem Backend werden einfach verworfen.

Sie können dann VACUUMmanuell zu einer verkehrsarmen Zeit erneut ausführen :

VACUUM VERBOSE users;

Prüfen Sie, ob eine kostenbasierte Vakuumverzögerung Ihnen helfen kann. Dies würde die Menge an E / A begrenzen, die Ihr Autovakuumprozess verwendet.

Vielleicht haben Sie einfach Ihr IOPS-Limit erreicht. Sie sollten die Zahlen auf der AWS-Oberfläche sehen können. Verwenden Sie unter eigenständigem Linux die iostat -dtkxy 10E / A-Messung. ( iostatwird normalerweise im sysstatPaket verpackt ).

Vielleicht VACUUMtritt das so oft wieder auf, wegen der aggressiven Einstellungen in deiner Konfiguration.

— Filiprem
quelle

Die Installation und Verwendung dieser beiden Tools ist auf einer RDS-Instanz nicht möglich.

— Dekso