高負荷Apacheサーバーのパフォーマンスチューニング

（私たちにとって）負荷の高いWebサーバーで見られるサーバーパフォーマンスの問題を理解したいと考えています。環境は次のとおりです。

• Debian Lenny（すべての安定パッケージ+セキュリティ更新プログラムにパッチ適用済み）
• Apache 2.2.9
• PHP 5.2.6
• Amazon EC2ラージインスタンス

私たちが見ている振る舞いは、通常、ウェブはレスポンシブに感じますが、リクエストの処理を開始するのにわずかな遅延があることです-時々、ほんの数秒、ピークの使用時間で2〜3秒です。サーバーの実際の負荷は非常に高いと報告されていtopます。多くの場合、10.xxまたは20.xxで報告されています。さらに、これらの時間（偶数vi）の間にサーバー上で他の処理を実行するのは非常に遅いため、負荷は確実に増加します。奇妙なことに、Apacheはその最初の遅延以外に非常に応答性が高いままです。

preforkを使用して、Apacheを次のように構成します。

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0

KeepAliveとして：

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

サーバーステータスページを見ると、このような高負荷の時間でも、クライアントの上限に達することはほとんどなく、通常80〜100のリクエストとキープアライブ状態のリクエストの多くを処理します。これは、最初の要求の遅さを「ハンドラーの待機」として除外するように指示しますが、間違っている可能性があります。

AmazonのCloudWatchモニタリングから、OSが15を超える負荷を報告している場合でも、インスタンスのCPU使用率は75〜80％であることがわかります。

からの出力例top：

top - 15:47:06 up 31 days,  1:38,  8 users,  load average: 11.46, 7.10, 6.56
Tasks: 221 total,  28 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.9%us, 22.1%sy,  0.0%ni,  2.6%id,  3.1%wa,  0.0%hi,  0.7%si,  4.5%st
Mem:   7871900k total,  7850624k used,    21276k free,    68728k buffers
Swap:        0k total,        0k used,        0k free,  3750664k cached

大部分のプロセスは次のようになります。

24720 www-data  15   0  202m  26m 4412 S    9  0.3   0:02.97 apache2                                                                       
24530 www-data  15   0  212m  35m 4544 S    7  0.5   0:03.05 apache2                                                                       
24846 www-data  15   0  209m  33m 4420 S    7  0.4   0:01.03 apache2                                                                       
24083 www-data  15   0  211m  35m 4484 S    7  0.5   0:07.14 apache2                                                                       
24615 www-data  15   0  212m  35m 4404 S    7  0.5   0:02.89 apache2            

vmstat上記と同時の出力例：

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  0      0 215084  68908 3774864    0    0   154   228    5    7 32 12 42  9
 6 21      0 198948  68936 3775740    0    0   676  2363 4022 1047 56 16  9 15
23  0      0 169460  68936 3776356    0    0   432  1372 3762  835 76 21  0  0
23  1      0 140412  68936 3776648    0    0   280     0 3157  827 70 25  0  0
20  1      0 115892  68936 3776792    0    0   188     8 2802  532 68 24  0  0
 6  1      0 133368  68936 3777780    0    0   752    71 3501  878 67 29  0  1
 0  1      0 146656  68944 3778064    0    0   308  2052 3312  850 38 17 19 24
 2  0      0 202104  68952 3778140    0    0    28    90 2617  700 44 13 33  5
 9  0      0 188960  68956 3778200    0    0     8     0 2226  475 59 17  6  2
 3  0      0 166364  68956 3778252    0    0     0    21 2288  386 65 19  1  0

最後に、Apacheからの出力server-status：

Server uptime: 31 days 2 hours 18 minutes 31 seconds
Total accesses: 60102946 - Total Traffic: 974.5 GB
CPU Usage: u209.62 s75.19 cu0 cs0 - .0106% CPU load
22.4 requests/sec - 380.3 kB/second - 17.0 kB/request
107 requests currently being processed, 6 idle workers

C.KKKW..KWWKKWKW.KKKCKK..KKK.KKKK.KK._WK.K.K.KKKKK.K.R.KK..C.C.K
K.C.K..WK_K..KKW_CK.WK..W.KKKWKCKCKW.W_KKKKK.KKWKKKW._KKK.CKK...
KK_KWKKKWKCKCWKK.KKKCK..........................................
................................................................

私の限られた経験から、次の結論/質問を導きます。

• KeepAliveリクエストが多すぎる可能性があります

• vmstatでIOを待機するのにある程度の時間を費やしていますが、それほど頻繁ではありません（どうでしょうか？）

• また、vmstatでは、いくつかの反復で、処理されるのを待っている多くのプロセスが表示されます。これは、Webサーバーでの初期ページ読み込み遅延を、おそらく誤って

• 静的コンテンツ（75％以上）とスクリプトコンテンツの混合を提供します。スクリプトコンテンツは多くの場合、かなりプロセッサを集中的に使用するため、2つのバランスをとることが重要です。長期的には、両方のサーバーを最適化するために静的データを別の場所に移動したいのですが、今日のソフトウェアはその準備ができていません

誰かがアイデアを持っている場合は追加情報を提供できてうれしいです。他の注意点は、これは高可用性プロダクションのインストールであるため、微調整後に微調整を行うことに警戒しており、私がKeepAlive値のようなもので遊んでいなかった理由ですまだ。

まず、クラウドでの処理についてあまり気にしないことを認めますが、他の場所での経験に基づいて、このWebサーバー構成はトラフィック量がかなり少ないことを反映していると思います。runqueueが非常に大きいことは、それを処理するのに十分なCPUがないことを示唆しています。ランキューには他に何がありますか？

キープアライブリクエストが多すぎる可能性があります

[いいえ] - 5秒間のタイムアウトがまだかなり高く、あなたが持っているものの、最近のブラウザは、パイプラインとする場合は、並列に要求を実行するに際に知っについて非常にスマートです、パフォーマンスが向上し、まだKEEPLIVE LOT「あなたがない限り-待っているサーバのをレイテンシーの問題が非常に大きいため、これを2〜3に減らすことをお勧めします。これにより、runqueueが少し短くなります。

Webサーバーにmod_deflateをまだインストールしていない場合は（そうすることをお勧めします）、ob_gzhandler（）をPHPスクリプトに追加します。自動追加としてこれを行うことができます：

if(!ob_start("ob_gzhandler")) ob_start();

（はい、圧縮はより多くのCPUを使用します-ただし、サーバーをより速く実行キューから取り出すことにより、全体のCPUを節約する必要があります/少ないTCPパケットを処理します-ボーナスとして、サイトも高速です）。

MaxRequestsPerChildに上限を設定することをお勧めします-500のように言います。これにより、どこかでメモリリークが発生した場合に備えて、プロセスのターンオーバーが可能になります。あなたのhttpdプロセスは巨大に見えます-必要のないApacheモジュールをすべて削除し、適切なキャッシュ情報を持つ静的コンテンツを提供していることを確認してください。

それでも問題が解決しない場合、問題はおそらくPHPコード内にあります（fastCGIを使用するように切り替えた場合、パフォーマンスが大幅に低下することはありません）。

更新

静的コンテンツがページ間でそれほど変わらない場合は、以下を試してみる価値もあります。

if (count($_COOKIE)) {
    header('Connection: close');
}

PHPスクリプトにも。

W状態のプロセスの数も非常に多いため、非同期リバースプロキシのインストールを検討する必要があります。あなたのApacheプロセスは、その上でブロックされているネットワーク上で遅いクライアントにコンテンツを送信するのに多くの時間を費やしているようです。ApacheサーバーのフロントエンドとしてNginxまたはlighttpdを使用すると、W状態のプロセスの数を大幅に減らすことができます。はい、キープアライブリクエストの数を制限する必要があります。おそらく、キープアライブをオフにしようとする価値があります。

ところで、107個のApacheプロセスは22 rpでは高すぎます。5個のApacheプロセスを使用して100〜120 rpを処理できました。おそらく、次のステップはアプリケーションのプロファイルを作成することです。

vmstatにはCPU待ち時間がかなり長いことを示す2つの行があり、その周りでかなりの数の書き込み（io-bo）とコンテキストの切り替えを行います。ブロックを書いているものと、その待ち時間をなくす方法を検討します。ディスクIOを改善することで最も改善が見られると思います。syslogを確認し、非同期を書き込むように設定します。コントローラーの書き込みキャッシュが機能していることを確認してください（チェックしてください-バッテリーが不良の可能性があります）。

キープアライブはパフォーマンスの問題の原因ではありません。キャッシュを前に実行していない場合、接続のセットアップにかかる時間を節約できます。MaxSpareServersを少しバンプすると、クランチではすべての分岐を待つことがなくなります。

最初の試みとしてキープアライブをオフにすることを検討する必要があります...

107個のリクエストが処理されたので、MaxSpareServersを設定した値よりも高くします...

静的コンテンツのリバースプロキシとしての長期nginxのIMHOを考慮する必要があります

最初の提案：キープアライブを無効にします。パフォーマンスが向上した特定の状況を特定できた場合にのみ必要でしたが、キープアライブを有効にすると一般的にリクエスト/秒が減少しました。

2番目の提案：MaxRequestsPerChildを設定します。ここでsymcbeanをエコーし​​ます。これは、メモリリークが発生した場合のプロセスロールオーバーに役立ちます。500は良い出発点です。

3番目の提案：MaxClientsを増やします。このための大まかな計算は、（物理メモリ-非httpdプロセスで使用されるメモリ）/各httpdプロセスのサイズです。httpdのコンパイル方法によって異なりますが、この数は最大255です。パブリックサーバーで250を使用して、システムをクロールするgoogle / yahoo / MSを処理します。

第4の提案：MaxSpareServersを増やす：4〜5倍のMinSpareServersのようなもの。

これらの提案が失敗した場合、リバースプロキシまたはmemcache for DBを使用した負荷分散を検討します。