-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
brpc如何处理磁盘IO密集型服务 #2582
Comments
对于磁盘IO阻塞导致bthread worker耗尽,这个可以考虑把rocksdb的调用放到一个单独的tag分组里面。这样网络和磁盘IO就分开了。 |
是一个好办法,请问作为客户端发起的bthread算哪个tag的?0吗?还是发起请求的bthread所在的tag |
客户端默认都是0,多个tag,是服务端的配置。可以参考https://github.com/apache/brpc/blob/master/docs/cn/bthread_tagged_task_group.md 这个文档 |
多谢,我试一下 |
#2551 这个PR没有合入,感觉跨worker池子通信是需要的。 |
这个 PR 解决什么问题呢 |
跨worker池子之间的协程唤醒问题。 |
这个文档中好像没有写清楚如何设置 tag 中的 worker 数量 |
文档已更新,需要先设置好FLAGS_bthread_current_tag,然后再设置FLAGS_bthread_concurrency_by_tag 。也可以调用bthread_setconcurrency_by_tag。 |
使用rocksdb作为backend的kv服务,brpc作为rpc框架,在handler里面同步调用rocksdb方法获取数据。
在这种模型下,如果rocksdb发生了阻塞,比如磁盘IO过高导致的问题,bthread worker会迅速用光,最终整个服务就会hang住,连metric都收集不了。
官方有什么建议吗?百度内部是如何处理这种常见的服务的。需要为rocksdb的get方法单独起一个线程池异步执行?
The text was updated successfully, but these errors were encountered: