zabbixのWEBコンソール画面の表示速度を改善したい
はじめまして。
業務用運用監視システムとしてzabbix4.0を導入しようとしております。
監視項目は全部でおよそ１７万アイテム（内有効が１３万ほど）あり、たとえばアイテム数が15,000ほどのホストでアプリケーションを指定せずに最新データを表示しようとすると、表示までに１分以上かかります。
chromeのデベロッパーツールで確認すると、TTFB値が50-55secとなっております。
DBサーバのslowqueryログを確認すると下記のようなSQLで0.07secほどかかっているのですが、これだけで表示までに１分もかかっているのか疑問に感じています。
SELECT t.itemappid,t.itemid,t.applicationid FROM items_applications t WHERE (t.itemid IN (73699,・・・
そこでまずはボトルネックを発見したく、サーバのスペックを変更する前にzabbix_server.conf等の設定を見直しております。
一般的にzabbixの表示速度を向上させるために確認すべき項目やプロセスはありますでしょうか？
TNK - 投稿数: 4671
まずは、以下の投稿に対する私の回答を見てください。
http://www.zabbix.jp/node/4800
一番のボトルネックになりやすいのは、データベースの性能です。
CPUのUtilizationやメモリの使用状況など、その表示が遅いという
サーバーでどのような処理での負荷が高くなっているのかをまずは
把握してみてください。
データベースのチューニングを行っていないのであれば、まずはそ
こからです。
Webインターフェースの処理だけが遅いのであれば、
zabbix_server.conf
の設定は関係ない場合がほとんどです。
あとは、使用するOSのディストリビューションやバージョン、使用
するミドルウェアの各バージョンと構成方法がわからなければ、具
体的なアドバイスはできません。
khiwa - 投稿数: 3
ご返信ありがとうございます。
構成としては下記となります。
ウェブサーバ：
スペック＝AWS EC2 t3.large
OS=Amazon Linux2
Apache/2.4.34
PHP 7.3.6(OPcache v7.3.6とapcuを導入しています。）
ＤＢ：
スペック＝AWS RDS db.r5.large（vCPU=2、RAM＝16Gib）
Aurora MySQL5.6.10a
DBのチューニングとしては、
・innodb_buffer_pool_size＝{DBInstanceClassMemory*3/4}（＝16*3/4で12Gib）が設定されています。
・innodb_file_per_tableはAWSのパラメータグループに項目が無いようで未設定です。
・innodb_file_formatはデフォルト＝Antelope（デフォルト）です。
CPUのメモリ使用率はCPUのI/O待ちが最大3%ほどで、[CPUがアイドル状態で消費された時間]平均が83%で
これといった特徴が発生していないようです。
また、zabbix_server_processのメモリ使用は
zabbix process memory usage -system＝全体平均が23GBで内zabbix_serverが平均22.74GBで推移
zabbix process memory usage -internal processは全体が10GB程度で内history syncerが9GBを占めています。
たとえばslowqueryで検知されたSQLをDBに対して直接発行した場合、0.0449 secで取得できます。
このことから、DBのチューニングというよりはウェブサーバ側で頭打ちとなっているのでは？と考えたのですが、いかがでしょうか？
TNK - 投稿数: 4671
データベースのパフォーマンスに問題が無く、ブラウザ上で確認し
てWebサーバーにリクエストを投げてから最初のレスポンスが帰る
までが約1分かかっているということなのですね？
最新データの画面の場合、表示するアイテムのデータをまとめて受
信することになるので、その為に多数のSQL文の発行がされていま
す。
書かれていたSQL文だけではなく、アイテムの数が多ければ、その
数だけの最新値の取得も実行されるので、1つのクエリだけの時間
が短くてもアイテムが15000個あるなら最新値取得のSQL文が15000
回実行されるので、それで時間がかかっているのかもしれません。
例えば、最新データの取得1件につき、0.001秒かかったとして、
15000件なら15秒かかることが予想されます。
しかも、シーケンシャルに処理されるので、この時間を短縮させる
のは難しいでしょう。
OPcacheとAPCuを使用されているとのことですが、OPcacheはコード
をコンパイルしておくことでの高速化の効果はあるかもしれません。
しかし、上にも書きましたが複数のSQL文を実行して画面のHTMLを
生成しているので、表示するアイテム数が多ければ、PHPのロジッ
クの処理よりもSQL文の処理の方が多くの時間を消費してしまうの
ではないでしょうか。
あと、APCuは、それに対応した関数をZabbixのPHP内では使用して
いないようですので、効果は期待できないと思います。
最新データの表示は、必ず何らかのフィルタリングを使用して運用
することをご検討ください。
最新データの画面ではなく、スクリーンやダッシュボードでの表示
速度改善のためであれば、Webサーバー側で改善する余地はあると
思います。
例えば、Apache HTTP Serverからnginxに切り替えるとか、PHP-FPM
を使用したり、HTTP/2を使用するようにすることで、ブラウザから
のリクエストの処理高速化とリクエストの並列度を高めることがで
きます。
結果として、スクリーンなどの複数の要素で構成される画面の画面
表示を高速化できます。
khiwa - 投稿数: 3
ご返信ありがとうございます。
下記認識違いをしておりました。確かに多数のSQLが発行されれば
結果として最初のレスポンスが遅くなるのは必然ですね
> 最新データの画面の場合、表示するアイテムのデータをまとめて受
> 信することになるので、その為に多数のSQL文の発行がされていま
> す。
> 例えば、最新データの取得1件につき、0.001秒かかったとして、
> 15000件なら15秒かかることが予想されます。
> しかも、シーケンシャルに処理されるので、この時間を短縮させる
> のは難しいでしょう。
できれば最新データも曖昧に検索してそこから徐々に絞り込んでいく、
というような使い方ができればと考えたのですが、ご忠告通り何らかのフィルタリングを
前提とした運用にするよう考えます。
ダッシュボードは遅いというほどではありませんが、nginxへの移行を検討してみようと思います。