2015年2月26日木曜日

MySQL HandlerSocketを監視するNagiosプラグイン

Quinn Dombrowski Sci-fi https://www.flickr.com/photos/quinnanya/7496308140

https://github.com/takeshiyako2/check-mysql-all/blob/master/check_handlersocket
HandlerSocket Plugin for MySQLへの接続を監視するNagiosプラグインです。
HandlerSocketへの読み込みコネクションチェック、書き込みコネクションチェック、検索チェックをサポートしています。

作者は、PerconaのRyan Loweさんです。
Ryan Lowe, Author at MySQL Performance Blog http://www.percona.com/blog/author/ryanalowe/




以下、セットアップ方法です。
環境は、Amazon Linux AMI 2014.09.2 (HVM) - ami-18869819です。

Perlのperl-Net-HandlerSocketモジュールをセットアップ。
# yum -y install cmake libtool libtool-ltdl libtool-ltdl-devel libedit-devel perl perl-devel git gcc-c++ perl-Time-HiRes perl-Test-Simple nagios-plugins-all
# git clone git://github.com/DeNA/HandlerSocket-Plugin-for-MySQL.git
# cd HandlerSocket-Plugin-for-MySQL
# ./autogen.sh
# ./configure --disable-handlersocket-server
# make
# make install
# cd perl-Net-HandlerSocket
# perl Makefile.PL
# make & make test
# make install

check_handlersocketプラグインをダウンロード。
# curl -O  https://raw.githubusercontent.com/garrinmf/check-mysql-all/master/check_handlersocket
$ perl check_handlersocket -h

ヘルプを見ると、タイムアウトは ”デフォルトで10秒” と書いてありますが、これは間違いで0.01秒です。
コードを見ると ualarm($OPTIONS{'timeout'}); となっているので、タイムアウトのオプションには、マイクロ秒を指定してあげます。
つまり、1秒 = 1000000、10秒 = 10000000 です。

以下、プラグインの使い方です。

読み込みコネクションと書き込みコネクションをチェック。
$ perl check_handlersocket -K read_connect -H localhost --timeout=1000000
OK: HandlerSocket is accepting read connections 

$ perl check_handlersocket -K write_connect -H localhost --timeout=1000000
OK: HandlerSocket is accepting write connections 

検索チェック。
テスト用テーブルを作成。
$ mysql -u root
mysql> USE test;
mysql> CREATE TABLE sample (id INT PRIMARY KEY, val INT);
mysql> INSERT INTO sample (id, val) VALUES (10, 100);
mysql> SELECT * FROM sample;

sampleテーブルから id = 10 を検索。
$ perl check_handlersocket -K read_exec -H localhost --database=test --table=sample --index='PRIMARY' --columns=val --index-value=10 --timeout=1000000
OK: Read

あとは、プラグインをNagiosなどに組み込めばOKです。
Enjoy!

2015年2月24日火曜日

Amazon EC2 + EBSにおけるIOバリアの設定によるパフォーマンス差は?

eutrophication&hypoxia Great Barrier Reef, Australia https://www.flickr.com/photos/48722974@N07/5093723696/in/photolist-91shvW-5w9sqC-bUL52L-bARkuF-oZ4DjD-9PqSyd-oDCmjp-dxNCMf-7dRfHA-92ovCb-nhNGq1-9QZNLw-bnWmc9-98cxQE-37z2C2-8L7EAm-cQZbq5-7tFo5g-gqgAZj-6tBwB-9QZPXN-8ek6w6-ehRoem-bARbgp-bAR83k-oDBrdB-p7qfCy-9uh9sc-bARa1x-pNZtk1-fFgqFF-grTuPe-grTfJ3-hMNwxi-oW5FA7-6NwjG9-aMZYRe-oDCnZt-q2EBwq-7tFjm4-bARc6v-grTjbJ-zZvy1-zZvxY-6erQZF-zZsmF-bnWhuh-7tFnyH-gqqXvo-fU8Mbp
Amazon EC2 + EBS を使ったとき、I/Oバリアのオン・オフでパフォーマンスが変わるか測ってみました。
=> 結果、変わらないことがわかりました。
また、CentOSを使ったときは、カーネルのバージョンを最新にすることによってパフォーマンスが改善することがわかりました。

以下、スループットを測ったときのメモです。

インスタンスとスペック
CentOS 6 (x86_64) - with Updates HVM
Instance type: c4.2xlarge
Disc: 300GB Provisioned IOPS (SSD) 1000 IOPS

EC2のCentOS6 HVMでresize2fs "Nothing to do!"と言われたとき
http://takeshiyako.blogspot.jp/2014/12/ec2centos6-hvmresize2fs-nothing-to-do.html
こちら方法で、あらかじめ、ディスクスペースを増やしておきます。

yum updateもしておきます。
# yum -y update
# reboot

現在のマウントの状況を確認。
# grep barrier /proc/mounts
/dev/xvda1 / ext4 rw,relatime,barrier=1,data=ordered 0 0

fstabファイルを編集。barrier=0を付与します。
# emacs /etc/fstab

UUID=xxxxxxxxxxxxxxxxx /                       ext4    defaults        1 1
->
UUID=xxxxxxxxxxxxxxxxx /                       ext4    defaults,barrier=0        1 1

サーバをリブート
# reboot

マウントの状況を確認。barrier=0が付与されていることを確認。
# grep barrier /proc/mounts
/dev/xvda1 / ext4 rw,relatime,barrier=0,data=ordered 0 0

dbenchを使ってベンチマークをします。5回づつ施行します。
# yum --enablerepo=epel -y install dbench
# dbench 5 -D . > ./dbench.log

I/Oバリアあり
Throughput 198.832 MB/sec  5 clients  5 procs  max_latency=291.996 ms
Throughput 198.525 MB/sec  5 clients  5 procs  max_latency=231.604 ms
Throughput 197.24 MB/sec  5 clients  5 procs  max_latency=529.609 ms
Throughput 198.003 MB/sec  5 clients  5 procs  max_latency=537.408 ms
Throughput 193.24 MB/sec  5 clients  5 procs  max_latency=500.507 ms

I/Oバリア無し 
Throughput 195.168 MB/sec  5 clients  5 procs  max_latency=336.223 ms
Throughput 196.525 MB/sec  5 clients  5 procs  max_latency=341.762 ms
Throughput 196.241 MB/sec  5 clients  5 procs  max_latency=664.540 ms
Throughput 197.79 MB/sec  5 clients  5 procs  max_latency=814.218 ms
Throughput 195.378 MB/sec  5 clients  5 procs  max_latency=441.299 ms
I/Oバリアあり・なしで差がないことがわかります。

気になったので、カーネルによって差が出るか、測ってみました。
カーネル 2.6.32-431.29.2.el6.x86_64
Throughput 58.7519 MB/sec  5 clients  5 procs  max_latency=204.272 ms
Throughput 60.9603 MB/sec  5 clients  5 procs  max_latency=197.062 ms
Throughput 58.7519 MB/sec  5 clients  5 procs  max_latency=204.272 ms
Throughput 63.2337 MB/sec  5 clients  5 procs  max_latency=658.214 ms
Throughput 61.4362 MB/sec  5 clients  5 procs  max_latency=984.695 ms

yum -y updateでカーネルを最新にしました。
カーネル 2.6.32-504.8.1.el6.x86_64
Throughput 195.168 MB/sec  5 clients  5 procs  max_latency=336.223 ms
Throughput 196.525 MB/sec  5 clients  5 procs  max_latency=341.762 ms
Throughput 196.241 MB/sec  5 clients  5 procs  max_latency=664.540 ms
Throughput 197.79 MB/sec  5 clients  5 procs  max_latency=814.218 ms
Throughput 195.378 MB/sec  5 clients  5 procs  max_latency=441.299 ms
パフォーマンスが改善していることがわかります。

Amazon Linux AMI 2014.09.2 (HVM) - ami-18869819 では、もっとパフォーマンスが良かったです。
Throughput 330.06 MB/sec  5 clients  5 procs  max_latency=557.884 ms
Throughput 331.476 MB/sec  5 clients  5 procs  max_latency=326.321 ms
Throughput 329.715 MB/sec  5 clients  5 procs  max_latency=614.967 ms
Throughput 333.588 MB/sec  5 clients  5 procs  max_latency=302.362 ms
Throughput 332.771 MB/sec  5 clients  5 procs  max_latency=418.299 ms


Amazon Linux AMI と CentOS それぞれのカーネルを比較したグラフです。



まとめ。

ディスクアクセスの多いアプリケーションは、Amazon Linux AMI で EBS プロビジョンド IOPS(SSD)を選択するのが良い。
これは、おそらく、ほかのOSと比べてAWS環境に最適化が施されているためである、と予想。(SR-IOVの設定の違いかな?と考えましたが未検証です。詳しい方がいらっしゃったら教えていただけると有難いです。)
あえて、CentOSを使うならば、そのままではかなりスループットが悪い。カーネルのバージョンアップによって改善されるが Amazon Linux AMI のスループットの60%ほどにとどまる。
ほかのOSでも検証してみたいです。

2015年2月19日木曜日

MuninのMySQLプラグインで"Unknown section: INDIVIDUAL BUFFER POOL INFO"エラーが出たときの対処法


https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/mysql_.in

最新のMySQL5.6で、MuninのMySQLプラグインでを利用しようとすると下記のようなエラーが出ます。
# cd /etc/munin/plugins
# munin-run mysql_innodb_rows
Unknown section: INDIVIDUAL BUFFER POOL INFO at /etc/munin/plugins/mysql_innodb_rows line 1098.

原因は、プラグインが INDIVIDUAL BUFFER POOL INFOの情報を解析せず、エラー処理がうまくいっていないためです。
これを解決するために、該当の情報をスキップするようにPerlのコードを編集します。
具体的には以下のようになります。

%section_mapハッシュの最後に、'INDIVIDUAL BUFFER POOL INFO' => \&skip, を追記します。
# emacs /usr/share/munin/plugins/mysql_
修正前。
    my %section_map = (
~~~~
        'BACKGROUND THREAD'        => \&skip,
    );
修正後。
    my %section_map = (
~~~~
        'BACKGROUND THREAD'        => \&skip,
        'INDIVIDUAL BUFFER POOL INFO'   => \&skip, 
    );

動作チェック。
# munin-run mysql_innodb_rows
Innodb_rows_deleted.value 215
Innodb_rows_inserted.value 13082874
Innodb_rows_read.value 14092838
Innodb_rows_updated.value 14092617

エラーを吐かずに動作するようになりました。