携程一次Redis迁移容器后的Slowlog“异常”分析

两个批次宿主机一样的内核版本，第一批没问题而第二批有问题，差异只可能在硬件上，非常有可能在计时上，翻看内核的commit log终于让我们发现了这样的commit，如图8所示：

图 8

该commit非常清楚指出，在4.9以后添加了一个宏定义INTEL_FAM6_SKYLAKE_X，但因为搞错了该类型CPU的crystal frequency会导致该类型的CPU每10分钟慢1秒钟。

这时再看看我们的出问题的第二批宿主机xeon bronze 3104正好是skylake-x的服务器，影响4.9-4.13的内核版本，宿主机内核4.10正好中招。

并且NTP每次同步间隔1024秒约慢1700ms，与slowlog异常完全吻合，而第一批次的机器CPU都不是SKYLAKE-X平台的，避开了这个BUG，迁移之前Redis所在的物理机内核是3.10版本，自然也不存在这个问题。至此，终于解开上面三个疑惑。

五、总结

5.1 问题根因

通过上面的分析可以看出，问题根因在于内核4.9-4.13之间skylake-x平台TSC晶振频率的代码BUG，也就是说同时触发这两个因素都会导致系统时钟变慢，叠加上Redis计时使用的gettimeofday会容易被NTP修改导致了本文开头诡异的slowlog“异常”。有问题的宿主机内核升级到4.14版本后，时钟变慢的BUG得到了修复。

5.2 怎么获取时钟

对于应用需要打点记录当前时间的场景，也就是说获取Wall-Clock，可以使用clock_gettime传入CLOCK_REALTIME参数，虽然gettimeofday也可以实现同样的功能，但不建议继续使用，因为在新的POSIX标准中该函数已经被废弃。

对于应用需要记录某个方法耗时的场景，必须使用clock_gettime传入CLOCK_MONOTONIC参数，该参数获得的是自系统开机起单调递增的纳秒级别精度时钟，相比gettimeofday精度提高不少，并且不受NTP等外部服务影响，能更准确来统计耗时(Java中对应的是System.nanoTime)，也就是说所有使用gettimeofday来统计耗时(Java中是System.currenttimemillis)的做法本质上都是错误的。

【编辑推荐】

1. 数据库运维的那些难题，我们用机器学习解决了
2. 12月数据库榜单，整体排名稳定如昨，Oracle 分数接连下降
3. 黑客攻击数据库的六大手段
4. 2018年12月全球数据库排行榜：Oracle惨不忍睹！
5. 如何正确使用Redis Streams？

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!