当社には専用サーバーが 3 台あり、1 台は Nginx を実行して Web サーバー (php) として機能し、もう 1 台は MySQL と Memcached を処理し、もう 1 台は静的ファイル (css、js、画像) を提供するために使用されます。
すべてのサーバーは New Relic 上で優れたパフォーマンスを発揮しますが、特に静的ファイル サーバーのパフォーマンスが優れています。
- CPU 使用率が継続的に 10% 未満
- ネットワーク IO 受信は非常に低く、送信は最高 10 Mb/s 程度ですが、MySQL サーバーは同じ仕様で、通常 20 mb/s でピークに達するため、これが問題であるとは考えられません。
- 負荷平均0.5未満
問題は、ピーク時には、一部のユーザーにとって、画像（サイズが 100kb - 200kb になることがあります）の読み込みに長い時間がかかることです（通常は数秒しかかからないのに、何秒も、最悪でも 1 分もかかることもあります）。
何ができると思いますか? 理想的には、CPU、RAM、帯域幅のいずれも制限に達していない場合、このようなことは発生しないはずです。
確認すべき (そしておそらく変更すべき) 重要な Nginx 構成パラメータはありますか?
答え1
考えられる可能性は2つあります。
- ディスクの I/O 上限に達しました。
- nginxの作業スレッドの制限に達しました。ワーカー_*コアモジュールからの設定パラメータとワーカー接続イベント モジュールから、これを増やす方法を見つけてください。デフォルトは単一のワーカー プロセスで、これは単一スレッドなので、マルチ CPU プラットフォームで実行している場合は、これを必ず増やす必要があります。単一 CPU ボックスを使用している場合でも、静的リソースを提供するマシンでこの数値を増やすと、他の何よりも先にディスク I/O が制限されるため、最初のスレッドがディスクからデータを供給されるのを待っている間に、他のスレッドがより多くの要求を受け取って処理できるため、メリットがあります。
答え2
ここで一日中座ってボトルネックがどこにあるかを推測することもできますが、より一般的なアドバイスがあれば、自分でボトルネックを見つけるのがずっと早くなります。
jeffatrackaid さんが書いた昨日のこの答えこれはより簡潔なバージョンであるかなり前に書いたものパフォーマンスのデバッグがどのように行われるかを理解するために、まずこれらを読むことをお勧めします。
あなたの場合、まず Firebug を使用して、ピーク時にリクエストのどの部分が遅くなっているかを判断します。帯域幅が真の問題でない場合は、帯域幅の問題は除外されます。Firebug の「ネット」セクションを見て、高速時と低速時の間でリクエストのどの部分が変化するかを確認します。
その後、これらの低速時に、nginx ワーカーの 1 つで-tとオプションの両方を使用して strace を実行します。 の出力を分析すると、nginx が遅くなっている場所が正確にわかるはずです。 strace 出力をファイルに書き込んでから、ファイルでまたは を使用して、時間のかかったシステム コールを特定すると便利です。-Tlessgrep
-cstrace のオプションが役に立つかもしれません。
遅いシステム コールを特定したら、どの nginx パラメータを変更する必要があるかを判断するのにまだ多少の作業が必要ですが、順調に進むはずです。その部分でサポートが必要な場合は、ぜひ戻ってきて、より具体的な質問をしてください。
ファイルベースのシステム コールであることが判明した場合は、待機していたファイルが見つかるまでトレースを遡って調べてください。それが大きなヒントになります。