OMP_NUM_THREADS を指定した場合の負荷について
「ImageMagick の OpenMP が有効だとサーバが高負荷になってしまう」問題を回避するために環境変数 OMP_NUM_THREADS に 1 を設定したものの、Nginx の場合、何故か /proc/$pid/environ に表示されませんでした。
これでは本当に環境変数が正しく設定できているのかどうか、いまいちわかりません。
というわけで、実際にこの設定が効いているのかどうかを調べるため、簡単ですが以下の方法でサーバの負荷を測定してみました。
検証環境は以下の通りです。
- Webサーバ
- 負荷生成用マシン
どちらも仮想機且つ同一ホストで試したので厳密なパフォーマンス測定としては微妙ですが、OMP_NUM_THREADS の指定による負荷の変動が確認できればいいので、この際良しとしました。
sysstat
まずはサーバ負荷を計測するため、sysstat をインストールします。
# yum install sysstat
これで sar コマンドが使えるようになります。
apachebench-for-multi-url
負荷生成用の仮想機には ApacheBench をインストールします。
ただし、一応複数 URL をリクエストしてみたかったので、標準の ab ではなく apachebench-for-multi-url の方を使用しました。
インストール方法はこの記事の通り。
ab に渡す URL リストとして、以下のように画像毎に二種類のサイズの URL を記述したファイルを用意しました。
- url.txt
http://dev01/resize/w/150/h/150/anmitsu.jpg http://dev01/resize/w/150/h/150/chimaki.jpg http://dev01/resize/w/150/h/150/kintsuba.jpg http://dev01/resize/w/150/h/150/oshiruko.jpg http://dev01/resize/w/150/h/150/shiratama.jpg http://dev01/resize/w/150/h/150/yokan.jpg http://dev01/resize/w/150/h/150/monaka.jpg http://dev01/resize/w/400/h/400/anmitsu.jpg http://dev01/resize/w/400/h/400/chimaki.jpg http://dev01/resize/w/400/h/400/kintsuba.jpg http://dev01/resize/w/400/h/400/oshiruko.jpg http://dev01/resize/w/400/h/400/shiratama.jpg http://dev01/resize/w/400/h/400/yokan.jpg http://dev01/resize/w/400/h/400/monaka.jpg
ちなみに、レスポンスのサイズが異なる場合に「Failed requests」の「Length」が増えてしまう問題については、apachebench-for-multi-url でも特に対処はされていないようです。
なので、実際にはエラーになっていなくてもかなり「Failed requests」が出ますが、「Length」であればあまり気にしなくて良いと思います。
参考:
IHS: ApacheBenchについて
http://webmemo.uzuralife.com/article/2768
benchmarking - Load Testing with AB ... fake failed requests (length) - Stack Overflow
http://stackoverflow.com/questions/579450/load-testing-with-ab-fake-failed-requests-length/579466#579466
ksar
ksar は sysstat のログからグラフを生成して可視化してくれるツールです。
Java 製の GUI ツールなので Windows でも動作し、操作も非常に簡単で使い易いのでオススメです。
以下からダウンロードして適当なディレクトリに展開しておけば OK。
ksar : a sar grapher
http://sourceforge.net/projects/ksar/
負荷の計測
この記事の通りに ngx_small_light をインストール、設定してあるものとします。
まず最初に OMP_NUM_THREADS を指定しない状態での負荷を測定したいので、既に /etc/sysconfig/nginx 内に「export OMP_NUM_THREADS=1」が書かれている場合は削除して、 nginx を再起動しておきます。
nginx を再起動したら、Webサーバ側で sar コマンドを実行しておきます。
取得間隔は 5 秒毎、回数は 1000 回にしました。
# sar -o sar.o 5 1000
Webサーバ側で sar コマンドを実行したら、負荷生成用マシン側で ab コマンドを実行します。
先ほど作成した url.txt を -L オプションに指定しました。
# ab -c 10 -n 1000 -L url.txt
同時接続数は 10、リクエスト回数を 1000 回にしています。
取得が完了したら ksar で読み込めるようにテキストファイルに変換します。
LANG=C sar -A -f sar.o > sar_imagemagick_openmp.txt
ksar を起動し、[Data] - [Load from text file...」から変換したテキストファイルを読み込みます。
CPU負荷と Load Avarage は以下のような感じになりました。
CPU 使用率が 80 % を超え、LoadAvarage もコア数近くまで上がってしまっているようです。
確かに処理の割に負荷は高め。
ab の「Requests per second」は 2.97 でした。
続いて OMP_NUM_THREADS に 1 を指定した場合の負荷を計測します。
/etc/sysconfig/nginx に「export OMP_NUM_THREADS=1」を記述し、 nginx を再起動しておきます。
最初に先ほど生成された sar.o を削除してから実行します。
# rm -f ./sar.o # sar -o sar.o 5 1000
完了したら先ほどと同じく ksar で読み込める形式に変換します。
LANG=C sar -A -f sar.o > sar_imagemagick_omp_num_threads_1.txt
ksar で読み込むと以下のようなグラフになりました。
こちらは CPU 使用率が 25 % 程度、LoadAvarage は 1 程度になりました。
約 1/4 になったのは、OpenMP がコアを一つしか使わなくなったからでしょうか?
ab の「Requests per second」は 1.27 でした。
まとめ
上記の通り、明確に値が変わったので、どうやら Nginx でも /etc/sysconfig/nginx ファイルに「export OMP_NUM_THREADS=1」を記述すれば効果はあるようでした。
ただ、負荷は下がったものの、パフォーマンスも半分程度に下がってしまいました。
こういうもんなのかなぁ?
厳密に測定したわけじゃないですが、それにしてもこれだけ違うとなんかやり方間違えてんじゃないかって不安になって来ますね・・・。
取りあえずまた何か分かったら書きたいと思います。
参考
Webサーバの場合に OpenMP を無効(または OMP_NUM_THREADS=1)にする事の意味については、以下の記事が非常にわかりやすくて勉強になりました。
OpenMPとウェブアプリケーションの組み合わせについて - デー
http://ultraist.hatenablog.com/entry/20111229/1325155636