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

tongban1981

hanzhenlll 发表于 2012-11-01 14:40
创建1个管理线程，动态检查线程警戒线， 没有可用资源向客户端发送信息。。

   我的服务器是单进程的，因为其实这个是个动态服务器，每次就是管理这几百个连接的一些请求，管理完就互相都退出了。 做实验时客户端用多线程也是为了模拟多点请求同时过来的情况。

tongban1981

yulihua49 发表于 2012-11-02 14:07
PPC:256是个坎，最好不要超过256。
如果需要超过256，请用TPC或T－pool模式。

    我的程序中，不是那种accept后创建进程或线程来管理的，而是一个进程本身来同时管理这几百个连接。 服务端程序本来就是一个动态管理进程，它启动后，要求其他数百个节点（不超过400个节点，连接过来不超过800个连接，每节点两个）启动计算进程并做一些计算。建立这些连接只是用来做一些管理上的交互（一个上行，一个下行）。现在就是觉得连接请求过来的比较集中，不知道为什么导致了阻塞。 （正常服务端接受一个连接很快的，可能只要1ms左右，但隔三百个左右就会卡3秒钟左右）

   由于对tcp的原理了解的不够深入，所以在分析上可能有盲点，导致一直没有分析到具体原因。

   实验试了一下，发现建立的连接< 150时（150是个概数，不是精确数字），其实哪怕服务器端不做accept操作，客户端的连接也成功返回了的，也就是其实服务器端操作系统自动把连接建好了，accept只是从系统获取到了建立连接的fd。所以前150个连接请求应该是特别快的。后面的连接请求服务器系统没有把客户端的连接收下来，估计是系统机制的原因？只有服务器程序accept之后，后面的连接才能继续。目前还没试过这个是操作系统自动接收的还是服务器程序接收的，后面做实验看看。
   按说哪怕有上千个连接同时过来，进backlog排序队列，服务器处理，也不应该出现卡的情况的。尤其是我现在只是accept下来，还没有进行实际的处理。-_-   

linux_c_py_php

分析tcp协议不如分析你自己的程序架构是否合理.

tongban1981

linux_c_py_php 发表于 2012-11-03 00:16
分析tcp协议不如分析你自己的程序架构是否合理.

现在关键是出问题的地方流程是比较简单的，不知道为什么会卡啊。

在一个端口accept，不应该有什么问题啊。连接也才几百个-_-
难道是因为都是一起来的，太密集了？ 我倒是可以改成让大家有个时间差过来，不过现在更想分析一下现在的现象是为什么。

safedead

回复 14# tongban1981


    你的程序有逻辑BUG
    一般在RHEL做单纯数据转发的服务程序，
    ulimit -n 65536
    ulimit -s 4096
    单进程处理3万套接字以下出连接问题的，
    别怀疑操作系统和硬件，肯定是程序的问题

linux_c_py_php

ulimit -n 10000 -SH

safedead 发表于 2012-11-03 13:08
回复 14# tongban1981

tongban1981

回复 15# safedead


   逻辑上应该没什么问题，我现在做实验，为了避免客户端和服务器在同一机器的影响（同时也为了保证连接的并发到达，毕竟创建线程模拟并发还是有时间差的），将服务端放置于一台机器上，客户端放置于其他多台机器。客户端、服务器通过思科交换机连接（只经过这一级，不经过其他交换机）。多个客户端连接请求同时过来，并在建立的连接上进行少量数据交互，之后连接不断开。服务器在accept后派生线程进行数据收发。收发结束后线程退出。 发现在accept到260左右（总花费时间24ms左右）时，会卡1秒钟（这一秒钟poll没有监测到新的连接请求过来）。

最近在做其他事情，这个实验没有细挖下去。
明天打算抽时间做的实验：

1）出现poll等不到连接请求时，当时存活的处理线程数？会不会处理速度不够，导致当时有太多的线程在收发数据，会有问题。（派生线程数未加限制，所以当时最多可能会有几百个在同时收发，考虑加个数量限制，虽然总量只有不到800个，但前面退出慢的话，可能确实会有问题）
2）另作一个测试程序或测试包，在做实验时同时测试客户端、服务器的网络连通性（之前做实验时同时对服务器所在节点开着一个ping，未发现有失败及卡的情况，不过这个不实时，需要换一下；
3）测试未做实验和实验时，服务器的网络延时