RocksDB PhysicalCoreID 慢问题排查

作者: siddontang | 来源:发表于2017-12-25 13:36 被阅读747次

    最近测试的时候,发现了一个奇怪的现象,在一些机器上面,压力不高,但 RocksDB 整个操作很慢。虽然 CPU 占用也不怎么高,但我们还是用火焰图先 profile 下,发现所有的疑点都落在了 PhysicalCoreID 这个函数上面。

    用 perf top 命令更加明确了问题

    这个函数主要是 RocksDB 那边用来得到当前在哪一个 CPU 上面执行,从而方便将 metric 直接跟这个 CPU 绑定的,具体可以参考 Core-local Statistics 这篇文章。因为这是一个非常频繁的操作,照理应该不会这么慢的。于是先看了看 RocksDB 相关的代码

    int PhysicalCoreID() {
    #if defined(ROCKSDB_SCHED_GETCPU_PRESENT) && defined(__x86_64__) && \
        (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 22))
      // sched_getcpu uses VDSO getcpu() syscall since 2.22. I believe Linux offers VDSO
      // support only on x86_64. This is the fastest/preferred method if available.
      int cpuno = sched_getcpu();
      if (cpuno < 0) {
        return -1;
      }
      return cpuno;
    #elif defined(__x86_64__) || defined(__i386__)
      // clang/gcc both provide cpuid.h, which defines __get_cpuid(), for x86_64 and i386.
      unsigned eax, ebx = 0, ecx, edx;
      if (!__get_cpuid(1, &eax, &ebx, &ecx, &edx)) {
        return -1;
      }
      return ebx >> 24;
    #else
      // give up, the caller can generate a random number or something.
      return -1;
    #endif
    }
    

    上面用宏区分了下,说到使用 sched_getcpu 会好很多,使用后面的 __get_cpuid 其实并不是推荐的,在 这个 comment 里面,RocksDB 团队也确认第一种方式会比第二种快十倍以上。然后我心里就咯噔了一下,是不是真的我们用了第二种方式。

    首先用 nm 指令看了下我们 fork 版本编译出来的 RocksDB 和直接原生的 RocksDB 的区别,看是否有 sched_getcpu 这个 symbol,悲催的发现我们的没有,这就大概能确认是这个问题了。

    然后直接使用 perf top 命令,进入到 PhysicalCoreID 函数,看汇编:

    其中,里面的 shr $0x18,%ebx 立刻吸引了我的注意,这根代码里面的 ebx >> 24 可是完全能对上的。然后直接使用 objdump 反汇编 RocksDB 库文件,找到函数的汇编代码:

    int PhysicalCoreID() {
     320: 55                    push   %rbp
     321: 48 89 e5              mov    %rsp,%rbp
    #if defined(ROCKSDB_SCHED_GETCPU_PRESENT) && defined(__x86_64__) && \
        (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 22))
      // sched_getcpu uses VDSO getcpu() syscall since 2.22. I believe Linux offers VDSO
      // support only on x86_64. This is the fastest/preferred method if available.
      int cpuno = sched_getcpu();
     324: e8 00 00 00 00        callq  329 <_ZN7rocksdb4port14PhysicalCoreIDEv+0x9>
      if (cpuno < 0) {
        return -1;
     329: ba ff ff ff ff        mov    $0xffffffff,%edx
     32e: 85 c0                 test   %eax,%eax
     330: 0f 49 d0              cmovns %eax,%edx
      return ebx >> 24;
    #else
      // give up, the caller can generate a random number or something.
      return -1;
    #endif
    }
    

    直接确认了这个问题。也就是我们并没有用到 sched_getcpu 这个函数。那么下一个问题就是为啥我们没用呢?

    因为我们现在使用的是 RocksDB CMakefile 来编译的,但判断是否使用 sched_getcpu 这个是前一段时间 CMakefile 才加入的,所以自然我们就悲催了。速度升级,然后在跑,使用 perf top 观察:

    看到了 __vdso_getcpu,也就是使用了更好的 sched_getcpu 了,问题解决了,但为啥 __get_cpuid 会慢成这样,我其实还不怎么清楚,可以后面关注一下相关的指令集。

    以后还是要跟紧上游,一些更新还是需要及时的 merge 的。另外,就是我们的 bench 测试需要更加的完善,之前一直关注 RocksDB 的写,这个反倒是忽略了。

    相关文章

      网友评论

        本文标题:RocksDB PhysicalCoreID 慢问题排查

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