最近一直在弄 TiKV 的性能优化,想到是否系统的 scheduler 会影响 TiKV 的性能,于是就稍微研究了下 perf sched。
首先抓取一段时间的记录,使用
sudo perf sched record -- sleep 5
这里需要注意,sched 会记录非常多的信息,所以时间不能很长,我上面就是记录了 5 秒,大概生成了快 400 MB 的数据。
然后使用 latency 命令来看最大的 delay:
sudo perf sched latency -s max
-----------------------------------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at |
-----------------------------------------------------------------------------------------------------------------
grpc-poll-2:(3) | 10162.378 ms | 83270 | avg: 0.019 ms | max: 2.346 ms | max at: 2600393.062326 s
grpc-poll-1:(3) | 11509.903 ms | 68917 | avg: 0.018 ms | max: 2.208 ms | max at: 2600394.231449 s
grpc-poll-0:(3) | 12253.333 ms | 53227 | avg: 0.020 ms | max: 2.024 ms | max at: 2600391.721447 s
可以看到,我们最大的 delay 是 gRPC 线程的 2.346 ms,在 2600393.062326 s 这个时间点,可以通过 script 命令详细的找到相应的地方。下面只是一个简单的 script 例子:
sudo perf sched script
raftstore-5 91697 [017] 2587136.922586: sched:sched_wakeup: apply_worker_2:91706 [120] success=1 CPU:019
raftstore-5 91697 [017] 2587136.922586: sched:sched_wakeup: apply_worker_2:91706 [120] success=1 CPU:019
:91649 91649 [008] 2587136.922610: sched:sched_wakeup: grpc-poll-0:91709 [120] success=1 CPU:006
:91649 91649 [008] 2587136.922670: sched:sched_wakeup: grpc-poll-0:91709 [120] success=1 CPU:006
raftstore-5 91697 [017] 2587136.922705: sched:sched_wakeup: apply_worker_1:91705 [120] success=1 CPU:031
我们也可以通过 map 命令详细的知道每个 CPU 任务的运行状态以及切换情况:
sudo perf sched map
B0 U0 Y0 A0 . B1 S0 J0 Q0 . E0 C0 A1 . Z0 . . W0 *C1 M0 G0 L0 R0 N0 2600390.841419 secs C1 => raftstore-5:91697
B0 U0 *. A0 . B1 S0 J0 Q0 . E0 C0 A1 . Z0 . . W0 C1 M0 G0 L0 R0 N0 2600390.841423 secs
B0 U0 . A0 . B1 S0 J0 Q0 . E0 *. A1 . Z0 . . W0 C1 M0 G0 L0 R0 N0 2600390.841432 secs
B0 U0 . A0 . B1 S0 J0 Q0 . E0 . A1 . Z0 . . W0 C1 M0 *. L0 R0 N0 2600390.841436 secs
B0 U0 . A0 . B1 S0 J0 Q0 . E0 . A1 . Z0 *K0 . W0 C1 M0 . L0 R0 N0 2600390.841437 secs
B0 U0 . *. . B1 S0 J0 Q0 . E0 . A1 . Z0 K0 . W0 C1 M0 . L0 R0 N0 2600390.841438 secs
上面每一行表示的是当前时间点所有 CPU 执行任务的情况, A0,C1 表示的是执行的任务,而 .
则是表明空闲,*C1
这个表明发生了切换,切到了任务 C1 上面。上面可以发现几乎所有 CPU 都在处理任务。
因为我们并没有安装最新的内核,所以并没有 perf sched 的 timehist 命令,也就没法尝试了。另外,perf sched 还有一个 replay 命令,会根据采集到的数据回放,便于排查问题。
上面仅仅是对 perf sched 的简单使用,可以知道,我们最大的 delay 是 2 ms,那么,能不能减少呢?
因为我们通常使用的都是 CFS 调度,有几个指标可以关注:
-
sched_min_granularity_ns
:任务最小运行时间,防止频繁的切换 -
sched_wakeup_granularity_ns
:该值只是用来判断任务被唤醒后能否抢占当前任务。 -
sched_latency_ns
:CFQ 队列所有任务的运行一次的周期。如果任务数量超过了sched_latency_ns / sched_min_granularity_ns
,周期就是number_of_running_tasks * sched_min_granularity_ns
。
对于我们系统来说,这三个值如下:
kernel.sched_min_granularity_ns = 3000000
kernel.sched_latency_ns = 24000000
kernel.sched_wakeup_granularity_ns = 4000000
看起来有点大,参考网上的一些实现调整下:
kernel.sched_min_granularity_ns = 100000
kernel.sched_wakeup_granularity_ns = 25000
kernel.sched_latency_ns = 1000000
继续测试,发现性能没啥太大的变化,而且 perf sched record 发现最大的 latency 也跟之前差不多。具体原因,我因为还不熟悉内核,所以也就考虑放一放,后面在请教大牛。但这里我知道,这个调整虽然在我测试这边没发现太大的作用,但至少学会了通过 sched 来排查系统的问题,这个没准以后能在其他的地方用到。
网友评论