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

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

スパイク自体は、サイトにヒットする新しいトラフィックの量が原因であり（どのような種類のDDOSでもありません）、ワニスマシンがバックエンドサーバーにトラフィックを転送するときに問題が発生しているようです（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

Apache netstat -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サーバーの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回で、最下部は0回に設定されています。これは有効な値です。

Varnishサーバーで、次の2つのパラメーターを変更してみます。

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

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

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