web-dev-qa-db-ja.com

開いているポートが不足しているワニス、多くのSYN_SENT接続

最近、Varnish（3x）-> Apache（3x）のセットアップで問題が発生し、SYN_SENT接続が大幅に増加しました。

スパイク自体は、サイトに到達する新しいトラフィックの量（いかなる種類のDDOSでもない）によるものであり、Varnishマシンがバックエンドサーバーへのトラフィックの転送に問題があるようです（Apacheトラフィックの低下はワニスのスパイクと相関しています） ）、使用可能なポートプールをSYN_SENTで輻輳させます。

キープアライブはApache（15s）で有効になっています。

どちら側に障害がありますか？トラフィックの量は重要ですが、そのようなセットアップ（3x Varnishフロントエンドマシン、3xバックエンドApacheサーバー）が停止することはありません。

助けてください。

ファイアウォールを介した接続のMuninス​​クリーンショットは ここ です。

ワニス~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/ etc/sysctl.conf（ワニス）

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 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_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

Apachenetstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/ etc/sysctl.conf（Apache）

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30
apache-2.2networkingtcpvarnishnetwork-traffic
8
user150997

あなたの問題はおそらくApacheサーバー上のsysctlにあります。

いくつかの仮定：通常、Varnishは各接続の処理がWebサーバーよりもはるかに高速です（VarnishサーバーのCPUがはるかに少なく、Apacheサーバーがメモリにキャッシュされた静的ファイルのみを提供している場合を除きます）。 Apacheよりもワニスで。

したがって、Apacheサーバー上のリソースは十分である可能性がありますが、要求はごく短時間であっても、どこかにキューイングする必要があります。現在、それらは最終的に処理される健全な方法でキューに入れられていません。

リクエストがVarnishでスタックし、Apacheサーバーに届かないようです。

これにはいくつかの証拠があります：

Muninグラフで、SYN_SENTがバックアップされる前に、TIME_WAITのリクエストが増加し、ある時点以降、SYN_SENTSとして積み上げられることに注意してください。これは、リクエストへの応答が遅くなり始め、キューがバックアップされ、リクエストがまったく応答されないことを示しています。

これは、Apacheサーバーが十分な接続を受け入れていないことを示しています（Apacheが接続を処理するために、そこに座ってキューに入れることができます）。

設定ファイルにいくつかの制限があります。

スパイクがある場合、VarnishサーバーではSYN_SENT状態で約30000の接続があります。

ただし、Apacheサーバーでは、max_syn_backlogは16384のみです。somaxconnは2048のみです。

Apacheサーバーのネットワークメモリバッファのサイズが非常に小さいことにも注意してください。 Varnishサーバーでそれらを16MBに調整しました。ただし、Apacheサーバーでは、net.ipv4.tcp_rmemはnet.core.rmem_maxと一致するのにわずか524KBです。

Apacheサーバーでこれらすべてのパラメーターを上げることをお勧めします。

何が起こっているのかを正確に知るには、Apacheサーバーの診断にさらに焦点を当てる必要がありますが、これらの値を上げる場合は必要ない場合があります。

おそらくnet.ipv4.tcp_memを調整するべきではありません。このパラメーターの単位はバイトではなくページであるため、net.ipv4.tcp_rmemまたはnet.ipv4.tcp_wmem（両方ともバイト単位）から同じ値をコピーしても意味がないことに注意してください。それはあなたのメモリ量に基づいてLinuxによって自動調整されるので、調整が必要になることはめったにありません。実際、これは問題である可能性があり、接続キュー全体に使用できるメモリを任意に制限します。

参照： http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

また、「vm.swappiness = 0」が2回設定されていることにも注意してください。1回目は10に設定され、もう1回は有効値である0に設定されています。

3
Walker Traylor

Varnishサーバーで、次の2つのパラメーターを変更してみてください。

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuseを使用すると、TIME_WAITの接続を再利用できます。

tw_recycleは、ロードバランサーなどで問題を引き起こす可能性があります。

0
Florin Asăvoaie