Skip to content

event_dispatcher 数量设置咨询 #3191

@MJY-HUST

Description

@MJY-HUST

在我们的场景中,通过 brpc 框架传输数据量较大。单个客户端可能会和多个服务端建立连接。在流量较小时(大量 brpc_worker 都阻塞在 parking log上),如果单次发送大量请求后返回。极端情况下分为两种可能,会影响系统长尾时延

  • 通过一个 fd 接收所有的 repsonse,此时虽然能产生 n 个 bthread,但是加了nosignal的flag。最后的 bthread_flush 只能唤醒最多 2 个 brpc_worker 消费。其实大量的 response 都是在串行消费。 这里是 signal_task 为了权衡性能和​​调度及时性,所以设置成了2。目前来看好像已经是最优设置?
  • 如果 response 通过多个 fd 接收。fd 的 消费在一个 event_dispatcher 中是串行的,此时也会存在大量response 串行消费的问题。但是这种场景下,可以通过增加 event_dispatcher 的数量,来提升唤醒并消费任务的 brpc_worker 数量, 实测可以提升一些性能。

这里有几个问题咨询一下

  • event_dispatcher 数量设置有什么建议参考吗?event_dispatcher 较多对性能有副影响么?
  • 当前 event_dispatcher_num 设置是不区分 tag 的,即每个 tagged group 都会初始化 event_dispatcher_num 个 bthread。但是基于实际需求,每个 tagged group 中的 brpc_worker 数实际上是不一样的。之前 当event_dispatcher_num 大于 num_threads 时,ctrl c失效 #1120 中提到过,event_dispatcher_num 的大小不能大于等于 brpc_worker 的数量,否则会存在问题。导致在多 tag 场景下设置 event_dispatcher_num 不太灵活,是不是应该有类似于分别设置或者每 n 个 brpc_worker 初始化一个 event_dispatcher 的参数。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions