私は、Zabbixデータベースをpostgresqlバックエンドに置いており、ディスク容量が1TBまで増えました。 Zabbix housekeeper (テーブルから古いデータを削除するプロセス)が18時間以上実行されていたため、パーティションを有効にするために this スクリプトを使用しました。
しかし、その後-ちょうど真夜中に-Zabbixは、新しいパーティションテーブルを作成する必要があるときに、データベースへのデータの挿入を停止しました。
pg_cancel_backend()
を介して実行中の自動バキュームプロセス(主にテーブルhistory
またはhistory_uint
)を強制終了すると、Zabbixサーバーが再度挿入できることがわかりましたいくつかのロックが消えるように 1。
トランザクションIDを解放するためにバキュームプロセスが必要であることを理解しているので、毎日これを行うべきではありません。
.public
および.partitions
のグローバルロックに起因すると想定)最終的な目標は、データベースの負荷を減らし、パフォーマンスを向上させることです。
パーティション分割を有効にすることで、history
とtrend_data
のハウスキーピングを無効にすることで、ハウスキーパーの実行時間を数分/秒に減らすことができました。しかし、監視が真夜中に動作を停止した場合、それは好ましい結果ではありません...
追加情報:
ハードウェアは非常に特大です(すべてのSSDで動作し、正常なだけです)。 Tweakのどのつまみが本当にわからないので、まったく触れない方がいいと思います。
1:残念ながら、私はこれを7時間後の朝に理解しました。現在、00:00から07:00までの2日間の監視データがありません。
通常の自動バキュームプロセスは、別のトランザクションをブロックするとサイレントモードで停止しますが、それが常に発生し、自動バキュームが終了しない場合は、最終的に、バキュームされていない古いテーブル行が存在します。トランザクションIDカウンターが循環するとすぐにデータが失われる危険を回避するために、PostgreSQLはnotがバックダウンするという、それほど好意的でない自動バキュームの実行をトリガーします。
テーブルの新しいパーティションを作成するには、パーティションテーブルにACCESS EXCLUSIVE
ロックが必要です。これは毎日発生するようで、autovacuumの実行速度が遅すぎて1日で終わらないように見えるため、自動テーブルパーティショニングのゴーストがチェーンをガタガタ動かし始める真夜中にスタックしてしまいます。
Autovacuumを殺すことは、問題を悪化させるだけなので、解決策ではありません。作業は失われ、PostgreSQLは再びautovacuumを開始します。たとえそれを沈黙させても、最終的にデータベースはデータの変更を拒否します。次に、データベースを停止して、シングルユーザーモードで起動し、手動でVACUUM
を実行するしかありません。これにより、停止時間が長くなるため、それは望ましくありません。
最良の解決策は、24時間以内に完了することを期待して、できるだけ速く実行できるようにautovacuumを調整することです。
autovacuum_work_mem
をできるだけ高く設定しますautovacuum_vacuum_cost_delay
を0に設定さらに、パーティションが多い場合は、autovacuum_max_workers
をいくらか増やす必要があります。
指を交差させて、深夜までに自動バキュームが完了することを期待してください。
あなたはのようなもので事態の状態を監視することができます
SELECT s.last_autovacuum, s.last_vacuum, age(t.relfrozenxid)
FROM pg_stat_all_tables AS s
JOIN pg_class AS t ON s.relid = t.oid
WHERE age(t.relfrozenxid) > 200000000
ORDER BY age(t.relfrozenxid) DESC;
そのリストが空になるまで作業を続けてください!
自動バキュームで24時間以内に1つのテーブルを完成できない場合は、しばらくの間、新しいパーティションの作成をスキップする(または少なくともパーティション分割されたテーブルにアタッチしない)ことが唯一の選択肢です。