かなりトラフィックの多いFreeBSDNginxサーバーがあり、多数のリッスンキューオーバーフローが発生し始めています。
[root@svr ~]# netstat -sp tcp | fgrep listen
80361931 listen queue overflows
[root@svr ~]# netstat -Lan | grep "*.80"
tcp4 192/0/128 *.80
[root@svr ~]# sysctl kern.ipc.somaxconn
kern.ipc.somaxconn: 12288
[root@svr ~]#
ただし、最大リッスンキューの長さを128を超えて増やすことはできないようです。kern.ipc.somaxconnを増やしましたが、最大値は変更されていません。私は何かが足りないのですか?
ありがとう!
Kern.ipc.somaxconnは、あなたが思っていることをしないかもしれません。これは、未処理のおよび未処理接続の制限です。 (たとえば、接続制限ではありませんが、保留中接続制限を処理します)。
コンピュータ以外の例えを使用するには:これは、呼び出し中の電話の最大数(ピックアップされて応答される前)であり、同時通話の最大数ではありません。
非常に大きなバックログがある場合は、アプリケーションが電話をより頻繁に取得できるようにする必要があります(たとえば、より多くのリソース、より多くのCPU、より優れたフレームワークなどを提供します)。
Http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html ">カーネル制限に関するFreeBSDハンドブックのセクションには次のように記載されていることに注意してください:(強調鉱山)。
Kern.ipc.somaxconn sysctl変数は、接続を受け入れるためのリッスンキューのサイズを制限しますnew TCP接続。デフォルト値の128は、通常、堅牢な処理には低すぎます。負荷の高いWebサーバー環境での新しい接続。このような環境では、この値を1024以上に増やすことをお勧めします。サービスデーモン自体がリッスンキューのサイズを制限する場合があります
Nginxの使用経験はありませんが、アプリケーション側から上記の制限について構成ファイルを確認します。
nginx config で128に制限されたリッスンキューである可能性があります
次のような設定については、nginxconfigを確認してください。
listen 80 backlog=128;
そして、バックログを削除するか(デフォルトは-1 =システム制限を使用)、より大きな値に変更します(ロードされたサーバーでも、8192で十分です)。リッスンキューを増やしても、リッスンキューのオーバーフローが表示される場合は、nginxが長時間ブロックされていることを示している可能性があります(HDDの速度が遅い/過負荷であるか、サードパーティモジュールの記述が不適切であるため)。