Zabbixは重い！というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。
Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。
海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していっています。(自分たちである程度修正できるだけの技術力は持ちながらも)そうやって自社での個別ソース修正などを避けることで不要な運用コストを削減しているようです。本社に行ってサポートの仕事をし始めたころ、海外のユーザーはOSSをよく理解し、サポートをうまく活用してるんだなぁと関心したものでした。(バグについても同様です)
そうやってマイナーバージョン、メジャーバージョンごとにパフォーマンスが改善されて今があります。実際にユーザーが大規模環境で使っている以上、パフォーマンスが悪いはずはないと思ってます。
ちなみに、海外のユーザーはZabbixサーバーを複数台に分けることはあまり好まないようです。そもそも複数台に分けると監視設定の管理などの運用コストが高くなるため、それを嫌っているのだろうと思っているのですが実際に聞いたことはないので真相は不明です。
ということで、Zabbixのパフォーマンスはそんなに悪くないよ！ということを自分でも確認するためにも、今回はそこそこのハードウェアで10,000台の監視ができるかどうか？というパフォーマンステストを行ってみました。
利用したサーバーのスペックはこちら。1Uタイプのサーバーを購入したことを想定して、それほど高価にならないスペックで構成してみました。
- CPU: Intel Xeon E3-1240 v2 (4C/8T 3.4GHz)
- メモリ: DDR3-1600 16GB
- RAIDカード: LSI MegaRAID SAS 8708EM2 (3GBps/BBWC付き 128MBキャッシュ)
- ディスク: Seagate 3.5inch SATA HDD 64Mキャッシュ x2 RAID 1構成
RAIDカードだけ古いのですが、手元に余っていたのがこれだけだったのでご勘弁を。SATAを利用しているのでそれほどパフォーマンスに影響はないかなと思っています。
パフォーマンスの測定方法
日本ではRHELやCentOSが使われることが多いと思うので、上記サーバーにCentOS 6.4 x86_64をインストルし、MySQL 5.1、Zabbix 2.0.9をインストールしてテストを行います。
さすがに監視対象を数千台も用意できないので、VMware上で3台ほどLinuxサーバーを起動してZabbixエージェントをインストール、Zabbixに同じIPで異なるホストを登録していきます。Zabbixのエージェントは動作が軽量なので、これでも十分耐えられます。
監視にはZabbix 2.0.9に標準で付属するTemplate OS Linuxを利用します。デフォルトでは監視間隔が短めなので、すべての監視項目を5分間隔の監視に変え、過去データの削除処理の負荷を見るためにヒストリの保存期間を7日に変更しています。ローレベルディスカバリも動作するとだいたい1ホストあたり45監視項目になります。
MySQLの初期設定
MySQLには以下の基本的な設定を入れてから起動してます。他にもパフォーマンス改善のためのチューニング設定はありますが、とりあえずはベーシックなチューニングを行っています。
innodb_file_per_table innodb_buffer_pool_size=12G innodb_log_file_size=256M innodb_log_files_in_group=2 innodb_flush_method=O_DIRECT
また、RHEL/CentOSに付属のMySQLはRHEL/CentOS 6.3以降でInnoDB Pluginが利用できるようになっています。InnoDB Pluginを利用することで、内部の書き込みスレッドを複数起動し書き込みパフォーマンスが向上します。
/etc/my.cnfに以下の行を追加するだけでInnoDB Pluginを有効にすることができるので、これを設定しない手はありません。今回は最初からInnoDB Pluginを有効にした状態でテストを行っています。
ignore-builtin-innodb plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so
RAIDカードの設定
ライトキャッシュの効果を見たかったので、最初はRAIDカードをWrite Throughモードで動かしています。負荷が高くなったときにライトキャッシュをONに設定してみます。
パフォーマンスの見方
パフォーマンステストはCPUロードアベレージ、CPU使用率、Zabbixのプロセスのビジー率、監視アイテムのキューを見ながら、
- CPUロードアベレージ、CPU使用率が高くなっていないか
- Zabbixプロセスのビジー率が高くなっていないか(70%以下が目安)
- アイテムのキューが溜まっていないか
という点を見ていきます。基本的にはアイテムのキューの数が増えなければ遅延なく監視できていると判断できます。
では、パフォーマンステストを行っていきます。
MySQL 5.1、5000監視対象
とりあえず5000ホストを登録。アイテム数が22万、720nvpsほどになってます。
このときのパフォーマンスグラフです。まだロードアベレージやCPU使用率は余裕があります(上の2つのグラフ)。キューも溜まっていません(右下のグラフの赤い線)が、housekeeperプロセスのビジー率が1時間に1回高くなっていることが分かります(右真ん中のグラフの黄色線)。
housekeeperというのは過去のデータを削除するためのプロセスなのですが、大規模になるとデータ数も多くなり、削除するデータを探す->削除するという処理に負荷がかかっていることが分かります。
housekeeperが重くなることは想定済みなので、あとでDBのパーティショニングを行いたいと思います。この時点では他の点ではほとんど負荷がない状況なので、とりあえずこのまま1万台までホストを追加してみます。
MySQL 5.1、10000監視対象
ホストを10000台まで追加してみました。アイテム数45万、1400nvpsほどになっています。
さすがにこのくらいになるとキューが溜まっていて、スムーズに処理ができないようになってきました。ただ、ロードアベレージとCPU使用率はそれほど高くないですが、history syncerのビジー率が100%になっている(右真ん中グラフの赤線)ことと、history write cacheの空き率(左下グラフの青線)がときどき0%になっています。
history syncerは収集したデータをメモリキャッシュからDBに書き込むためのプロセスで、DBへの書き込みがボトルネックになっていることが分かります。
実はこのあとhousekeeperを止めてDBのパーティショニングを行ったのですが、パフォーマンスの改善は見られませんでした。上記のグラフの通り、housekeeperプロセスが1時間に1回動いたとき、housekeeperのビジー率は高いものの、そのときにCPUやI/O負荷に与える影響はそれほど大きくなっていないため、止めてもそれほどシステムへの負荷は変わらなかったようです。(ちなみにこの時点でZabbixのDBはトータル100GBほどありました。)
MySQL 5.1、10000監視対象、ライトキャッシュ有効
ここでRAIDカードのライトキャッシュを有効にしてみたところ、負荷が大幅に下がりました。グラフ真ん中の少し途切れているところがライトキャッシュを有効にするためにサーバーを再起動したところです。
ライトキャッシュを有効にする前のCPUのI/O waitの値はそれほど高くないものの(およそ25%程度)、RAIDカードを搭載してライトキャッシュを有効にすることでパフォーマンスは大幅に改善されることが分かりました。
MySQL 5.1、10000監視対象、ライトキャッシュ有効、より細かなチューニング
上記でもかなりパフォーマンスは改善されたのですが、まだ1時間に1度history syncerのビジー率が高くなっていることが分かります。これはトレンド(グラフ用に収集データをサマリしたもの)の計算を行う処理が1時間に1度動作するためです。
デフォルトのTempate OS Linuxに含まれている監視設定には数値データのものが多いため、トレンドデータの計算にも負荷がかかりやすい状況になっているようです。
キューに溜まっているアイテムは0になっているため監視の処理自体はスムーズに行われているものの、このトレンド計算のための負荷が気になります。もうちょっと負荷を抑えられないかということでOS、MySQL含めいろいろとパラメータ調整を行ってみたところ、ある程度まで負荷を落ち着かせることができました。
ところどころキューが出ていますが(右下グラフの赤線)、多くても2個程度ですし、すぐに0に戻っているためあまり問題にはならなさそうです。
グラフの後ろの方でhistory syncerの負荷が上がっているタイミングがありますが、これは直前にWebインターフェースから長い期間のスクリーンを表示したことによる影響が出ているのだと思われます。I/O負荷などはまだ低いのでもっと監視対象を増やせそうな気もしますが、Webインターフェースからの負荷の影響があることを考えると、このくらいに止めておいた方が良さそうです。
MySQL 5.5、10000監視対象
さて、いろいろなところでMySQL 5.5のパフォーマンスが良いという情報がありますし、海外の大規模Zabbixユーザーの多くはMySQL 5.5(そろそろMySQL 5.6に移行中)です。MySQLを5.5にアップグレードするとパフォーマンスがより改善され、Webインターフェースからのアクセスがあっても安定するのでは、という期待をこめてテストをしてみました。MySQLの設定は上記と同条件で、InnoDB Pluginは5.5でデフォルトとして採用されたためパラメータをコメントアウトしています。
個人的にかなり期待してアップグレードしたのですが...。あまりパフォーマンスが改善された様子はなく、なんだか逆に少し悪くなっているような気もします。5.5で追加されたパラメータなども調整してみたのですがあまり変わらずでした。
history syncerが発行するクエリは単純なinsertですし、InnoDB PluginとMySQL 5.5ではZabbixサーバーが使う部分ではそれほど大きな違いはないのかもしれません。
結論
Zabbix 2.0.9とMySQL 5.1で10,000台、45万アイテム/5分間隔という規模でも監視できることを確認できました。正直、このハードウェアでこれだけ監視できれば十分なのではと思ってます。
また、今回テストした環境ではMySQL 5.1ユーザーは少なくともInnoDB Pluginを利用していれば十分パフォーマンスは得られそうです。苦労してMySQL 5.5にアップグレードしてもあまり効果はないかもしれません。それよりも、適切なハードウェアを選択し、適切なチューニング設定を行う方が大切に見えます。
今回のテストでは主に数値データを収集していますので、ログ、トラップデータ監視が大量にある場合はまた違った結果になるかもしれません。余力があれば、ログやトラップデータを中心に監視した場合のテストと、MySQL 5.6を利用したテストも行ってみたいと思います。
0 件のコメント:
コメントを投稿