Open sukki37 opened 2 months ago
未处理
未处理
未处理
未处理
未处理
未处理
未处理
未处理
未处理
未处理
本地跑了多次测试,当cpu负载过高时,一个 goroutine 的 propose 的 off cpu 时间会略长于另一个 goroutine 的 fsync 的时间。
原因是 propose 的请求是异步等待的,通过 go select 方法等待 propose 的结果,所以当系统负载高时,这里的 runtime 调度也会有多余的等待的。
目前 dragonboat 的写入数据的路径实现没有办法修改,也没什么优化手段了,这里已经是调用 go 最底层的异步处理方式了。
暂不处理这个问题
Is there an existing issue for the same tech request?
Does this tech request not affect user experience?
What would you like to be added ?
During testing of the insert on non-primary key tables(standalone), we observed that the logservice propose operation has a significantly longer wait time compared to the fsync operation. The discrepancy between these two operations seems to indicate that the propose process, which is supposed to commit logs across replicas, is being delayed by factors that are not related to the disk I/O or fsync operations.
Why is this needed ?
This could be causing delays in transaction processing and impacting overall performance, especially in high-concurrency scenarios.
Additional information
tool: https://github.com/iovisor/bcc https://github.com/brendangregg/FlameGraph
command: /bcc/tools/offcputime.py -df -p "$(pgrep -d ',' test)" 30 > out.stacks ./FlameGraph/flamegraph.pl --color=io --title="Off-CPU Time Flame Graph" --countname=us < out.stacks > out.svg