3

我 strace'd 一个触发大量内核时间的 java 进程以查看正在使用的系统调用，并且惊讶地看到它gettimeofday()并clock_gettime()占主导地位（我怀疑这是由于日志记录），考虑到这些man vdso状态，这很奇怪：

使用strace (1) 跟踪系统调用时，vDSO 导出的符号（系统调用）不会出现在跟踪输出中。

这些系统调用是怎么发生的？有没有办法避免它们？

该机器在 EC2 上运行 Ubuntu 16.04.1。

为了让事情变得更简单，我用 C ( testgtod.c) 创建了一个最小的测试程序：

#include <stdlib.h>
#include <sys/time.h>

void main(void)
{
    struct timeval tv;
    for(int i = 0; i < 1000; i++) {
        /* glibc wrapped, shouldn't actually syscall */
        gettimeofday(&tv, NULL);
    }
}

然后我在 strace 下编译并运行程序：gcc testgtod.c -o testgtod && sudo strace ./testgtod

尽管我的预期是，输出包括对 gettimeofday() 的一千次调用。

我测试的东西以确保我没有看到东西：

  1. 确保二进制文件是 64 位精灵使用file

  2. ldd ./testgtod确保 vDSO 处于活动状态：

    linux-vdso.so.1 => (0x00007ffcee25d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f6e161000) /lib64/ld-linux-x86-64.so.2 (0x0000559ed71f3000)

  3. getauxval(AT_SYSINFO_EHDR) != NULL

  4. gettimeofday(&tv, NULL)将调用替换为syscall(SYS_gettimeofday, &tv, NULL)，调用次数增加到 1000 万次，time在两种情况下运行时的行为都是相同的：./testgtod 0.16s user 0.83s system 99% cpu 0.998 total.

4

1 回答 1

5

该问题与在 Xen 上运行的 VM 有关，具体而言，Xen 时钟源还不允许 vDSO 访问时钟：

ubuntu@machine:~% cat /sys/devices/system/clocksource/*/current_clocksource
xen

然后，我将时钟源更改为tsc：

ubuntu@machine:~% sudo sh -c "echo tsc >/sys/devices/system/clocksource/clocksource0/current_clocksource"

注意：不建议移动到tsc生产机器上的时钟源，因为它可能会导致时钟向后漂移。

有关vDSO 和时钟源之间交互的详细文章，请参阅https://blog.packagecloud.io/eng/2017/03/08/system-calls-are-much-slower-on-ec2/ 。

注意 2：Xen 的支持似乎tsc在 4.0 版和 Sandy Bridge+ 平台中的 CPU 支持方面有所改进。现代 EC2 机器应该可以使用tsc. 使用 . 检查 Xen 版本dmesg | grep "Xen version"。tsc亚马逊已经在 re:Invent 2015 ( https://www.slideshare.net/AmazonWebServices/cmp402-amazon-ec2-instances-deep-dive )中推荐了时钟源。我还没有投入生产，但情况似乎并不像 packagecloud 所暗示的那么糟糕。

附加阅读：
为什么rdtsc与 VM 交互不佳
Xen 的 4.0 rdtsc 更改
Linux 内核计时文档，讨论 TSC 的陷阱

于 2017-03-06T12:41:48.307 回答