RocksDB PhysicalCoreID 慢问题排查

最近测试的时候，发现了一个奇怪的现象，在一些机器上面，压力不高，但 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 的写，这个反倒是忽略了。