キュー遅延対策について
Zabbixサーバを運用して7年程経ちますが、
ここ１年ほどで徐々にキューがたまるようになってきました。
WEBの管理画面の「管理」＞「キュー」で見ますと
更新待ちアイテムのキュー（10分以上）で、多いときでは25000～40000ほど貯まります。
多くの場合は、時間が経つと貯まったキューの値は減っていくのですが
長時間貯まったままになってますと、サーバをOSから再起動したこともございます。
監視対象は少しづつ増えておりますが、
何か設定を変更することでキューが貯まらなくなるような対策についてご教示いただけないでしょうか。
もしくは確認する設定項目などございましたらご教示ください。
お手数ですがよろしくお願いします。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
・基本情報
Zabbixサーバ
OS CentOS5.1（Final）
Zabbix version zabbix-2.0.12-1.el5
SQLversion mysql 5.0.95
Zabbixサーバ
仮想基盤 KVM
memory 10GB
CPU 4個
Disk 1TB（iSCSI)
監視基本情報
ホスト数 (有効/無効/テンプレート) 2643 2389 / 200 / 54
アイテム数 (有効/無効/取得不可) 71937 61972 / 9557 / 408
トリガー数 (有効/無効)[障害/不明/正常] 24990 24539 / 451 [177 / 0 / 24362]
ユーザー数 (オンライン) 485 7
1秒あたりの監視項目数(Zabbixサーバーの要求パフォーマンス) 228.12
※特徴として、Zabbixプロキシが480台程ございます。
・設定情報
・zabbix_server.confより抜粋
LogFileSize=0
StartPollers=50
StartPollersUnreachable=10
StartTrappers=50
StartPingers=10
StartDiscoverers=5
StartSNMPTrapper=1
CacheSize=80M
StartDBSyncers=40
HistoryCacheSize=400M
TrendCacheSize=200M
HistoryTextCacheSize=800M
Timeout=15
＃デフォルト値より変更しているもので、
＃かつ、本件に関係がありそうな項目を抜粋
・my.cnfより抜粋
innodb_buffer_pool_size=40G
innodb_log_file_size=512M
innodb_log_files_in_group=2
max_connections=1024
thread_cache_size=1024
expire_logs_days=20
log-error=/var/log/mysqld.log
＃デフォルト値より変更しているもので、
＃かつ、本件に関係がありそうな項目を抜粋
・zabbix_server.logに出ていた主なエラーログ
5105:20190616:000943.132 [Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction [update ids set nextid=nextid+2 where nodeid=0 and table_name='events' and field_name='eventid']
zabbix_server [5105]: ERROR [file:db.c,line:1269] Something impossible has just happened.
このエラーが少ないときだと1時間単位で出ないこともありますが、平均的に200回/1時間ほど、多い時で1000回/1時間ほど出ています。1日で6000回ほど記録されています。
・これまで対処した設定変更と結果
StartDBSyncersの変更
導入当初から今年の4月までの約7年間はStartDBSyncers=50で運用していましたが、4月に40にしたところ、上記Lock wait timeout exceededのログが
1日平均2000回ほど発生していたものが1000回程度になり、キューが貯まる頻度も下がりました。
6月10日に40を35に変更したところ、設定変更後1日は落ち着いていたのですが、
6月12日未明からキューが貯まりやすくなり、かつ上記Lock wait timeout exceededのログが1日平均6000回～7000回ほど記録されるようになりました。
16日に35から40に設定を戻しましたが、現在もこの状況が続いております。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
fripper - 投稿数: 495
設定されている監視対象の規模がかなりのものとなる様子ですので
どの部分がボトルネックになっているか、の特定と解消が最重要・必要かと思います
2.0系ですと、Serverのみでサポートされている zabbix【xxxxx】 のアイテムを利用して
サーバモジュール側の負荷・各プロセスの稼働状況を採られてみるのが良いかと思います
ひょっとすると、HouseKeeper による削除処理が走ることで、ディスクI/O が消費され
監視値の格納や、設定の select 等に必要な I/O 側に影響が出ていて
キューが貯まる形で可視化されてしまっているのではないでしょうか？
■Serverの設定値：StartTrappers
・利用されているProxyの数(480)
・アイテム数 (61972)
・NVPS (228.12)
から
・Proxy側は標準的なActive Proxy として構成されている
・ログ等のバーストのような爆発的受信は恒常的に発生しない
・Proxyからの送信インターバル(DataSenderFrequency)は標準もしくはそれに近い値 (60sec)
と考えると、StartTrappers=50の設定値は十分かと思います
■Serverの設定値：StartPollers：50
Zabbixサーバから直接（Proxyを介さず）監視する項目が少ないのであれば
この値はもう少し少なくできるかと思います
zabbix【xxx】項目から確認して、稼働率が低いようであればプロセス数の削減を検討しても良いと思います
■DB周り
I/O wait の発生状況や、Slow-query の発生状況はいかがでしょうか？
MySQL 5.0.x 系ですと、かなりの I/O 速度が出るストレージを利用するか
相応のチューニングを施さないと、この規模のNVPS による Insert 発生に
耐えられないかと思います
ほぼ同規模のサーバを構築・運用した経験がありますが
MySQL 5.5系以降を利用し、History等テーブルのパーティショニングや
HouseKeeper の無効化、InnoDB テーブルの圧縮など
特に DB 周り・ストレージ I/O 周りの影響を重点的に対処したうえで
StartDBSyncers=8
として、キューの滞留なく稼働できております
CPUコア数を超えるようなプロセス数でディスクIOが発生するような状況にすると
I/O Wait が上がりやすくなってしまうため、無駄なキューが発生しやすくなっているの
かもしれません
Poller/Trapper 等、データの入り口となる部分のプロセス数は、監視対象・項目の数に応じて
ある程度減らせない等はあるかと思いますが、zabbix【xxx】のアイテム値から
最適値を探ることは可能です
DBMS 側 (MySQL) のバッファを大きく採って、実ディスクI/O をできる限り大きな単位で行わせるようにして
＃もちろん、不意の電源断などでデータ喪失・ディスク破損等のリスクは大きくなりますが
Zabbixサーバ側のHistoryCacheSize・HistoryTextCacheSize・TrendCacheSizeを、トリガー設定で
必要とされるに十分なだけ割り当てて
＃障害の判定時に、いちいち select せずに済むように （不要なディスクI/O の排除）
ZabbixサーバからのDB書込も、ハードウェア側のCPU・ディスク I/O での
「同時に処理できる最大並列数」を鑑みたような値にしておくのが良いかと思います
同じテーブルへの複数同時要求は、DBMS 側でのロック処理等で、更に余計に
待たされる等の事象の原因にもなりますし‥
大沢 - 投稿数: 6
お忙しい中、早速ご回答いただきありがとうございます。
内容確認させていただきます。
取り急ぎ現時点で調べられている部分だけお話しますと
＞ひょっとすると、HouseKeeper による削除処理が走ることで
そのとおりでございます。なるべく止めたくはないとは考えてますが
キュー遅延と比較すると関連性は高いです。
＞StartPollers：50
仰るとおり、こちらの使用率はもう少し抑えられそうです。
Trappersプロセスがよく100%になっておりますので、こちらの値を上げることを検討します。
＞DB周り
やはりここの設定の調整が重要なんですね。
この点を重点的に考えます。仰るとおりslowqueryは確認しております・・・
よろしくお願いします。
Yasumi - 投稿数: 372
この規模になると、DB設定等で多少の改善はありますが、
監視台数が増えていくといずれは限界が見えてくると思います。
「1秒あたりの監視項目数(Zabbixサーバーの要求パフォーマンス)」も高いので
ここを抑えるために全体の監視間隔を広くするのもありかと思います。
ただ、OSもZabbixもDBもバージョンがかなり古いので、
やはり抜本的解決のためには最新OSとバージョンでの構築が必要だと思います。
kz999 - 投稿数: 24
回答じゃなくて感想ですみませんが、zabbixってこんなに監視つめるものなんですね。
自分もDBのクエリサイズとかある程度いじりましたけど、スキル的な自信もないので各種設定を攻めていくよりこの監視規模になる前にzabbixサーバ増やしちゃう方向にいくかなあ。。。
今回は目の前の遅延をどうにかしないといけないので、仕方ないとは思いますけど。
平常時にギリギリの状態って、何かあった時（特定NW帯落ちてアラート処理が大量に発生とか）に破綻する危険性を孕んでたりしますから、怖くないですか？
それとzabbixプロキシ480台とありますが、プロキシって皆さんそんなに気軽に使うものなんでしょうか？
古くても最新のzabbix-serverと通信できるagentと異なり、zabbixプロキシはserverとバージョンが一致している必要がありますから、zabbix-serverをバージョンアップしたくなった時に480台のプロキシも一斉に上げないといけなくなるわけで、その状況ってとてもしんどくないものでしょうか。
大沢 - 投稿数: 6
Yasumi様
アドバイスいただきましてありがとうございます。
監視間隔を広くする選択肢については思いつきませんでした。
抜本的解決も合わせて進めたいと思います。
kz999様
ご意見ありがとうございます。仰るとおりでございます。
今回を教訓に今後は早めにサーバを増やす方向で考えたいと思います。