DTrace 的开发者之一 Brendan Gregg 目前正在 Linux 内核中开发基于 BPF 的性能分析工具，他总结了分析 Netflix 在将 Cassandra DBMS 从 CentOS 迁移到 Ubuntu 时遇到的性能问题所获得的经验。基于 Xen 的 Amazon EC2 云。 迁移后，CPU 负载增加了 30%，写入操作期间的延迟增加了大约相同的量。 事实证明，密集请求时间信息的应用程序的性能很大程度上取决于系统中选择的确切时间源。
起初，性能下降的原因并不明显，诊断开始于使用 top 和 execsnoop 实用程序监视持续运行或定期启动资源密集型系统进程可能产生的影响。 但一切都表明，资源消耗增加了，特别是在用 Java 编写的 Cassandra DBMS 中。 比较在 CentOS 和 Ubuntu 上并行运行的两个 Cassandra 进程处理相同查询的分析指标，结果表明总时间的大约 32% 花费在调用 os::javaTimeMillis() 上，该函数用于获取有关当前时间的信息。
此后，进行了一项实验，编写了一个简单的 Java 应用程序，在循环中调用 System.currentTimeMillis() 方法一亿次。 运行该应用程序显示，在 CentOS 上完成需要 13 秒，在 Ubuntu 上大约需要 68 秒，即慢5倍。 用 C 语言编写了一个类似的程序，该程序调用 gettimeofday() 函数一亿次，但在执行时，得到了类似的结果。
由于很明显问题的根源是返回当前时间的函数，因此在系统中选择不同的精确时间源时，注意力转向了指标的变化。 从“/sys/devices/system/clocksource/clocksource0/current_clocksource”的内容来看，在客户系统中运行Linux时，默认使用“xen”定时器。 将时间源更改为“tsc”后，Ubuntu中测试应用程序的执行时间从68秒减少到3.3秒，即它变得快了 20 倍。 此外，还对kvm-clock时间源进行了性能测试，结果显示与TSC相比延迟增加了20%。 $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ 时间 java TimeBench 真实 1m8.300s 用户 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ 时间 java TimeBench 真实 0m3.370s 用户 0m3.353s sys 0m0.026s
为了在选择 TSC 源时获取时间，使用 RDTSC 处理器指令，该指令的执行不需要系统调用（该指令不需要提升权限，并从 CPU 内置的时间计数器生成一个值）。 默认情况下，TSC 未激活，因为在过去，该源不排除逐渐时间漂移，而在其他处理器中，这种漂移是通过软件调整以获得更准确的读数。 据一位专门从事处理器开发的工程师称，对使用 TSC 时的时间偏移的担忧长期以来都是不真实的，在现代处理器中，该源可以产生稳定的读数多年。
将 Netflix 的生产服务器切换到 TSC 源后，写入延迟减少了 43%，并且使用 Ubuntu 实现的结果比运行具有“xen”时间源的 CentOS 的配置快 4 倍。 研究结果被转移到亚马逊，亚马逊官方建议在基于 Xen 虚拟机管理程序的 AWS EC2 环境中使用默认的 TSC 时间源（在基于 Nitro 虚拟机管理程序的环境中仍然建议使用 kvm-clock）。
来源： opennet.ru