« | »

2013.11.15

Apacheのチューニング(4)

本稿「Apacheのチューニング」・・・ベンチマークとメモリ設定については今回が最終回になります。

前回では動的コンテンツを表示する場合にメモリを以上に消費していることがわかりました。

原因はphpが非常にCPUとメモリを消費していることです。

 

また、Apache自身、自身の動作が軽量であるがためにプロセスの同時実行制限がかなり緩めになっています。

これら設定がインストールされた状態のままで運用すると、同時アクセスが重なった場合やいわゆるF5アタックといったdds攻撃でサーバーが実質停止してしまう事態になります。

少なくともサーバーがページングのために処理が取られてしまって動作停止状態になるのは避けねばなりません。

 

Apache と phpのメモリ設定(default)

CentOSの場合、Apacheの設定ファイルは /etc/httpd/conf/httpd.conf、phpの設定は /etc/php.ini に格納されています。

それぞれメモリ設定関連の初期値を見てみます。

Apache(httpd.conf)

#### Server-Pool Size Regulation (MPM specific)
## <IfModule prefork.c>
StartServers 8     ←起動時の子プロセス起動数
MinSpareServers 5     ←アイドル状態の子プロセス最小数
MaxSpareServers 20    ←アイドル状態の子プロセス最大数
ServerLimit 256        ←サーバーが処理できる子プロセス最大数
MaxClients 256         ←同時接続クライアント数
MaxRequestsPerChild 4000 ←子プロセスの起動数限界(これを超えると順次KILLされる)
</IfModule>

 

php(php.ini)

455行目あたり
; Maximum amount of memory a script may consume (128MB)
; http://www.php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 128M

 

Apacheは同時接続と子プロセス数がかなり大きく、phpのメモリリミットがかなり大きな数値です。

phpプロセスあたり128MBまで取得可能となっているのですら、同時接続されるとそれだけメモリを広げようとします。

この仮想サーバーに割り振った1GBのメモリでは足りなくなるのも当然です。

 

ただ「じゃあ一気に10MBくらいにしちゃえ・・・」と強引に設定したとしても、今度はWordPressが動作しなくなります。

私の環境では、プラグインが入っていない素のWordPressでは32MB設定で動作しましたが、現在のこのサイトはギャラリープラグイン等色々拡張していると32MB設定ではWEBが表示されなくなりました。

今のサイト構成では64MB程度の設定は必要なようです。

よってphp.iniでのメモリ取得の上限は128MBから64MBに変更します。
php(php.ini)の修正

455行目あたり
; Maximum amount of memory a script may consume (128MB)
; http://www.php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 64M

2013.11.20訂正、WordPressのプラグイン、NextGEN Galleryにおいてサムネイルの更新を実行すると64Mのメモリではサーバーエラーを発生するようになりました。(1152×768の画像から200×200のサムネイル作成) 調整した結果、+16Mの80M設定で今のところ順調に動くようになりました。

 

次にApacheの設定を行います。

Apacheはデーモン起動時、クライアントからリクエストが来た時のレスポンス向上のためダミーで子プロセスを起動して待機しています。

この設定が、

StartServers       8
MinSpareServers    5
MaxSpareServers   20

となるわけですが、我が家のサーバーはそんなに立派な処理能力がありませんので、最大値20はちょっと持ちすぎです。

同時接続もそんなにないと仮定して、ここは

StartServers       5
MinSpareServers    5
MaxSpareServers   10  ←Minに対して2倍のマージンに抑えた。

という設定にします。

同様に、処理できるプロセス数、同時接続数が

ServerLimit      256
MaxClients       256

これが、かなり過多な設定となっています。

これら数値は、前回のベンチマークでは同時接続でのメモリ消費と鑑みて同時接続が15位が限界だったので、MxClientsは15とします。 ServerLimitは接続に対して4つのプロセスを同時実行できるものとして、15×4=60を設定します。

そしてMaxRequestsPerChildについては、ゾンビプロセス増殖を抑えるため、200とかなり絞って設定します。

なお、ServerLimit設定により60が同時実行限界なので、それ以上のプロセスは原則発生しないはずですが、プロセスKILLがそんなにリアルタイムで実行されるわけではないので多少余裕を見て200としています。(大雑把な数値)

 

ServerLimit      60
MaxClients       15
MaxRequestsPerChild  200

 

Apache(httpd.conf)修正内容

#### Server-Pool Size Regulation (MPM specific)
## <IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 60
MaxClients 15
MaxRequestsPerChild 200
</IfModule>

 

ベンチマーク実施

ここまで設定したならば、またしても前回と同様abコマンドでベンチマークを行ってみます。

前回は同時接続数100ではメモリオーバーフローしていましたが、今回はどうでしょう。(時間が掛かるのでトライ回数は1000から100に減らしています。)

$ ab -c 100 -n 100 http://www.wendy-net.jp/otoyo/

 

リソースの状況。

20131115A

MaxClients設定を15に設定しているので、前回の同時接続15の場合と同等のメモリ消費量です。

このくらいであればサーバのコントロールは問題なく出来ます。

また、ベンチマークの結果は下記の通り。

[root@web_server ~]# ab -c 100 -n 100 http://www.wendy-net.jp/otoyo/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.wendy-net.jp (be patient)…..done
Server Software:        Apache/2.2.15
Server Hostname:        www.wendy-net.jp
Server Port:            80
Document Path:          /otoyo/
Document Length:        69864 bytes
Concurrency Level:      100
Time taken for tests:   66.450 seconds
Complete requests:      100
Failed requests:        11
   (Connect: 0, Receive: 0, Length: 11, Exceptions: 0)
Write errors:           0
Non-2xx responses:      11
Total transferred:      6260171 bytes
HTML transferred:       6223099 bytes
Requests per second:    1.50 [#/sec] (mean)
Time per request:       66450.203 [ms] (mean)
Time per request:       664.502 [ms] (mean, across all concurrent requests)
Transfer rate:          92.00 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12   36  23.1     35      75
Processing:  9131 40217 19222.3  42583   66359
Waiting:     8531 39605 19410.3  42000   66359
Total:       9146 40253 19242.2  42619   66433
Percentage of the requests served within a certain time (ms)
  50%  42619
  66%  52882
  75%  62350
  80%  62391
  90%  66374
  95%  66375
  98%  66433
  99%  66433
 100%  66433 (longest request)
[root@web_server ~]#

なにやら、レスポンスデータが異様に遅いという数値になっています。42秒から66秒とか…

しかしこれは致し方ないことで、ベンチマークソフトでは100の同時接続が完了したレスポンスデータを返しているので、Apache側が同時接続の口が15しかなく、残りは一旦待ちの状態にされて順次実行されていますから致し方ないことです。

 

実際のレスポンスとしてはどうでしょう・・・同時接続をMaxClientと同じ15に設定して流してみます。

[root@web_server ~]# ab -c 15 -n 100 http://www.wendy-net.jp/otoyo/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.wendy-net.jp (be patient)…..done
Server Software:        Apache/2.2.15
Server Hostname:        www.wendy-net.jp
Server Port:            80
Document Path:          /otoyo/
Document Length:        69864 bytes
Concurrency Level:      15
Time taken for tests:   66.638 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      7026200 bytes
HTML transferred:       6986400 bytes
Requests per second:    1.50 [#/sec] (mean)
Time per request:       9995.637 [ms] (mean)
Time per request:       666.376 [ms] (mean, across all concurrent requests)
Transfer rate:          102.97 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   7.2      0      66
Processing:  4195 9690 1954.8   9814   14556
Waiting:     4062 9132 1830.3   9287   13779
Total:       4196 9692 1955.1   9814   14557
Percentage of the requests served within a certain time (ms)
  50%   9814
  66%  10085
  75%  10266
  80%  10386
  90%  11151
  95%  12678
  98%  14303
  99%  14557
 100%  14557 (longest request)
[root@web_server ~f]#

今度はかなり改善されました。 長くとも14.5秒という値です。

実際にこのベンチマークが走っている裏からWEBブラウザでアクセスしてみましたが、概ねこの時間くらいでレスポンスが帰ってきています。

 

最近スマホでの通信レスポンス関係の言葉で「パケ詰まり」という言葉があります。

通信(パケットの通り)が重く、WEBブラウザが固まって見えることから来ている言葉ですが、この「パケ詰まり」状態とは概ね、ページ表示のリクエストから15秒以上経過して反応がない場合はそのように呼ばれるそうなので、ちょうどこの同時接続15の制限はこの仮想サーバーに割り振ったCPUリソース/メモリリソースとしてはここら辺りが上限ということになります。

もし、15秒以上掛かっていたとしたら、MaxClientの値を減らして、その数値になるよう調整が必要になります。

 

まとめ

Apacheやphpについて、

ディストリビューションがデフォルトで設定しているメモリ領域や子プロセス関係の設定値はかなり贅沢なシステムリソースの上で実行されることを想定した数値であることがベンチマーク結果からわかりました。

それが安全方向に振られたものであれば良いですが、実際にはハングアップに近いところまで追い込まれる設定となっています。

今回の設定値はあくまで私が設定したサーバーの場合であって、1GBのメモリを搭載したサーバーすべてにいえることではありません。 今回の事例はいち参考事例として、自身の環境での最適化を検討する際の一助になればと思います。

Trackback URL

Comment & Trackback

No comments.

Comment feed

Comment





XHTML: You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">