Zabbix でしか使用していない /var/lib/pgsql へのアクセスによるIOwaitの高負荷が周期的に発生する
OS：Rocky 8.4
Zabbix：5.4.7 （sever, agent2 共）
postgreSQL：13.3.1
気づいてみた結構前から発生していたようなのですが、バッチやバックアップ等の動いていない日中帯に、
1.5～2時間弱の周期で、40～50分程度サーバの負荷が IOwait での高負荷となり、
サーバ全体として高負荷状態になって、酷い時には、
TeraTerm やAWSのシステムコンソールからのアクセスにも応答しない
という状態に陥ってしまいました。
ひとまず、posrgreSQL 用のストレージの IOPS値を、デフォルトの 3000から 5000 に上げたところ、
今のところまったくアクセスできなくなる状況は再発していない状況です。
posrgreSQL は Zabbix でしか使用していないこと、ならびに、write の負荷も同時期に増加しているがさほとではなく、
read の負荷が極端に高いことから、Zabbix から周期的にそれなりの長時間重いアクセスを続けているように思われるのですが、
Zabbix でそのような周期的な処理をなにか行っていますでしょうか？
ちなみに、ブラウザ側からのZabbix に対するアクセスとしては、複数の画面で、該当サーバ等のダッシュボードのグラフを常時表示している状態で、
これらのアクセスにより、高負荷の山ができるとも思えませんし、
automatic vacuum も毎分実行されているもので、こちら高負荷の山の原因ではなさそうです。
同様な事象になったことがある方はいらっしゃいませんでしょうか？
すぐには原因の回答をいただけると一番ありがたいので、実際のところなかなか難しいと思っているので、
postgreSQL や Zabbix_server等のログでこんなメッセージが出力されていないかとかの、
調査の進め方でもいいので、どなたかご教授いただけませんでしょうか？
hige.no.papa - 投稿数: 53
補足情報です。
いままでは、potgreSQLの監視を行っていなかったので、これを機に
PostgreSQL by Zabbix agent 2
というテンプレートを入れてダッシュボードのzabbixのデータに関するグラフを見てみたところ、System performance のダッシュボードの read/write rates の posrgreSQL 用のストレージのグラフで、高負荷時の山としては低い write 側のグラフと、pg_stat_database_metrics のグラフの
・Tuples returned per second
・Blocks hit per second
の動きに関連性がありそうにみえました。
ただ、read/write rates の posrgreSQL 用のストレージのグラフの read側のグラフにおいては、それらとは関係なく、一定期間負荷の高い状態が続く形になっていて、それと類似した波形のグラフはありませんでした。
もし、このデータグラフで見た方がいいよといったものがございましたら、ご教授願います。
TNK - 投稿数: 4671
定期的に発生しているのであれば、housekeeperの処理だったりし
ませんか？
hige.no.papa - 投稿数: 53
ご回答ありがとうございます。
現状の zabbix_server.conf では、housekeeper についてのパラメータを明示的には何も指定していないので、
デフォルトの設定状態であるという認識ですので、基本的には１時間周期で実行されるものなのかと思ったのですが、
１回あたりにかかる時間が長いので、２時間周期で実施するよう調整されているのでしょうか？
そう思って、改めて、zabbix_server.log を見てみたところ、
「executing housekeeper」
のログが出た時刻と、山が始まる時刻がほぼ一致していて、
「housekeeper [deleted 2355586 hist/trends, 0 items/triggers, 16 events, 20 problems, 0 sessions, 0 alarms, 0 audit, 0 records in 3973.095745 sec, idle for 1 hour(s)]」
といったようばログが出た後に負荷が収束し始めているように見えます。
また、上記のログの記載通り、1時間の空きのあと次の回が起動されていました。
housekeeper であれば、必要な処理ということで、現状の設定のままとしておくしかないでしょうか？
それとも、現状１時間のインターバルを２時間に延ばす方法があるのか、まだ調査できてませんが、
インターバルを伸ばした場合に生じうる悪影響等ありましたらご教授いただけませんでしょうか？
ログの正しい見方を把握していませんが、上記の例だと、１時間のインターバルで、2,355,586 件のデータを削除したということに鳴るのでしょうか？
これでインターバルを２時間にすると、単純計算で削除件数が２倍の500万件になってしまうので、かえって負荷があがることに鳴ってしまいますでしょうか？
TNK - 投稿数: 4671
ご自身で書かれている通り、間隔を2時間にすれば削除しなければ
ならないレコード数は2倍になるので、より負荷がかかったり終了
するまでの時間が伸びてしまうだけだと思います。
データベースの処理性能を向上させるか、housekeeperを使用せず
にデータベースのパーティショニングの構成に変更するなどの対策
をご検討ください。
hige.no.papa - 投稿数: 53
コメントありがとうございます。
やはり、インターバルを伸ばすのは無意味、もしくは逆効果になりかねないということですね。
正直 posegreSQL は Zabbix でのデータ保存用にしか使ったことがなく、
チューニング的なことには、疎いのでご教授いただきたいのですが、
テーブルをパーティションに分ける方法は自分で調べることとして、
Zabbix用のみに使用している posegreSQL においては、
テーブル構成は Zabbix 特有のものになっていると思われますので、
その中で、パーティションに分割した方がいいテーブルとしては、
どのようなものが挙げられますでしょうか？
TNK - 投稿数: 4671
対象とすべきテーブルは、ヒストリやトレンドの各テーブルになる
と思います。(historyで始まるテーブルとtrendsで始まるテーブル)
TimescaleDBを使用するという選択肢もあるとは思いますが、実運
用でちゃんと使用したことが無いので、参考URLだけ書いておきま
す。
ご参考：
Amazon Aurora PostgreSQLでZabbixデータベースをパーティショニングしてみる
https://devlog.arksystems.co.jp/2023/04/18/18942/
大規模監視サーバでのPostgreSQL
https://www.pgecons.org/wp-content/uploads/2020/02/PGECons_20200212_Semi...
TimescaleDB による Zabbix の性能改善
https://www.sraoss.co.jp/tech-blog/zabbix/zabbix-timescaledb/