当社は、さまざまなテーマの多くの大規模なインターネットポータルを提供しています。 このようなプロジェクトの詳細は、視聴者の増加に伴うさまざまな困難の発生を意味し、したがってサーバーの負荷が増加します。 クライアントの1人がビデオポータルを積極的に宣伝しているため、必然的に負荷が急速に増加し始めました。 ある時点で、2台のサーバーを回避することはできなくなり、さらに2台を追加することが決定されました。 その後、さらに2つ...結果として、サーバーは12になりました。ただし、負荷は増大し続け、水平スケーリングは1つに制限できません。 さらなる最適化について考える時が来ました。
そのため、もちろん、誰もがnginxが静的を最適に処理することを知っています。 もちろん、適切な構成の最適化が必要です。 このプロジェクトも例外ではありません-Nginxはすべての静的データを配布します。 基本的に、これはグラフィックおよびオーディオ/ビデオコンテンツ、特にサイズが50 MBから2 GBのビデオファイルです。 Nginxはそのタスクに完全に対応しています。さらに、私たちのチームはすでに微調整で多くの経験を積んでいます。 しかし、何らかの方法で問題が常に発生し、それらの解決策が常に表面にあるとは限りません。 私たちの場合、ビデオコンテンツの「新鮮な部分」がポータルにアップロードされたときに、ピーク負荷で問題が発生し始めました。 簡単に言えば、システムはディスク上にありました。 以下のグラフに見られるように、ディスクサブシステムの100％の負荷は数時間連続して続く可能性があります。
その結果、コンテンツ配信の速度が非常に遅くなり、ユーザーに不満が生じます。
その時点での静的の配布を担当する構成ファイルの一部：
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ { aio on; directio 512; output_buffers 1 512k; root /srv/www/htdocs; }
そのような場合、どのように状況を改善できますか？ このテーマに関するHabréの記事はたくさんあります（そしてそれだけではありません）。それらへのコメントには多くの有用なヒントがあります。 スタティックを配布するには、高速SSDキャッシュが最適なソリューションであると考えられています。 VFSのキャッシュは、選択したセクションの境界に収まる一方で、多数の小さなファイルには適していると考える人がいます。 SSDオプションはおそらく良いですが、すべての人に適しているわけではありません。なぜなら、カップルは言うまでもなく、単に別のドライブを追加する物理的な能力がないからです。 RAMの一部をキャッシュパーティションに割り当てるのは良い解決策ではありません。Linuxカーネル（Linuxのみを使用）がキャッシュの良い仕事をし、空きRAMが常に十分であるとは限りません。
私たちのケースでは、多くの空きRAMがありました（各サーバーで16 GBの最大90％）。 しかし、どのように正しく使用できますか？ アップロードバッファを512 Kbから8 Mbに増やすことが決定されました。
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ { aio on; directio 512; output_buffers 1 8m; root /srv/www/htdocs; }
これにより、ディスクの負荷を平均で1.5倍から2倍に減らすことができました。 Webサーバーのメモリ消費量が大幅に増加しました（平均で、全体の70〜90％）。
以下のグラフは、最適化後にディスク負荷がどのように変化したかを示しています。
ネットワーク負荷グラフ。 発信トラフィックは、平均で1.5倍から2倍に増加しました。
最適化後のRAM消費の変化のグラフ：
バッファ設定を使用した実験の結果、負荷ピークへのコンテンツ配信の速度はユーザーあたり平均1 Mb / sであり、これは許容可能な結果です。 サービスは安定しており、クライアントもユーザーも満足しています。
有用な記事：
Nginx wiki
nginxのチューニング
5分でNginxをスピードアップ
Nginx Secure Web Server