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 的写,这个反倒是忽略了。

推荐阅读更多精彩内容