web-dev-qa-db-ja.com

sysctl.confのnet.ipv4.tcp_max_syn_backlogの正しい値

sysctl.confを調整しています。

Linodeのウェブサイトの 最適化ガイド によると、以下はsysctl.confに設定する適切な値です：

net.ipv4.tcp_max_syn_backlog = 3240000

ただし、archlinux最適化ガイドの 同じ値 は次のとおりです。

net.ipv4.tcp_max_syn_backlog = 65536

最後に、別の 最適化ブログ （古くはありますが、GoogleでのSEOはかなり高い）で、値は次のように宣伝されています。

net.ipv4.tcp_max_syn_backlog = 4096

これらの球場はすべて大きく異なります。この値を高い数値（低い数値に対して）に設定する理由は何ですか？どちらが最初に実際の「正気」の値である必要がありますか？

linuxubuntusysctl
8
Hassan Baig

これは主に、サーバーを介して実行しているトラフィックの量に依存します。いくつかの重要な質問があります：

  • 処理する同時接続数はいくつですか？
  • 平均応答時間はどれくらいですか？ （応答の生成に、たとえば10〜50秒かかる場合、DDoS攻撃がなくてもリソースが簡単に不足する可能性があります）。
  • どのサーバーを使用していますか？ nginx、haproxy、varnish

監視する必要があります：

netstat -s | grep "SYNs to LISTEN"

これは、サーバーがパケットをドロップしていることを示す症状です（たとえば、バックログキューがいっぱいであるため）。

Netstat統計は/proc/net/netstatにエクスポートされます。ここで、統計はListenDropsと呼ばれます。スクリプトを使用して解析するか、次のようなものを使用する方が簡単かもしれません。

cat /proc/net/netstat | awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} \
    (f==1){ i=2; while ( i<=NF){ printf "%s = %d\n", n[i], $i; i++}; f=0}'

人間が読める統計名を取得します。このデータは、たとえば、 telegraf 、 collectd または prometheus 。

カーネルのチューニング

net.ipv4.tcp_max_syn_backlog-クライアントがまだACK応答を送信していないハーフオープン接続の数 （source） をキューに保持できます。

net.core.somaxconn受け入れのためにキューに入れることができる接続の最大数

net.core.netdev_max_backlogネットワークインターフェイスを通過し、カーネルによる処理を待機している、受信キュー内のパケットの最大数。

これらの設定は、開いているファイルの数と密接に関連しています（Linuxの場合と同様に、新しい接続ごとに2つのファイルハンドルが開きます）。以下を使用して制限を確認できます。

cat /proc/sys/fs/file-nr
8160    0       3270712

つまり、サーバーは8160のうち3270712個のファイルを開いています。

4
Tombart