-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bthread signal & wait 问题咨询 #2849
Comments
这个是一个普遍问题,我们线上也遇到了。有状态服务一般会独占机器,现在机器普遍核数都比较多,基本都100+核数了。目前看到brpc在bthread worker比较多的时候调度开销比较大,希望社区能尽快解决一下哈~ ❤️ |
分tag得把N个tag(brpc::Server)绑到N个port吧,不太优雅 |
是的,需要这么做,如果各个Server之间没有要求很强的隔离性,那确实也不用这么做。本质上是得优化协程调度。 |
据我观察,频繁的触发 futex_wake 和 futex_wait 的原因是因为整个系统在“不必要”的时机进入的休眠状态,这样很容易产生一个 wake 和 多个 wait,导致系统调用频繁,worker 越多,wait 和 wake 越频繁,所以减少如何减少这种“不必要性”才是最重要的。我这边经过大量的测试发现一个 case 就是整个系统在高压繁忙下也进入了 wait 状态,很明显这是“不合适的”,“不必要的”。这是由于当前的模型下,会导致 epoll 延后处理,形成了多个 worker 工作在一个 queue 上,queue 没有了,立刻都进入休眠,然后 epoll 被唤醒后,“worker 们”又相继被唤醒,造成了”不必要性“。 |
你的PR #2819 先合下? |
好的,已经在修改中了,刚空出时间来搞 |
在使用过程中,观察server侧的火焰图,此时brpc_worker thread的cpu基本打满。发现futex_wake、futex_wait占用的时间占比比较高,竞争锁成为了瓶颈。怀疑可能是由于调度不均衡,某些worker中的task较多,而一些worker的task较少,当这些task消费完之后每次都会调用wait,然后又快速被signal唤醒。同时也存在parking_lot中没有wait的线程但仍然在signal的场景。
这方面是否存在一些优化点,比如:
The text was updated successfully, but these errors were encountered: