Perf Sched 研究

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