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