2013.11.03

Apacheのチューニング(3)

前回の投稿ではApache自体は大変処理能力が高いサーバーソフトであることがわかりました。

 

では、スクリプトが実行される動的ページではどうなるか…ベンチマークをかけてみます。

 

まずは、/etc/init.d/httpd restart としてApache関連ソフトを一斉リスタートしてゾンビプロセスを開放します。

つぎに、このblogサイトがWordPressで動いていますので、このサイトトップに対してベンチマークをかけます。

まずは、静的ページと同じように、同時接続100から。

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

このコマンドを実行します。

 

…えーと… まったく応答が返ってこなくなります。

 

サーバーが完全に息切れ状態。

リソース状況を確認すると、CPUが100%に張り付き、メモリがオーバーフローしてSWAPもすべて消費されています。

20131016E

 

さらに1-2分様子を見ると、

20131016F

 

あまりにSWAPが激しすぎて、CPUリソースが下がり始めています。

 

これはページング処理の末期症状でもあり、SWAPのためにSWAP領域を確保するためDISK-I/Oに処理をとられすぎてなにも処理できていない状態となっています。この状態は言い換えると、端末100台から同時F5アタックを受けているのと同じ状態なので、このように事態にならないようにチューニングする必要があります。

 

では、どの程度まで同時接続を減らしていくとSWAP領域を極端に消費しなくなるかテストを繰り返します。

ここのサーバー構成・WordPressの動作状況では、同時接続15…

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

 

ここまで下げてやっと実用的なリソース状況まで下げることが出来ました。

20131016I

 

これでもCPUリソースが100%行ってしまっているので、ベンチマーク結果は10-15秒くらいかかって1ページを処理するためかなり遅いです。

それでもサーバーはダウンしていませんので、このあたりが同時接続の上限ということになります。

 

意外に処理できる接続数が少ないというのが正直なところ。

 

Apacheだけの処理であれば同時接続1000でも耐えそうですが、動的ページはサーバーにかなりの負担をかけるということなのでしょう。

 

この主な原因はphpスクリプトエンジンにあり、CentOS6.4にインストールされるphp5では、phpプロセスに割り振られるメモリ(ヒープメモリ)がデフォルトでは128MBとなっています。 常にすべてのヒープメモリを消費しているわけではないですが、同時接続が15程度で1GB割り振ったサーバーのメインメモリを枯渇させていますので、phpによるメモリ消費が半端ないことがわかります。

 

またCPU消費も一気に100%に駆け上がっていることから、phpはかなり重いプログラムであることがわかります。

 

考えてみればLAMPサーバーって変な取り合わせです。

LAMPサーバーのL=Linux / A=Apache / M=MySQL・・・これらサーバーはCPU消費やメモリ消費を極力少なくなるようカリカリチューニングされたサーバーで、安定度も定評があります。

でも最後のP=php がCPU喰いメモリ喰いな上にゾンビ化しやすく、安定度も低い…。

もともとphpはこういう用途で作られたのではないとはいえ、その他Ruby言語やPythonもかなり重い言語でもありますので、結局LAMPサーバーではPのスクリプトエンジンが総じてサーバーリソースを大喰らいしていると言っても過言ではありません。

 

そして、これら言語で作られた動的WEBサーバーが時代の先端というのもなんだか妙な感じです。

 

次回は、これらリソース大喰らいなスクリプトエンジンに振り回されないよう、サーバーが処理できるリソースに見合った設定ファイルに書き換えます。

(つづく)

 

 

おまけ / そのころ、親サーバーでは…

同時接続100の時のベンチマークではここのWEBサーバーはSWP処理のため応答不能状態に陥っていますが、VMwareが動作している親(物理)サーバーはどうかというと…下図の通り。

20131016J

CPUであるXeon E3-1265LV2の4コア8スレッドが枯渇しているわけではなく、あくまでひとつのスレッドが忙しい状態でしかありません。

CPUを満遍なく動作させるためにコアを入れ替わり動作させているところもリソースメーターからわかります。

 

親サーバーにはVMwareWorkStation9.0.2がインストールされており、配下にはこのWEBサーバー以外に、リバースプロキシ(CentOS6.4)・旧WEBサーバー(RedHat9)・Mailサーバー(WindowsXP)・Sambaサーバー(CentOS6.4)・UPS監視サーバー(RedHat9)、デスクトップ評価用WindowsXPが同時実行していますが、WEBサーバーが応答不能になっていたとしても他の仮想OSにはほとんど影響を与えていません。(メモリ消費は実際には8GB程度消費していますが、リソースメーターではなぜか正しく表示されないので、メモリ部分はここでは無視します)

 

このあたりがVMwareでサーバーを仮想化することもメリットでもあり、仮想空間に適切にリソースを割り振ればサーバーがダウンしたとしても物理サーバーは無事に動作させ続けることが出来ます。(イコール、傷害に対処することが容易になる)

 

 

2013.11.01

Apacheのmod_sslの問題はあっけなく解決

前回からのつづきです。

外出先からblog更新を実現するため、WordPressのログインや管理画面系をhttps接続しようとApache WEB Serverにmod_sslを組み込んで設定を行っていましたがうまくいきません。 WordPressが動作しているバックエンドサーバーはhttps接続が確認できたものの、フロントエンドサーバーのリバースプロキシがhttps接続を確立できていませんでした。

接続要求がlogに残らないので、LofLevel設定を”warn”から”debug”に切り替えて接続テストしても一向に接続要求が記録されません。

 

おかしいなぁおかしいなぁ…と思案していると、ふと思い出したことが…

接続のログが残らないということは接続自体認識していない? 誰かが接続を拒否している?

それってもしかして…ファイヤーウォール??

大ビンゴでした。

http接続は許可していましたが、httpsは閉じたまま…

20131031-FireWall

 

なんというか…自分でファイヤーウォールを設定しておきながら、そのことをすっかり忘れていました。 もう…アホとしか言えません。

ファイヤーウォールを設定すると、しっかりフロントエンドからバックエンドまでhttps接続が何事もなく貫通。 この数日の悶々とした日々はなんだったのか…orz

 

兎にも角にもオレオレ証明書ながらセキュア通信は確保できましたので、ここからWordPressの設定を行っていきます。

 

WordPressに「WordPress HTTPS」プラグイン導入

WordPress自体はhttp接続が基本です。

トップページからhttps://~として接続することも出来ますが、リンクからジャンプしたときにhttp://~に戻ってしまうことがあります。

ユーザーログイン画面や管理画面、特定の任意ページのみをhttps接続(強制的に)するためにはプラグインで対応します。

特定画面をhttps接続するためのプラグインは色々ありますが、今回は「WordPress HTTPS」をチョイス。

インストールはダッシュボードのプラグインメニューから新規追加を選び、「WordPress HTTPS」を検索してインストール & 有効化。有効化が完了すると、ダッシュボードのある左メニューにHTTPSというメニューが追加されています。

これをクリックするとプラグインの設定画面になります。

個別の固定ページをhttps接続できるようになっていたりとなかなか多機能なプラグインですが、まず行いたいのはログイン画面と管理ページのhttps接続。 この設定は「Force SSL Administration」フラグにチェックを入れて保存すれば自動的に今開いている管理ページからhttps接続に切り替わりります。

 

2013.10.28

ここ数日Apacheのmod_ssl関連で悩み中…

WordPressのカスタマイズはちょこちょこ進んでいます。(テーマレイアウトやプラグインが少しづつ変化していると思います)

ただし、今だ手をつけていないのが、外出先からのblog投稿するためのセッティング

WordPressのblog投稿は、WordPressログイン後、ホームURL以下のwp_adminディレクトリにあるWordPress管理プログラムにアクセスする事で可能になりますが、あまりに有名なディレクトリでもあるのでアタックを受けやすく過去には脆弱性を突いた大規模な被害が出ています。

よって、フロントエンドのリバースプロキシで、外からのアクセスではwp_adminディレクトリ以下はアクセス禁止にしています。

 

blog投稿するには自宅内の特定ルーティング経由することで可能としていますが…正直不便!!

しかし外で更新を許可するには、少なくともSSL通信(https://)でのアクセスは必須。

よって、現在https://~でのWordPressアクセスを可能とすべく奮闘中。

 

WordPressが走っているApache自体はSSL導入も完了してhttps://~アクセスも確認できていますが、リバースプロキシを通してだとなぜか接続できない。 VirtualHostの設定が良くないのか、access.logやssl_access.logに記録が残っていないので、接続要求がどこかに消えてなくなっている模様。

現在、どこで設定がつまずいているのか調査中…今のところまったくもって謎…

 

2013.10.17

Apacheのチューニング(2)

前回、webサーバー Apacheのパフォーマンス測定をApache標準のABコマンドを使用して実施したことを記載してから結構日がたってしまいました。

今日はそのつづきです。

Apacheのパフォーマンスを測定する場合、固定htmlで構成される静的ページと、WordPressのようなスクリプトでhtmlを出力する動的ページの双方からチェックをするのが好ましいとされています。

動的ページはphpなどのインタラプタが重いことはわかっているので、まずはもっとも負荷が軽い静的ページからApacheのパフォーマンスを測定します。

 

静的WEBページのパフォーマンスチェック

 

測定に使用したのがサイト工事中案内用のhtml

工事中ページ

htmlとしては非常に単純なもので、Apacheもほとんど負荷にならないものかと思います。
この状態で、abコマンドを使用し、同時接続100 / リトライ1000回を実行するため下記コマンドを入力します。

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

なお、ここで注意すべき点があり、URLを指定する場合、”/”で閉じたディレクトリ指定でコマンド発行が必要です。

“/”で閉じないディレクトリ名でURL指定しコマンド実行すると、Apacheからはリダイレクト処理ためのリターンコード301がベンチマーク対象になってしまい、あっという間に処理が完了してしまいます。

ベンチマーク実施前のシステムリソース状態はFig-1の通り

20131016AFig-1:ベンチマーク前システムリソース

待機状態にしてはメモリ消費が結構多い状態。

後述しますが、Apacheより起動されたプロセスがそのままゾンビプロセスとなって残っているのが原因かと思います。

これらゾンビプロセスについては、Apacheの設定ファイル httpd.conf を正しく設定することによりかなり解消します。

httpd.confを調整するにはまずこのシステムがどの程度チューニングするかを見極める必要があります。

まずは、suコマンドでrootに入り、/etc/init.d/httpd restart としてApache関連ソフトを一斉リスタートします。 これにより余分なApache関連のゾンビプロセスが削除されて、メモリ占有率は初期状態になります。

 

[root@webserver home_dir]# /etc/init.d/httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中:                                            [  OK  ]
[root@webserver home_dir]# exit
exit

 

20131016BFig-2:httpdをリスタート

 

この状態で、Apache標準のベンチマークソフトABを使用してパフォーマンスチェックします。

 

[sysuser@webserver ~]$ ab -c 10 -n 1000 www.wendy-net.jp/under_c/
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)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.15
Server Hostname:        www.wendy-net.jp
Server Port:            80

Document Path:          /under_c/
Document Length:        23341 bytes

Concurrency Level:      10
Time taken for tests:   272.397 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      23567000 bytes
HTML transferred:       23341000 bytes
Requests per second:    3.67 [#/sec] (mean)
Time per request:       2723.970 [ms] (mean)
Time per request:       272.397 [ms] (mean, across all concurrent requests)
Transfer rate:          84.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4  34.2      1    1000
Processing:  2108 2719 122.9   2704    3511
Waiting:     2091 2513 117.3   2497    3309
Total:       2110 2722 127.7   2706    3803

Percentage of the requests served within a certain time (ms)
  50%   2706
  66%   2739
  75%   2758
  80%   2773
  90%   2818
  95%   2897
  98%   3104
  99%   3439
 100%   3803 (longest request)
[sysuser@webserver ~]$

 

20131016CFig-3:ab -c 10 -n 1000 www.wendy-net.jp/under_c/ 実行後

 

数秒以内で終わるで、メモリリソースメーターにはほとんど痕跡が残っていないです。

CPUリソースメーターでは・・・すこし動いたか、という程度。

静的ページのベンチマークテストでは、同時接続が(-c オプション)100から500になっても、応答速度は多少影響を受けるものの、CPUリソースが数%、メモリリソースで20MB程度が変動するくらいです。

 

静的ページでのベンチマークはApacheの処理性能がそのまま反映されますので、この結果からはApacheというサーバー自体は非常に処理能力が高いことがわかります。

 

(つづく)

 

 

2013.09.28

Apacheのチューニング

普段我が家のサイトは海外からのスパムアタックを除けば、それほど沢山のお客さんが来るわけではないです。 しかし折角サイトを観ていただくのですから少しでも快適に・・・と思いWEBサーバーのパフォーマンスを測ってみました。

今回のサーバー更新では、旧サイトは出来る限り現状維持のため、古いサーバーに搭載していたのと同じApache1.3.42を採用、新サーバーはCentOS6.4標準のApache2.2を採用しています。

一つのドメインで2つのApacheを駆動するため、VMware上の仮想サーバーは

Apache

というフロントエンド & バックエンド サーバー構成で構築。

この構成でパフォーマンスはどんなもんだろう・・・と、Apache標準のABコマンドを使用してベンチマークを測ってみると、新サーバー・・・特にWordPressが妙に重い。 いや重いというレベルではなく、システムが固まるレベル。

これについては色々事例・文献を調べて試行錯誤し、一様の決着が付きましたが、なんというかやりきれない気持ち。

詳細についてはまた後日記載します。

 

2 / 212