Skip to content
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

server侧一次pv支持 cpu 资源统计 #1822

Closed
feng-y opened this issue Jun 27, 2022 · 4 comments
Closed

server侧一次pv支持 cpu 资源统计 #1822

feng-y opened this issue Jun 27, 2022 · 4 comments
Labels
feature new feature

Comments

@feng-y
Copy link

feng-y commented Jun 27, 2022

Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)

Describe the solution you'd like (描述你期望的解决方法)
在grpc/ brpc-pthread 模式下 支持使用 clock_gettime(CLOCK_THREAD_CPUTIME_ID) 获取整体的cpu资源,方便用于pv级别统计cpu资源,并用于 abtest 实验追述,然后用于实验资源的评估;

希望可以在自定义的bthread 中 以及 相应rpc 的bthread 中统计cpu 资源

Describe alternatives you've considered (描述你想到的折衷方案)
bthread_attr_t 增加 fn,再切换时支持统计

Additional context/screenshots (更多上下文/截图)

@wwbmmm
Copy link
Contributor

wwbmmm commented Jul 28, 2022

原始需求是统计一次pv消耗的cpu资源,但仅从bthread层面来统计是不够的。我们可以修改bthread代码来统计一个bthread消耗的cpu,但如何把bthread跟一次pv关联起来是难点。
比如在一次pv的处理过程,server端会有io的bthread、处理请求的bthread,client端会有处理rpc response的bthread。
比如用户在处理请求过程中可能启动bthread/pthread来进行并行处理,或者将任务提交到某个bthread/pthread线程池中处理。

另一种思路可以考虑下:将不同成份的流量路由到不同的实例,然后比较不同实例的cpu消耗,从而进行实验资源的评估。

@feng-y
Copy link
Author

feng-y commented Aug 2, 2022

暂时比较难支持路由实例的事情,有办法先统计bthread的耗时么

@wwbmmm
Copy link
Contributor

wwbmmm commented Aug 2, 2022

Describe alternatives you've considered (描述你想到的折衷方案)
bthread_attr_t 增加 fn,再切换时支持统计

看了下百度内部现有的bthread_attr_t自定义fn的方式不太满足这里的需求,因为server端bthread是由框架创建而不是由用户创建的,传不了自定义的bthread_attr_t。
因此,这个需求还需要重新开发。如果只是统计bthread的cpu消耗,可以考虑扩展一下bthread::TaskStatistics,加个cpu消耗的统计项,并且在bthread切换时更新该值。

@chenBright
Copy link
Contributor

Closed this as completed in #2852 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature new feature
Projects
None yet
Development

No branches or pull requests

3 participants