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