1. ホーム
  2. 質問と答え
  3. TCP接続が最大65000〜

TCP接続が最大65000〜

2013-10-25 18 views
5

の場合、サーバーはRSTをクライアントに送信します。Java Nettyを使用する高負荷TCPアプリケーションで作業しています。TCP接続が最大65000〜

これはテストサーバー上で完璧に動作し、300k接続になりますが、プロダクションサーバーにデプロイすると65387の接続しかサポートできません。この番号に達した後、クライアントは "java.io.IOException： "例外。私は何度も何度も試してみると、毎回接続が65387になると、クライアントは接続を作成できません。

怒鳴るなどのネットワークキャプチャは、10.95.196.27がサーバである、10.95.196.29は、クライアントである：

16822 12:26:12.480238 10.95.196.29 10.95.196.27 TCP 74 can-ferret > http [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=872641174 TSecr=0 WS=128 
16823 12:26:12.480267 10.95.196.27 10.95.196.29 TCP 66 http > can-ferret [SYN, ACK] Seq=0 Ack=1 Win=2920 Len=0 MSS=1460 SACK_PERM=1 WS=1024 
16824 12:26:12.480414 10.95.196.29 10.95.196.27 TCP 60 can-ferret > http [ACK] Seq=1 Ack=1 Win=14720 Len=0 
16825 12:26:12.480612 10.95.196.27 10.95.196.29 TCP 54 http > can-ferret [FIN, ACK] Seq=1 Ack=1 Win=3072 Len=0 
16826 12:26:12.480675 10.95.196.29 10.95.196.27 HTTP 94 Continuation or non-HTTP traffic 
16827 12:26:12.480697 10.95.196.27 10.95.196.29 TCP 54 http > can-ferret [RST] Seq=1 Win=0 Len=0

サーバーへのクライアント3握手した後、サーバーがクライアントにRSTのパッケージを送信することにより例外要因、および新しい接続が壊れました。

クライアント側の例外は、のように怒鳴るスタック：

16:42:05.826 [nioEventLoopGroup-1-15] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the end of the pipeline. It usually means the last handler in the pipeline did not handle the exception. 
java.io.IOException: Connection reset by peer 
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_25] 
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[na:1.7.0_25] 
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225) ~[na:1.7.0_25] 
    at sun.nio.ch.IOUtil.read(IOUtil.java:193) ~[na:1.7.0_25] 
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375) ~[na:1.7.0_25] 
    at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:259) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:885) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:226) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:72) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:460) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:424) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:360) ~[netty-all-4.0.0.Beta3.jar:na] 
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:103) ~[netty-all-4.0.0.Beta3.jar:na] 
    at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]

Severの側は例外を持っていません。

私は巨大な接続をサポートするように怒鳴るいくつかのsysctlアイテムを回してみたが、その無用た

：すでにOSのリリースがSUSE Linuxのある999999

linux-152k:~ # ulimit -n 
999999

に

net.core.wmem_max = 33554432 
net.ipv4.tcp_rmem = 4096 4096 33554432 
net.ipv4.tcp_wmem = 4096 4096 33554432 
net.ipv4.tcp_mem = 786432 1048576 26777216 
net.ipv4.tcp_max_tw_buckets = 360000 
net.core.netdev_max_backlog = 4096 
vm.min_free_kbytes = 65536 
vm.swappiness = 0 
net.ipv4.ip_local_port_range = 1024 65535 
net.ipv4.tcp_max_syn_backlog = 4096 
net.netfilter.nf_conntrack_max = 3000000 
net.nf_conntrack_max = 3000000 
net.core.somaxconn = 327680

最大オープンを設定し、FD 3.0.13カーネルのEnterprise Server 11 SP2：

linux-152k:~ # cat /etc/SuSE-release 
SUSE Linux Enterprise Server 11 (x86_64) 
VERSION = 11 
PATCHLEVEL = 2 
linux-152k:~ # uname -a 
Linux linux-152k 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux.

dmesgには何もありませんCPUとメモリは低レベルに保たれ、すべてのことがうまくいくように見えます。クライアントからのサーバリセット接続だけです。

私たちは2.6.32カーネルのSUSE Linux Enterprise Server 11 SP1であり、うまく動作し、最大300kの接続をサポートできるテストサーバーを持っています。

カーネルやセキュリティの制限により、この問題が発生する可能性がありますが、RSTを送信する理由についてのデバッグ情報を得るための提案や方法はありません。ありがとう。

出典

2013-10-25 Santal Li

+0

これに関するアイデアはまだありません。ちょっと追加情報が見つかりました。別のテストサーバーでは、すべて正常に動作し、linux2.6カーネルである300000接続に到達します。おそらく別のカーネルバージョンによって引き起こされると思います。テストするサーバーを増やし、何かがあれば更新します。 –

+0

1台のクライアントマシンの1つのNICに64kを超える接続を作成しようとしていますか？もしそうなら、それは不可能です。複数のクライアントマシン（または複数のNIC）に接続を広げることができますか？接続を切断するのはクライアントマシンだけかもしれません。 – trustin

+0

5台のクライアントマシンがあり、それぞれが60000台のサーバーへの接続を作成します。私はそれがクライアント側のドロップ接続ではなかったと確信しています、とにかく感謝します。 –

答えて

関連する問題

 関連する問題