web-dev-qa-db-ja.com

奇妙な分位数に分類されるUbuntuHTTPレイテンシ

十分なRAM、帯域幅、CPUを備えたUbuntu10.10サーバーがあります。 Apacheとnginxの両方から静的ファイルを提供するときに、レイテンシーの分布に奇妙で繰り返し可能なパターンが見られます。この問題は両方のhttpサーバーに共通しているため、Ubuntuのネットワークまたはキャッシュパラメーターを誤って構成したか、適切に調整していないのではないかと思います。

ab -n 1000 -c 4 http://Apache-Host/static-file.jpg

Percentage of the requests served within a certain time (ms)
  50%      5
  66%   3007
  75%   3009
  80%   3011
  90%   9021
  95%   9032
  98%  21068
  99%  45105
 100%  45105 (longest request)

ab -n 1000 -c 4 http://nginx-Host/static-file.jpg

Percentage of the requests served within a certain time (ms)
  50%     19
  66%     19
  75%   3011
  80%   3017
  90%   9021
  95%  12026
  98%  12028
  99%  18063
 100%  18063 (longest request)

結果は一貫してこの種のパターンに従います。リクエストの50%以上が期待どおりに処理され、残りは個別のバンドに分類され、最も遅いものは数桁遅くなります。

Apacheは2.xであり、mod_phpがインストールされています。 nginxは1.0.xであり、Passengerがインストールされています(ただし、どちらのアプリサーバーも静的ファイルのクリティカルパスにあるべきではありません)。各テストの実行時の平均負荷は約1でした(サーバーには12個の物理コアがあります)。 5GBの空きRAM、7GBのキャッシュスワップ。テストはローカルホストから実行されました。

Ubuntuサーバー10.10のデフォルトから行った構成の変更は次のとおりです。

/etc/sysctl.conf:
    net.core.rmem_default = 65536
    net.core.wmem_default = 65536
    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096 65536 16777216
    net.ipv4.tcp_mem = 16777216 16777216 16777216
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.route.flush = 1
    net.ipv4.tcp_no_metrics_save = 1
    net.ipv4.tcp_moderate_rcvbuf = 1
    net.core.somaxconn = 8192 

/etc/security/limits.conf:
    * hard nofile 65535
    * soft nofile 65535
    root hard nofile 65535
    root soft nofile 65535

other config:
    ifconfig eth0 txqueuelen 1000

この種の問題がベルを鳴らすかどうか、または構成に関する詳細情報が役立つかどうかをお知らせください。御時間ありがとうございます。

更新:以下に示すようにnet.netfilter.nf_conntrack_maxを増やした後に表示されるものは次のとおりです。

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      3
  95%      3
  98%      3
  99%      3
 100%      5 (longest request)
4
slowernet

nf_conntrackの完全な問題であるというコメントを外して、conntrakテーブルを増やすことができます。

sysctl -w net.netfilter.nf_conntrack_max=131072

または、すでにファイアウォールの背後にいる場合は、HTTPトラフィックを接続追跡から除外できます。

# iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
NOTRACK    tcp  --  anywhere             anywhere            tcp spt:www 
NOTRACK    tcp  --  anywhere             anywhere            tcp dpt:www
6
Kyle Brandt