在搞Oracle数据库优化的时候，虽然分析复杂问题也挺头痛的，不过Oracle的各种工具以及丰富的可观测性接口总能让人觉得分析问题有一种酣畅淋漓的感觉。本人在Oceanbase上也是一个新手，再加上在网上的OB运维经验与运维知识也不如Oracle丰富，因此对于复杂问题的分析总觉得有点力不从心。
最近一直在做D-SMART OB专版的发版前的冲刺工作，我觉得如果利用D-SMART如果无法把这个问题解决掉，就无法体现知识自动化的能力，因此我还是想找个时间利用工具链去排查一下系统存在问题的原因。
前天上午想给实验室的OB加点压，从采集一些TOP SQL来测试SQL审计的功能。启动压力测试后发现TPMC居然只有400多，往常这个脚本起码能跑倒3-4万。通过D-SMART简单分析了一下，发现半夜2点多开始的merge还没完，因此就简单的把问题归结为MERGE的问题了。中午吃完饭回来发现Merge结束了，不过OB集群的性能还是不好，看来我以前的猜测并不准确。于是我又发起了一个Merge操作，在OCP上看到MERGE持续进行，不过依然很慢。
图片
从D-SMART的“OB合并情况分析工具”可以看到确实有两个任务正在进行MERGE。不过再往下分析就遇到了问题。
图片
查看当前merge任务明细的时候，发现数据是空的，找不到正在进行的Merge工作。118节点上的MERGE操作一直处于等待状态，长时间没有任何变化。因为手头还有其他 事情，所以就没有持续跟进了。昨天早上到公司发现那个持续时间很长的MERGE完成了，从OCP上查看，发现MERGE总共做了13个小时。
图片
我也把我的问题发到了一个Oceanbase交流的群里，咨询了一些OB的资深用户，在他们的指导下我检查了一些性能视图，不过我看到这些视图都是空的，还是无法定位问题。不过通过和他们的交流，我逐渐缩小了分析问题的范围。终于把问题定位到了日志流复制不同步的问题上了。当某个日志流不同步的时候，实际上MERGE在等待日志同步完成，因此看不到当前Merge线程的工作内容，但是线程还是处于run状态。如果这个日志流日志同步了，那么在GV$OB_TABLET_COMPACTION_PROGRESS就可以看到MERGE线程在干活了。
图片
至此，这个问题已经能够定位到日志流同步延时导致了MERGE的问题，不过实际上这个问题还是没有解决，因为哪怕日志流同步了，Merge完成了，还是无法恢复系统的性能。
图片
确实，针对这个情况如果不解决日志流追了13小时才追平的问题，应该是无法解决当前这个性能问题的。于是我仔细思考了整个故障的过程。因为性能问题持续存在，所以只要系统加压一段时间，日志流同步的问题一直存在。经过多次测试，我发现总是118节点出现日志流不同步的问题，其他节点并没有出问题。这三个节点的PC SERVER配置是完全相同的，而且也并没有哪个服务器的负载有问题。
图片
图片
从目前的情况看，只能继续分析三个节点的操作系统有何不同了。通过D-SMART的操作系统诊断工具发现，118服务器的sys%经常会比较高，压测一旦开始就超过20%，其他节点都很正常。这是一个十分明显的疑点，不过到此为止我们的工具已经无法继续往下提供下钻能力，必须依托操作系统的工具了。在这种情况下，perf是一个十分好的分析工具，它可以提供的内核调用情况可以很好的分析sys cpu较高的问题。
图片
perf top命令的输出展现在我面前的时候，我就恍然大悟了。acpi_pm_read，这个最近一直困扰我的系统调用，一下子就激活了我的大脑-这应该是clocksource的设置问题。
图片
主机时钟源日检告警我以前是看到过的，只不过没有和这个性能问题挂钩而已。实际上D-SMART的日检已经给了我这个问题的答案，只是我没有去关注它而已。
图片
根据上面的分析过程，我们重新梳理了诊断工具。通过“查询合并情况”工具进入诊断。
图片
针对正在进行合并的作业，点击“合并信息”可以下钻查看当前正在做哪些合并工作。
图片
如果下钻进去发现当前并没有正在进行合并的对象，那么说明当前的合并作业正在等待什么前置条件。日志流同步是一种常见的可能原因。
图片
点击下钻可以看日志流同步的情况，如果向系统存在性能问题的时候一样，日志流确实处于异步状态，那么就可以继续下钻去分析当前系统clocksource设置的情况。
图片
至此整个分析实现了一个闭环。完成工具的优化后，整个分析过程似乎又找到了一点当年分析Oracle故障时的流畅感觉。
图片
通过D-SMART内部的一个应用访问性能探针指标可以看到优化前后十分明显的效果。底下那根曲线是今天早上的，而那根波动十分明显的曲线是两天前系统存在问题的时段，比对时段系统都是没有任何负载的。
图片
现在来复盘这个问题似乎整个查找过程十分流畅，但是在实际解决这个问题的过程中是不连贯的。这种不连贯来自于两方面的原因，一方面是因为OB的性能分析，故障诊断的知识的缺乏。当OB数据库出问题的时候，缺少能够指导我们一点点排查问题的工作指南，甚至很多OB的性能问题，OB原厂的同学都没有遇到过或者总结分析过，因此很多问题就变得很神秘了。
另外一方面原因是OB的等待事件的可观测性太差了。大家可以看到上面的那个等待事件是系统存在性能问题时采集到的，下面的等待事件是我正在写这篇文章时采集到的的。
图片
从二者我们无法看出明显的区别，因此我们也无法通过等待事件来缩小问题分析起点时的排查范围。Oracle数据库的等待事件做得很优秀，遇到系统问题，我们一般先看等待事件，就可以大致明确方向，缩小分析范围，很快步入正轨。正是因为OB的等待事件还不够完善，导致了其实用性远没有Oracle的好，因此问题分析的入口就变得更为复杂了。希望OB的同学能够在后续的版本中加速优化等待事件。
最后要和大家分享的就是关于时钟源的事情，对于单机数据库，时钟源可能也会引起一些性能问题，不过绝对没有分布式数据库那么明显。因为分布式数据库多节点的时间协调更为频繁。因此要确保所有的数据库服务器、复制服务器、连接数据库的中间件服务器等都是用相同的时钟源的。而对于目前最常见的三种时钟源：tsc、hpet、acpi_pm，tsc是首选，acpi_pm是最差的选择。一般情况下，在使用分布式数据库的时候，这些服务器的时钟源必须都设置为tsc。
图片
昨天我表示要关于这个问题写一篇文章的时候，讯飞的戴明明老师给我发来一个他们的经验，也是与OB的时钟同步相关的，当OB数据库的服务器节点的时钟同步存在问题的时候，在OCP中添加主机因为OCP服务器与需要添加的主机之间时钟不同不问题，导致任务失败。配置ntp统一时钟后，问题才消失。当时钟源设置不统一的时候，时钟同步问题是持续存在的，戴老师遇到的这个问题在这种情况下也会遇到。
时钟同步问题与时钟源问题不仅对OB是十分重要的，对于其他分布式数据库依然重要。对于今后要使用分布式数据库的同学，建议用小本子记下我今天分享的这个案例。
