Perf Sched 研究

作者: siddontang | 来源:发表于2017-06-24 13:21 被阅读1370次

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

    相关文章

      网友评论

        本文标题:Perf Sched 研究

        本文链接:https://www.haomeiwen.com/subject/svkkcxtx.html