web-dev-qa-db-ja.com

Netstat -sは、「受信キューからプルーニングされたパケット」と「受信キューで折りたたまれたパケット」を表示（および拡大）します

次のようになります。

[root@primary data]# netstat -s | grep buffer ; sleep 10 ; netstat -s | grep buffer
    20560 packets pruned from receive queue because of socket buffer overrun
    997586 packets collapsed in receive queue due to low socket buffer
    20587 packets pruned from receive queue because of socket buffer overrun
    998646 packets collapsed in receive queue due to low socket buffer
[root@primary data]#

念頭に置いて、上記は再起動したばかりのボックスです...約1時間の稼働時間。私たちは最近2か月上回っていた箱を持っていました、そしてこれらの対抗者は何百万人（XXX百万）に向かいます。

さまざまなsysctl変数を変更してみました...

ここに私が関係していると私たちが信じているsysctl変数があります：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

ソケットバッファオーバーラン/パケットの折りたたみ（私はこれが剪定されたパケットほど悪いものではないと理解しています）が原因でこれらの剪定されたパケットを解決する方法を誰かが知っていますか？

ありがとう。

linuxnetworkingtcpsysctlbuffer
7
anonymous-one

あなたが提供した情報から判断して、そしてあなたはすでにバッファを増やしているように見えるので、問題はおそらくアプリケーションにあります。ここでの根本的な問題は、OSがネットワークパケットを受信して​​も、十分に高速に処理されないため、キューがいっぱいになることです。

これは必ずしもアプリケーション自体が遅すぎることを意味するのではなく、そのマシンで実行されている他のプロセスが多すぎるために十分なCPU時間を取得できない可能性もあります。

2
Roman

実際、必ずしもバッファを増やしているわけではありません。キューの最大可能サイズにすぎません。

ソケットを開くと、キューは次の値に設定されます。net.core.rmem_default= 212992 net.core.wmem_default = 212992

したがって、最大値を増やしても何も起こりませんnlessアプリケーションは、setsockopt（）を呼び出してキューサイズを増やします（最大値が割り当てようとしているサイズを下回っている場合は失敗します）。

上記の値を増やしてみてください。

2
Graham Nicholls