客户端出现大量timeout

[cuisonghui]

search() leaf error:host:.bj,port:8104,brpc status code:1008,brpc error message:[E1008]Reached timeout=3000ms @:8104,query:穿越时空之妃不能忍 timecost:3001 latency:3001291

大部分的请求都是正常，但是会会出现很多的timeout 错误，但是此query,在服务器端的耗时确实正常，只有几十毫秒．

使用的单连接，baidu_std协议．设置了3秒的超时时间．

感觉消息阻塞在网络或者框架上了，请问怎么排查此类问题，有没有可能单连接的各种缓冲区满了，导致阻塞等???

[jamesge]

先按这个排查一下

[cuisonghui]

@jamesge 好的，谢谢，目前我的服务打开vars就会挂掉，我先把这个问题定位一下．

[jamesge]

先跑下asan排除下内存问题吧

[cuisonghui]

目前已经定位到访问vars core dump的问题.

具体core原因没有定位到，目前已经把name=bvar_sampler_collector_usage的统计去掉，

就变得一切正常，请问去掉这个统计项会对其他逻辑或者功能产生副作用吗?

[cuisonghui]

vars显示是正常的，但是只有点击一下，就会变成0,请问这个问题怎么解决呢．

[jamesge]

你这个程序看上去不太正常，跑过asan么？你上面那个coredump不像是root cause，更像是内存写坏后的“受害者”

[cuisonghui]

我用gperf跑了一下内存，没发现明显问题，而且这个程序一直在线运行，也一直表现平稳，最近想把grpc替换成brpc就出现了莫名的问题．
我再用asan跑跑．

[cuisonghui]

目前bvar问题已经定位到原因：
由于我们的程序是使用守护进程方式启动，会fork两次．
改为使用非守护进程运行(前台运行)，bvar系统以及统计项是没有问题的．
请问守护进程模式，会有什么限制吗?

[jamesge]

fork两次目前不支持，见 #208 ，现象就是很多bvar都为0或不再更新

[cuisonghui]

已经把bvar的线程移动到main函数之后执行，以保证fork之后才执行bvar线程．

目前进行业务压测，超时问题应该是bthread_worker_usage达到上限导致,跟预期服务承载能力不相符，目前还在排查．

但是随着qps继续上涨，服务会直接卡死，访问前端页面(http://:6104,http://:6104/vars)也不行，压测全部报超时error

---

Search request Error1: 1008: [E1008]Reached timeout=3500ms @:6104 Query : 爱情练习题
Search request Error1: 1008: [E1008]Reached timeout=3500ms @:6104 Query : 爱情两部曲
Search request Error1: 1008: [E1008]Reached timeout=3500ms @:6104 Query : 爱情两好三坏
Search request Error1: 1008: [E1008]Reached timeout=3500ms @:6104 Query : 爱情领域

---

且服务cpu占用基本为0,服务不能自己恢复正常,只能重启解决．
但是netstat查看监听端口正常,处于LINSEN状态，并且使用telnet访问此端口也能连接上.
最后发现是服务的线程block住，导致的问题.

我的理解是这样子的:由于我的服务还会使用brpc client往下游发送数据，而造成bthread资源不够,所以整体block住,不知道对不对.

请问这种情况如何避免?

[jamesge]

限制最大并发了么？https://github.com/apache/incubator-brpc/blob/b0533d17d3efce43dcc6f2359a559fed95e5791e/docs/cn/server.md#%E9%99%90%E5%88%B6%E6%9C%80%E5%A4%A7%E5%B9%B6%E5%8F%91

[cuisonghui]

没有设置最大并发度，之前也想设置，但是对应的不知道bthread_worker_count应该设置多少.
因为我们的系统是这样的，此服务需要向后端节点(比如说10个后端节点)发送请求,那么就会从我们自己的线程池中取10个thread并发请求后端节点，整体都是同步等待的过程，根据我的理解，这样的话可能一次请求就需要消耗bthread的数量是10＋1次.

[jamesge]

建议直接用rpc的接口，半同步方式，不要每个rpc占用一个bthread。

[cuisonghui]

@jamesge 我了解了一下半同步方式．在读文档的时候，发现有ParallelChannel这种组合channel.请问这种channel是否就可以解决我目前遇到的问题？
由于不太了解ParallelChannel的机制，我的理解是这样的:在rpc的bthread线程中调用了pthread的阻塞函数，而同时又使用client同步客户端，导致死锁．那我换成ParallelChannel，相当与把pthread的阻塞函数换成bthread的阻塞，这样是不是就不会出现死锁问题?

[cuisonghui]

@jamesge 目前在使用ParallelChannel半同步模式，假如有一个下游节点出问题了，用什么方法可以知道？目前ParallelChannel是提供map和merge函数的，可以干预请求和返回，但是如果失败的，有这样的回调函数吗。