We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
我们在线特征服务通过redis协议,请求一个同机部署的data_mesh服务。该data_mesh服务使用brpc搭建,redis协议。data_mesh收到同机的特征服务的请求后,进行协议转换然后请求远端存储。特征服务和 data_mesh 在同一个 POD,通过 k8s 进行部署。k8s 对 data_mesh 所在的 docker 进行了绑核,绑定到了 1 个 CPU 核心上。 绑核是通过 k8s 的 资源限制 request/limit 来做的,而非 set_cpu_affinitiy 特征服务请求 data_mesh 走的是 127.0.0.1, 不经过网卡
我们发现特征服务请求 data_mesh 的耗时较高,哪怕是 data_mesh 不带任何业务(空跑一个 brpc server),同机调用的P99 latency 在 2ms 左右。 但 avg 耗时基本正常,比 ping 略高,在500us 左右。 我们的 qps 并不高,只有 50 左右。data_mesh 通过内置服务来看,资源使用情况也很空闲。
我们猜想,在 1 个核的情况下,brpc server 彻底失去了并行的能力,导致在 epoll thread 和 brpc worker 之间线程切换开销较大。
请问是否有更进一步的排查问题的方法以及解决方案?
The text was updated successfully, but these errors were encountered:
单核情况下你开了多少个worker?同机访问可以考虑用uds,能够进一步减少网络耗时
Sorry, something went wrong.
试着减少一下worker数量
No branches or pull requests
背景描述
我们在线特征服务通过redis协议,请求一个同机部署的data_mesh服务。该data_mesh服务使用brpc搭建,redis协议。data_mesh收到同机的特征服务的请求后,进行协议转换然后请求远端存储。特征服务和 data_mesh 在同一个 POD,通过 k8s 进行部署。k8s 对 data_mesh 所在的 docker 进行了绑核,绑定到了 1 个 CPU 核心上。
绑核是通过 k8s 的 资源限制 request/limit 来做的,而非 set_cpu_affinitiy
特征服务请求 data_mesh 走的是 127.0.0.1, 不经过网卡
问题描述
我们发现特征服务请求 data_mesh 的耗时较高,哪怕是 data_mesh 不带任何业务(空跑一个 brpc server),同机调用的P99 latency 在 2ms 左右。 但 avg 耗时基本正常,比 ping 略高,在500us 左右。 我们的 qps 并不高,只有 50 左右。data_mesh 通过内置服务来看,资源使用情况也很空闲。
猜想
我们猜想,在 1 个核的情况下,brpc server 彻底失去了并行的能力,导致在 epoll thread 和 brpc worker 之间线程切换开销较大。
请问是否有更进一步的排查问题的方法以及解决方案?
The text was updated successfully, but these errors were encountered: