最近一直在弄 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 来排查系统的问题，这个没准以后能在其他的地方用到。
