2015.02.27

サーバー不幸の連鎖その3(歯切れの悪い完了)

WordPressのプラグインのお陰でMySQLのDBの修復も完了し、仮想サーバーやVMWare含めたシステム全体を再起動すると新たな問題が発生していました。

 

今度はこれまで無事に動いていたWEBサーバーも動作しなくなっています。

厳密には、旧サイトは普通に動いていますが、このblogを格納している新しいWEBサーバーがエラーを出しています。

何度かサーバーを再起動して傾向を探ろうとしますが、

 

Apacheから“503 Service Unavailable”エラーで落ちる場合と

WordPressから“データベース接続確立のエラー”のエラーで落ちる場合

 

この二種類あるようです。

どちらも起動したてのサーバーでは考えにくいエラーです。

特にApacheのエラーはサーバーリソースが枯渇した場合に出るエラーで、安定稼働していたApache設定ファイルには何も手を加えずシステム再起動して出るような類のものではありません。

旧サイトは正しくつながっているので、少なくともリバースプロキシのApacheは正しく動作しているようです。

 

そして起動時のログを追いかけながら、何度か再起動を繰り返しているとおかしな傾向が見えてきました。 サーバーの起動にかなり時間が掛かっているということに・・・

 

システム全体の再起動では、親サーバーが起動した後スクリプトでVMWareをバックグラウンドで起動し順次仮想サーバーを起動していきます。 同時実行するとサーバーの起動順序がバラバラになるので一つ一つの仮想サーバーの動作が確定してから次の起動に移ります。

よって複数のサーバーで起動の時間がかかっていると全体の起動完了が非常に時間が掛かることになります。

それぞれの起動を追いかけて行くと、途中で引っかかっているシーケンスを発見しました。

 

netfsサービス…NFSです。

 

本来ならばVMWare内の仮想ネットワークでのNFS接続なのでそんなに接続に時間がかかるとは思えません。

しかし、確実にNFSでつまづいているようです。

再起動してログイン画面が出、システムにログインし、dfコマンドでマウント状況を確認するとログインした段階ではまだNFSマウントされていません。

数分経過してからdfで確認するとNFSマウントされているので、どうやらバックグラウンドモードで再接続を試みているようです。

ただWEBサーバー / MySQLサーバー / sambaサーバーこれらはNFSマウントされた先のデータを利用していますので、こんなに遅くマウントされることは想定していません。 どうやらこれがエラーの諸悪の根源のようです。

 

対策としてはNFSクライアント設定でnfsvers等CentOS同士だから・・・と、デフォルト解釈で任せていた部分を明示的に設定。

出来ればサーバー起動前にNFSマウントを保証したいのでバックグラウンド接続はやめてフォアグラウンド接続の設定にしたかったのですが、それだと今回のような場合ハングアップ同様の状態となりかねず、もっと深刻な問題になりそうなので一旦見送り。 さらにsambaについてはsambaの設定(smb.conf)において接続先IPアドレスだけでなくネットワークインターフェース名(eth1等)を明示的に設定。

 

これら設定を行ってシステムを再起動…安定接続できるようになりました。

 

何れのサーバーもクライアントからの接続とNFS接続を分離し、仮想とはいえDUAL LAN構成としていたのでここに問題があったのかもしれません。

・・・ここで「かもしれません」と歯切れの悪い記載になっているのは、本当にそうなのか…と、設定を元に戻して再起動すると今度は何事もなかったように起動して来て不具合の再現性が無くなってしまったためで、本当にこの設定が決定打なのか…じつははっきりと言い切れないのです。

 

ただ接続設定が明示的ではなかったのは事実で、その設定自体がなにか悪影響するわけではないと思います。

なので今回はこの設定のまま運用を再開することにしたのですが、やはり内心は不安です。

 

暫く様子をみて、また何かあるようであれば追いかけてみたいと思います。(こういう体験はできれば勘弁願いたいですが…)

2015.02.25

サーバー不幸の連鎖その2

WEBサーバーが観れなくなっている原因を探ろうとノートパソコンを起動しようとしたら、まさかのsambaサーバーの同時不調。

危うく無実のノートパソコンがクラッシュしかけの状態まで行き、やっとの思いでサーバーのメンテナンスを開始。

 

まず行うのは、外部(WAN)側からの接続は駄目で、では内側(LAN)からのアクセスはどうか。

 

コチラは問題なし?…いやなんとなく重い…でも一応機能はしている。

 

特にWordPressにログインするとものすごく重い。

ここで疑ったのはeo光と接続しているアクセスルーター。

しかし、おとよが採用しているのはマイクロリサーチ社のSuperOPT100E

民生用ながら空気のような存在とまで言われる信頼性の塊。

先代のSuperOPT50も同様に信頼性の塊で10年以上使用していたものの、本体ではなく電源(ACアダプタ)が壊れたので買い換えしてまだ2年ほど。

そうそう考えられない事ながら念のため、普通にインターネットに接続。

 

コチラ問題なし。快調。

 

仮想マシンが不調なのか?? と、念のため別仮想マシンで動作しているメールサーバーを外部(WAN)/内側(LAN)からアクセスしてみる。

 

外部(WAN)NG / 内側(LAN)OK。

 

WEBサーバーとメールサーバーがまったく同じ挙動…ということは、仮想マシン個別の話ではなくて、

 

1.VMWare自体がおかしなことになっているのか

2.VMwareを動作している親サーバーがおかしなことになっているのか

3.インフラ(Internet)がおかしくなっているのか

 

この三つに想定要因が絞られる。

続いて確認したのが、アクセスルーター(SuperOPT100E)はLAN側に簡易DNS機能を有しているので、LAN側からのサーバーアクセスでは簡易DNS機能を使用していることから、外部のDNS…とくにこのwendy-net.jpがちゃんと外から見えているか。

これは我が家の固定IPで直接外部から接続してみるとわかる。

 

結果、IPアドレス直接アクセスではOK / ドメイン名アクセスではNG

 

どうやら原因は見えてきた、ドメインを管理しているdnsサーバーが怪しい。

 

そこでnslookupを使用して”wendy-net.jp”が登録されているns.mydomain.jpと比較用にgoogleのdnsにアクセスしてみる。

ビンゴです。 dnsサーバーが落ちています。

pingを打ってみると応答ありなので、センターが物理的に落ちているのではなくて、ホスティングサーバーが落ちているっぽい。

原因はわかったものの、私の手の及ぶところではないので、とりあえずドメイン管理会社にメールで連絡。

この時点で日曜日の夕方になっていたので、実際に対応いただけるのは早くて明日。 気長に待つしかないでしょう。(困るけど)

 

しかしそれでも、なぜWAN側からアクセスされることのないsambaや、WEBサーバーが極端に重くなっているのか…この問題が解決していません。

とくにsambaの不調は深刻で、お家のすべてのパソコンがログイン後デスクトップでブラックアウトしたままになります。

 

色々ググッてみるとsambaは更新により過去の設定ファイルが役に立たない場合があるという記述を発見。 このsambaを設定したのはCentOS6.4のとき。 今は更新により6.6となり、それからの自動更新が行われています。

ちょっと信じ難い部分もありますが、昨年末にアップデートし、安定稼動を見届けた状態のスナップショットもありますので問題の切り分けには丁度良かろうと…CentOS動作のサーバー(WEBサーバー / リバースプロキシ / MySQLサーバー / samba)を昨年末にロールバック。

 

今回一番うかつな作業でした。

 

MySQLのDBやWEB本体のディスクはすべてNFS経由で親サーバーのストレージにありますので、仮想サーバーには一切依存性のデータは残していないはずでした。

それは事実ですが、一点依存性のある重要なファクターを忘れていました。

 

時間です。

 

時間軸が昨年末に戻り各サーバーのntpd同期が完了しないうちにサービスを動作させたので、特にWordPressがMySQLにアクセスした際にパニックが発生。 インデックスデータの整合性が取れなくなるというトラブルに発展。

まさに泣きっ面に蜂です。

WordPressのDBまで飛ばして、この2ヶ月ほどのデータがDBアクセスできない状態とあっては再起不能になりそうです。

ただこちらの問題は幸いWordPressにインポートしていたデータベース管理用プラグイン“WP-DBManagerにリペア機能が搭載されていて、インデックスの不整合を何とか修復してくれました。こちらはかなり運が良かったです。(今回ノートパソコンでもロールバックして痛い目をみたので、今後ロールバックはよほどのことがない限りやらないと心に誓った)

 

しかし、まだsambaは不調のままです。 なんら不具合対策は前進していないです。

ここまでサーバーをあれこれ触っていたので、一度システム全体をリセットして仕切りなおし…と親サーバーを再起動すると、さらに別の問題が発生します。

 

つづく・・・

2015.02.24

サーバー不幸の連鎖

2月22日(日)よりサーバーが不調です(現在進行形)。

やっかいな状態なのと私がうかつな作業をしてしまった事でトラブルの連鎖という情けない状態になったので、備忘録もかねてblogに残します。

 

事の始まりはドメイン”wendy-net.jp”を登録しているマイドメイン社のDNSサーバー”ds.mydomain.jp”が22日お昼ごろからダウンしていたことに端を発します。

スマホ(docomo回線)から当サイトの動作をチェックしようとしてWEBが見えていないことに気がついて、原因を探ろうとノートパソコンを起動すると

 

ログイン後デスクトップ起動中に画面が真っ暗のままマウスカーソルが表示される

 

という状態に陥り起動がままならない状態となります。

 

「サーバーの様子がみたいのにその前にノートパソコンかよ・・・」と毒づきながらまずノートパソコンが起動できないの原因を探らねばなりません。

強制終了して再起動してもログインするとまったく駄目、復元ポイントを使用してロールバックしても駄目。

逆に復元ポイントに戻ったことによりアプリの整合性が取れなくなりアンインストールしたソフトが、「プログラムの機能」にエントリポイントだけ残して居座ってしまいアンインストールできなくなります。このためアプリによっては(例えばMicrochip社の開発ツール”MPLAB X”など)事前にアンインストールが前提のアップデートソフトがインストールできなくなるという余計なトラブルを抱えます。

こちらは“geek”というアンインストーラーの保存状態に関係なく問答無用にアンインストールするというアプリを使用することでノートパソコンの状態は一旦元に戻ります。

 

やっと、画面ブラックアウトの原因を探れると探っているあることに気がつきます。

「ネットワークが切断されているとデスクトップが起動する」ということに。

何度か再起動してもネットワークがOFFであれば、なにも問題なく起動します。

もしかしたら・・・とsambaに接続している共有ディスクにカーソルを触れて、クリックすると…反応が返ってきません。

どうやらサーバーのsambaが完全に停止ともいえない中途半端な動作をしているようです。

 

WEBサイトが動いていない原因(このときはまだ外部のDNSサーバーが原因とは気がついていない)を探ろうとしていたら、sambaも不調…

なにやらとても不幸な出来事が起こっている予感がします。

 

22日は日曜日。

我が家のサーバーは日曜日の朝5時にcronにより再起動するようになっています。

「再起動がトリガとなって一気に不具合が多発?」以前再起動によりRAIDディスクの不具合が勃発したこともありうネガティブな考えしか頭に浮かびません。

しかし、日曜朝の再起動でシステムからメールに自動送信してくるディスクの状態はなんら異常は示していません。

 

 

とりあえず共有ディスクの再起動時の接続を解除することでサーバー本体とノートパソコンが安定してつながる状態が確保できたので、まずは原因の究明から入ろうと作業開始。

でもそれは不幸の連鎖のまだ入り口でした… つづく・・・

 

本来は↓のネタを書きたかったのに・・・

2014.03.24

WEBサーバーの入れ替え完了

仮想環境の話ですが先日から時間を見つけて準備していた新しい仮想WEBサーバーがセットアップ完了したので先ほど入れ替えしました。

 

最初にセットアップしたWEBサーバーは、仮想環境に割り振ったリソースがCPUコア=1 / メモリ=1GBだったので、WordPressを動作させるにはちょっと重く、同時アクセスが20もくるとCPU=100% / メモリを使い切るという状態であったので、CPUコア=2 / メモリ=2GBに増やしマルチプロセス/スレッドが効率よく動作するようセットアップ。

ローカルネットワーク内で動作確認し特に問題なしであったため、外部からの接続フロントエンドであるリバースプロキシ設定を差し替えて、現在新しいほうのWEBサーバーで運用開始です。

 

リソースが増えたことでかなり処理能力が上がりました。

同時接続も3-4倍は処理できるようになったでしょうか?

詳細のベンチマーク・チューニングはこれからですが、まずは新しいサーバーで稼動実績を積んで行こうと思います。

インストール・セットアップ詳細についてはまた後日。

まずはサーバー入れ替え稼動の報告でした。

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のメモリを搭載したサーバーすべてにいえることではありません。 今回の事例はいち参考事例として、自身の環境での最適化を検討する際の一助になればと思います。

1 / 212