doc001
doc001
> 这个看着是thrift依赖的问题
从栈上看是因为没有足够的线程运行bthread，导致了 bthread 的堆积，这个得找为什么堆积了
pthread mutex 里有线程 id的字段，可以看看持有锁的线程在做什么
另外，参考一下这个问题：https://github.com/baidu/braft/issues/139
本质上是这个问题：https://github.com/apache/incubator-brpc/issues/473 。可以先切换成 bthread mutex 试试 ，参见 macros.h： //#define USE_BTHREAD_MUTEX 使用 bthread mutex 后，类型 1 的栈会在类型 2 后排队，可以让用于执行 bthread 的线程更多，不造成堆积的话，也就不会有这种死锁 case
> > 本质上是这个问题：[apache/incubator-brpc#473](https://github.com/apache/incubator-brpc/issues/473) 。可以先切换成 bthread mutex 试试 ，参见 macros.h： > > //#define USE_BTHREAD_MUTEX > > 使用 bthread mutex 后，类型 1 的栈会在类型 2 后排队，可以让用于执行 bthread 的线程更多，不造成堆积的话，也就不会有这种死锁 case > > 多谢解答！ >...
我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了
> > 我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了 > > 多谢，我们是有做一些代码的修改，现在已经能够编译通过，并用bthread_mutex代替pthread_mutex做了一下验证，发现仍然有可能导致死锁的问题。 > 我理解在_rq full时，如果在_rq里所有换出的bthread拿的锁恰好是当前正在执行的bthread里所需要拿的锁，就可能发生死锁的情况，不知道我理解得对不对。这里如果想要彻底解决这个问题，就需要避免_rq full的时候换出的bthread持有的锁是正在执行的bthread要拿的锁这种情况。不知道是否有比较好的办法可以从根本上解决这个问题？ > 还有一个问题想请教一下，bthread_mutex里的mutex是一个unsigned int，没有标识线程信息，这里拿到了这个unsigned int之后如何去找谁持有了这个mutex呢？ 关键还是看为什么请求会堆积。可以看下 bthread usage，在brpc的bvar页面里能找到，如果这个usage和cpu usage能对上，说明是cpu瓶颈了，处理能力已经超出单机的能力，需要考虑做限流。如果usage远低于cpu usage，说明代码内阻塞的操作比较多，这时候需要找耗时比较长的地方，可能是磁盘操作或者其他类型的阻塞，具体的得靠抓栈和一些监控来分析，调大max_concurrency可以缓解情况，不过还是得先找到根因。
> > > 我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了 > > > > > > 多谢，我们是有做一些代码的修改，现在已经能够编译通过，并用bthread_mutex代替pthread_mutex做了一下验证，发现仍然有可能导致死锁的问题。 > > 我理解在_rq full时，如果在_rq里所有换出的bthread拿的锁恰好是当前正在执行的bthread里所需要拿的锁，就可能发生死锁的情况，不知道我理解得对不对。这里如果想要彻底解决这个问题，就需要避免_rq full的时候换出的bthread持有的锁是正在执行的bthread要拿的锁这种情况。不知道是否有比较好的办法可以从根本上解决这个问题？ > > 还有一个问题想请教一下，bthread_mutex里的mutex是一个unsigned int，没有标识线程信息，这里拿到了这个unsigned int之后如何去找谁持有了这个mutex呢？ > > 关键还是看为什么请求会堆积。可以看下 bthread usage，在brpc的bvar页面里能找到，如果这个usage和cpu usage能对上，说明是cpu瓶颈了，处理能力已经超出单机的能力，需要考虑做限流。如果usage远低于cpu usage，说明代码内阻塞的操作比较多，这时候需要找耗时比较长的地方，可能是磁盘操作或者其他类型的阻塞，具体的得靠抓栈和一些监控来分析，调大max_concurrency可以缓解情况，不过还是得先找到根因。 另外，brpc内置了一个contention分析的页面，可以分析锁冲突的耗时。到了rq is...
> > > > > 我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了 > > > > > > > > > > > > 多谢，我们是有做一些代码的修改，现在已经能够编译通过，并用bthread_mutex代替pthread_mutex做了一下验证，发现仍然有可能导致死锁的问题。 > > > > 我理解在_rq full时，如果在_rq里所有换出的bthread拿的锁恰好是当前正在执行的bthread里所需要拿的锁，就可能发生死锁的情况，不知道我理解得对不对。这里如果想要彻底解决这个问题，就需要避免_rq full的时候换出的bthread持有的锁是正在执行的bthread要拿的锁这种情况。不知道是否有比较好的办法可以从根本上解决这个问题？ > > > >...