swoole recv后报 “Resource temporarily unavailable”

今天组内有人反应线上脚本 每天有上百个 “Resource temporarily unavailable” 异常,程序是nsq的消费脚本 调用了zan框架的服务接口,最终的原理是 脚本把我需要的接口名字send 给服务方,recv结果的时候收到了Resource temporarily unavailable错误 errno 码是11,查了下资料有两种情况 linux会报这中错误 一个是发送时 一个是接收时 ,应该是swoole内部某个recv方法没有判断EAGAIN错误,初步判断问题出在swClient_tcp_recv_no_buffer 方法,但是不确定,待验证。

(一)发送时

  当客户通过Socket提供的send函数发送大的数据包时,就可能返回一个EAGAIN的错误。该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值。tcp_sendspace定义了应用在调用send之前能够在kernel中缓存的数据量。当应用程序在socket中设置了O_NDELAY或者O_NONBLOCK属性后,如果发送缓存被占满,send就会返回EAGAIN的错误。
  为了消除该错误,有三种方法可以选择:
  1.调大tcp_sendspace,使之大于send中的size参数
  —no -p -o tcp_sendspace=65536

  2.在调用send前,在setsockopt函数中为SNDBUF设置更大的值

  3.使用write替代send,因为write没有设置O_NDELAY或者O_NONBLOCK

(二)接收时

接收数据时常遇到Resource temporarily unavailable的提示,errno代码为11(EAGAIN)。这表明你在非阻塞模式下调用了阻塞操作,在该操作没有完成就返回这个错误,这个错误不会破坏socket的同步,不用管它,下次循环接着recv就可以。对非阻塞socket而言,EAGAIN不是一种错误。在VxWorks和Windows上,EAGAIN的名字叫做EWOULDBLOCK。其实这算不上错误,只是一种异常而已。

  另外,如果出现EINTR即errno为4,错误描述Interrupted system call,操作也应该继续。

  最后,如果recv的返回值为0,那表明对方已将连接断开,我们的接收操作也应该结束。

(三)以下是另一种解释

假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发,当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,

需要封装socket_send()的函数用来处理这种情况,该函数会尽量将数据写完再返回,返回-1表示出错。在socket_send()内部,当写缓冲已满(send()返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部,但暂没有更好的办法.

参考资料:http://blog.csdn.net/tianmohust/article/details/8691644

发表评论

电子邮件地址不会被公开。 必填项已用*标注