s****l
发帖数: 600 | 1 有一个TCP server比较old school，收一个request，计算返回然后close tcp
connection。
现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
奇怪的是每次connect timeout客户端ssh竟然断掉了。
benchmark只是拿2个VM来做，所以实际上还有空间。
同样的实验，用udp可以完成。 |
w***g
发帖数: 5958 | 2 应该是file descriptor用完了。这个TIME_WAIT是一个经典问题，我经常碰到，
但是我也不知道正确的解决办法是什么，同问一下。
seastar+DPDK似乎没这个问题。1GB网卡背对背连能做到500K req/s。
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
n*****t
发帖数: 22014 | 3 http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux
参考一下。另外，谁先 close？
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
z**0
发帖数: 618 | 4 Linux不大清楚，记得Windows里面TCP连接关掉后系统不是马上回收，如果短时间内有
很多连接就不行了。可以用连接池吧？
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
a9
发帖数: 21638 | 5 问魏老师
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
w********m
发帖数: 1137 | 6 无解。
你这是DDoS。内存耗尽了。
解决了估计能得图灵奖。
据说windows server这种情况挺的更久一点。 |
s****l
发帖数: 600 | 7 请问为什么是内存耗尽了
【在 w********m 的大作中提到】
: 无解。
: 你这是DDoS。内存耗尽了。
: 解决了估计能得图灵奖。
: 据说windows server这种情况挺的更久一点。
|
p******o
发帖数: 25 | 8 我觉得你说的对。我ubuntu 默认的file descriptor 上限是 780013, 跟楼主说的70万
的时候timeout 很接近。cat /proc/sys/fs/file-max
"The operating system uses file descriptors to handle file-system files as
well as pseudo files, such as connections and listener sockets." oracle doc
里的。
【在 w***g 的大作中提到】
: 应该是file descriptor用完了。这个TIME_WAIT是一个经典问题，我经常碰到，
: 但是我也不知道正确的解决办法是什么，同问一下。
: seastar+DPDK似乎没这个问题。1GB网卡背对背连能做到500K req/s。
|
c*********e
发帖数: 16335 | 9 tcp server有很多种啊，multi process, multi-threading, async
你用的哪种？
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
H****S
发帖数: 1359 | 10 用tcp port multiplexer复用端口
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
s*****e
发帖数: 115 | 11 did you try 'persistent connection' ?
【在 s****l 的大作中提到】
: 有一个TCP server比较old school，收一个request，计算返回然后close tcp
: connection。
: 现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
: 大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
: 奇怪的是每次connect timeout客户端ssh竟然断掉了。
: benchmark只是拿2个VM来做，所以实际上还有空间。
: 同样的实验，用udp可以完成。
|
l***p
发帖数: 358 | 12 server, 否则不会pile up TIME_WAIT
TIME_WAIT is status of actively close end
【在 n*****t 的大作中提到】
: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux
: 参考一下。另外，谁先 close？
|
l***p
发帖数: 358 | 13 google SO_REUSEADDR option 允许进入time_WAIT端口重用
要么你直接更暴力一点， RST connection rather than decently close connection(
FIN): S_LINGER = 0
【在 w***g 的大作中提到】
: 应该是file descriptor用完了。这个TIME_WAIT是一个经典问题，我经常碰到，
: 但是我也不知道正确的解决办法是什么，同问一下。
: seastar+DPDK似乎没这个问题。1GB网卡背对背连能做到500K req/s。
|
