web-dev-qa-db-ja.com

Postgresの長い自動真空停止データベース

かなり大きなテーブル（100万行）があり、データベースがこのテーブルの自動バキューム（> 30分）でスタックしているため、データベース全体がぎくしゃくしています。アプリケーションは今でもロードされません。

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

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

enter image description here

これらは、ユーザーテーブルの自動バキューム設定です。

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

私が使用したこれらの推奨設定 PostgreSQLのパフォーマンスが遅い？データベースをバキュームすることを忘れないでください

待たなければならないのですか？私のオプションは何ですか？

更新

Postgres 9.5にアップグレードし、RDS IOPSを900に増やしましたが、バキュームプロセスはまだIOPSを最大にしており、データベースに対して他に何もできません。プロセスは、アップグレードの1日前のある時点で実行されていました。

また、私が持っていたカスタムautovacuum設定を削除し、現在はデフォルトを使用しています。

以下は、これらのクエリの結果の添付です。

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

postgresqlpostgresql-9.5awsautovacuum
7
Andrew Cetinic

autovacuumによって起動されたVACUUMプロセスは、次のコマンドで安全に強制終了できます。

SELECT pg_terminate_backend(PID_of_backend);

実際、Postgresqlのクライアントプロセスはすべてこの方法で終了できます。このバックエンドによるコミットされていない作業は単に破棄されます。

次に、トラフィックの少ない時間に手動でVACUUMを再実行します。

VACUUM VERBOSE users;

コストベースの真空遅延 が役立つかどうかを確認します。これにより、autovacuumプロセスが使用するI/Oの量が制限されます。

多分あなたは単にあなたのIOPS制限に達しました。 AWSインターフェースで数値を確認できるはずです。スタンドアロンLinuxではiostat -dtkxy 10 I/Oを測定します。 （iostatは通常sysstatパッケージにパッケージ化されています）。

たぶんVACUUMは、設定のアグレッシブな設定が原因で、頻繁に再起動します。

5
filiprem