[求助]socket多对一connect连接请求被阻塞问题，怀疑和系统配置有关

tongban1981

    在做某功能实现时，会同时发起多个客户端向同一服务进行连接的操作，此时发现部分连接请求被阻塞了2.9秒左右。即客户端认为connect请求已经发出，但服务器端阻塞的poll没有收到，直到接近3秒钟后才收到。
    为了简化故障现场，进行了如下实验：

   1）测试环境： hp服务器，系统为redhat enterprise 5.1 x86_64
   2）服务器程序： 在某一端口阻塞式poll，发现有连接请求时就accept下来。
   3）客户端程序： 创建N个线程，这些线程同时向服务器程序发起connect连接。

   为了保证不是交换机因素，将客户端及服务器程序都放置于同一个系统上，连接地址使用127.0.0.1 （客户端、服务器不处于一服务器的实验现象类似）

   现象：

   并发连接数N在1-40之间时，总连接时间大概为0.000x秒
   并发连接数N在50-60之间时，N个连接请求中，慢的可能0.0x秒才能成功
   N=100，最慢的连接时间要0.1秒
   N=150，最慢的0.2
   N=200，最慢的0.3
   N=250，最慢的0.4
   N=300，最慢的几十个连接要3秒多，能看到中间不知道在哪里被阻塞了2.9秒左右，这2.9秒server程序没有收到任何连接请求。

   从以上现象看，怀疑是server程序所在的服务器阻塞了所有请求，导致server程序收不到请求。觉得有可能是服务器的系统安全设置问题，将同一时间的批量连接当做了syn攻击包。
   但系统防火墙是关闭的，ulimit，sysctl设置的打开文件数，backlog等设置也都是足够的。所以问题一直没有精确定位。

   各位TX有见到过类似现象的吗？觉得原因可能是什么？

giantchen

the first SYN TCP segment is lost, the default re-try interval is 3.0 seconds.

tongban1981

giantchen 发表于 2012-11-01 05:17
the first SYN TCP segment is lost, the default re-try interval is 3.0 seconds.

你是说三次握手中服务端返回的syn丢了还是客户端发送的丢了？ 服务端返回的倒没考虑到，只是想过会不会是客户端第一次握手时过去的数据包丢了，后来觉得不能是大家同时丢（每次都是阻塞一批），怀疑是server端的问题，这个方面就没有深分析。  retry如果是3秒就差不多对的上了，不过连接时间一般都是2.8-2.9秒，每次都差一点是三秒，如果确实是retry应该比三秒稍微多一点啊。另外，问题的根子还是不知道啊，就是为什么会批量的丢包呢？

hanzhenlll

创建1个管理线程，动态检查线程警戒线， 没有可用资源向客户端发送信息。。

tongban1981

现象补充：

发现是服务器端有问题，还没具体定位，不过更细化了。 在服务器端，为了统计时间，我使用了gettimeofday函数或者time函数。发现有这些函数时，几百次连接同时过来，在accept到300左右时（可能不固定）就会阻塞3秒左右，不使用这些时间函数基本不阻塞。现在还不知道是时间函数吊住了还是时间函数导致poll吊住了。还要再具体分析一下。

pself

syn cookie 关了吗

tongban1981

syn cookie等都关闭了，感觉和没关时效果差不多，不像它的原因

yulihua49

tongban1981 发表于 2012-10-31 23:57
在做某功能实现时，会同时发起多个客户端向同一服务进行连接的操作，此时发现部分连接请求被阻塞了2. ...

PPC:256是个坎，最好不要超过256。
如果需要超过256，请用TPC或T－pool模式。

是用xinetd侦听吗？那就更不行了。


交易服务器框架提供各种交易并行的处理机制，包括PPC（每个连接一个进程），TPC（每个连接一个线程），TPOOL(线程池)模型。PPC模型具有最好的可靠性，可直接用于客户端并发连接数不大（<256）的场合，如果需要大并发连接，可以配合交易管理器使用。TPC模型具有最好的可移植性，容易移植到各种平台。可以配合SDBC提供的自愈式数据库连接池工作，比PPC更有效的使用数据库资源。适宜处理客户端并发连接数<1000的场合，如果需要更大的并发连接数，可以配合交易管理器使用。TPOOL模型具有最好的系统资源利用率，适于大量客户端的并发接入场合，必要时也可以配合交易管理器，可以使用数据库连接池和其他连接池。由于使用了高性能的epoll机制，其可移植性受限，仅用于LINUX系统。

pself

再用台机器作为客户端，2台同时连接服务器，看是不是结果一样。就可以判断是服务器还是客户端问题

tongban1981

pself 发表于 2012-11-02 14:43
再用台机器作为客户端，2台同时连接服务器，看是不是结果一样。就可以判断是服务器还是客户端问题

小实验的卡，基本定位就是服务器程序的问题。做实验，找了两个同事一起，各自写了小客户端和服务器，互相进行交叉测试，发现只有我的服务器会卡。最后发现只有我使用了gettimeofday时间函数。去掉之后就不卡了。如果改为使用time函数，大部分情况不卡，但偶尔也会卡一次。还没分析清楚具体原因。（做实验单独使用getimeofday没发现卡的情况，100万次调用也只需要1.5秒左右）。

另外，发现实际工作的版本有时还是会卡，由于那个网络环境比较复杂，还在继续分析中。