雪崩效应造成处理阻塞

昨天（其实好久了，这是邮件内容）发现ogre4ad（一个比较适应通用的通讯协议的服务器，依靠PIPE和业务进程通讯）发送数据感觉速度慢，（就像有阻塞），服务器重启动一段时间后，就会出现后端服务器进城将发送管道写满的情况。前端的用户请求无法正常处理。

业务服务器的日志如下，每次处理都是管道阻塞。

Apr 23 19:00:42.771 2008@LM_ERROR@SEND_PIPE Pipe is full or data small?,Some data can't put to pipe. Please increase and check.

Apr 23 19:00:42.771 2008@LM_INFO@tmplen:1234 deque_begin=2707885,deque_end=2813817

Apr 23 19:00:42.771 2008@LM_DEBUG@put frame to pipe.len:1437 i:0

Apr 23 19:00:42.771 2008@LM_INFO@Before push_end node->sizeofnode:1437 deque_begin=2521517,deque_end=2521457

Apr 23 19:00:42.771 2008@LM_ERROR@SEND_PIPE Pipe is full or data small?,Some data can't put to pipe. Please increase and check.

Apr 23 19:00:42.771 2008@LM_INFO@tmplen:1429 deque_begin=2709119,deque_end=2813817

从OGRE 4A 的日志来看。

Apr 23 19:32:44.406 2008@LM_INFO@tmplen:1437 deque_begin=3063266,deque_end=3058935

Apr 23 19:32:44.406 2008@LM_INFO@Can't find svchanle info. svrinfo IP|Port:[58.44.83.95|24812] .

Apr 23 19:32:44.406 2008@LM_INFO@Has 767 peer want to close. Please wait. ACE that is accursed.

从日志和配置文件，代码定位看到情况如下：

1.发送PIPE的管道不长，只有 5M 。但是这个问题应该不足以引发问题，只是错误的一个诱因。

2.INFOSVRD发送的数据比较长，一个用户就有1.6K左右。结合前面的问题，目前的管道只能处理大约3000个请求。但这还是一个诱因。

3.根据日志观察，每次OGRE都只从管道取出一个数据发送，但是却找不到发送目标对应句柄，由于是WEB业务，这个服务器的客户端可能经常断开。

5.检查OGRE的代码，在发送数据时如果出现错误（包括找不到对端）就退出从PIPE取数据的循环。如果正常，这个循环会一次取多达1024个发送数据。而错误情况，只处理一个数据。

6.每次处理的时间片间隔有点长，达到0.05s。

 

由于上面这些原因和错误，一个雪崩效果就造成了。

由于客户端可能经常吊线，结果造成每次从PIPE只能取一个数据出来，所以找不到原来对应的端口。然后处理退出循环，继续等，然后由于等待时间很长，更多的端口肯定断掉了，结果只有恶性循环了。所以数据一直发送不出去。

 

修正问题

核心问题应该还是处理循环的问题，将代码修改为出现错误时，继续处理，测试，客户端得到正常请求。其他几个问题调整后修正。