zabbixで6万itemに耐えれるようにパフォーマンスチューニングをしてみた
TL;DR
Mysqlが仮想メモリで動いていてI/O wait多発。
Mysqlのメモリチューニングしたら上手くいった。
背景
zabbixで使用するitemが増える(現在6万ぐらい)につれてwebインターフェースが繋がらなくなることが多発。
自動復旧用にitemを設定しているためitem自体を減らすことが難しく、zabbixサーバー自体のチューニングをすることにしました。
使用環境
- zabbix 3.4
- AWS上のubuntu端末で運用
- item 6万・ホスト数500程度
- t2.largeで運用
- zabbix proxyは使用せずzabbix serverのみの運用
- apache2/zabbix server/mysqlの構成
調査
zabbixの標準的なログとして
- apache2のログ
/var/log/apache2/access.log - zabbix serverのログ
/var/log/zabbix/zabbix_server.log - mysqlのログ
/var/log/mysql/mysql.log
今回は事の発端がweb インターフェースから繋がらない、が問題だったのでapache2のログから調査を始めました。
/var/log/apache2/error.logに以下のようなログが吐かれてました。
[mpm_prefork:error] [pid 22269] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
このエラーはapacheのMaxスレッド数を超えてアクセスが来た時に吐かれるエラーになります。
じゃあこの時間にめっちゃアクセスが来てるのを調べるべく、/var/log/apache2/access.logのアクセス数をshellで解析
LOG_FILE=$1
function print_apachelog () {
DATE=$1 #24/Oct/2018
for h in {0..23};
do
if [ ${h} -le 9 ]; then
h=0${h}
fi
for m in {0..59};
do
if [ ${m} -le 9 ]; then
m=0${m}
fi
DATETIME=`echo "${DATE}:${h}:${m}"`
COUNT=`cat ${LOG_FILE} | grep -c ${DATETIME}`
echo "${DATETIME} ${COUNT}"
done
done
}
print_apachelog 25/Oct/2018
print_apachelog 26/Oct/2018
上記みたいにざっくりとしたアクセス数を解析。
該当時間帯には100程度しかアクセス数が無い。。じゃあ次はzabbix serverとmysql。
zabbix serverのログには目立ったエラーログがない。。
なのでもっと多くの情報を得るべく、zabbixでzabbixのインフラ情報を得ることにしました。
zabbix server自体に
Template OS LinuxとTemplate App Zabbix Serverのtemplateを追加。
標準的なcpu/memoryの状況とzabbixの内部チェックができます。
latest dataかGraphから各メトリクスの状況を確認できます
内部チェックの詳しい仕様は以下で確認できます
https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/internal
該当時間帯に発生していたこととしては
- cpu load average が5に達している
- cpu I/O waitの値も高い(60 ~ 80%)
- zabbixのqueueがめちゃくちゃ溜まってる(多い時で4000!!)
- zabbix history write cacheの値が該当時間帯に0%になっている
- history syncer processesもbusyになっていた。
どうやら
- zabbixサーバー上のhistory syncer processesがI/O待ちで滞留
- httpコネクションも滞留する
- apacheのMaxリクエスト制限に引っかかりweb インターフェースが使えなくなる
という流れのようです。
ではhistory syncer processesはどのような役割をしているのか？
zabbix japanの社長によると
収集したデータをメモリキャッシュからDBに書き込むためのプロセス
とのこと。なるほど。ということは
- zabbix serverのprocessが仮想メモリ上で動いており、I/Oが waitが発生
- Mysqlが仮想メモリ上で動いており、I/Oが waitが発生
の二択に絞られそうです。なんとなくcpuを食っているのはMysqlが怪しい気がするので、Mysqlのcpu使用率を調べてみます
zabbixのitemに以下のようにitemを追加。
- zabbxi agent item
system.run[ps auwx | grep -v grep | grep mysql | awk '{print $3}']
結果としてMysqlがcpu食ってました。実memory自体は全然消費していなかったので、仮想メモリでsqlを実行しているので、I/Oが数値が跳ね上がったで間違いなさそうです。
結論
メモリの空きも結構あったので実際の変更点としては
innodb_buffer_pool_size 1024 -> 4096
に変更をしました。これだけ調査したのに、変更点これだけ。。
zabbixに繋がらなくなった時はまずはDB起因を疑ってもいいかもしれません。
実際のzabbix用のmysqlのチューニングは以下のサイトが参考になりそうです。
https://www.percona.com/blog/2014/11/14/optimizing-mysql-zabbix/