【OceanBase诊断调优】——hpet(高精度时钟源)引起的CPU高问题排查

最近总结一些诊断OCeanBase的一些经验,出一个【OceanBase诊断调优】专题出来,也欢迎大家贡献自己的诊断OceanBase的方法。

1. 前言

昨天在问答区帮忙排查一个用户CPU高的问题,帖子链接:《刚刚新安装的OceanBase集群,没有任何数据,CPU占用非常高,这正常吗?》,总结了一下诊断经验,供其他人参考。

2. 问题现象

集群创建完成,创建了一个租户,还未曾导入数据,就出现cpu居高不下的情况,如图是其中一个节点的

3. 适用版本

OBServer 2.x版本, OBServer 3.x版本, OBServer 4.x版本

4. 排查过程

  1. 用obdiag收集了一下cpu高场景的信息obdiag gather scene run --scene=observer.cpu_high,从其中的top.txt信息中看到内核态使用CPU过高。
补充知识:在 Linux 的 CPU 状态信息中发现,有"%us、%sy、%ni、%id、%wa、%hi、%si、%st"等状态。
● us:用户空间占用CPU百分比(Host.cpu.user)
● sy:内核空间占用CPU百分比(Host.cpu.system)
● ni:用户进程空间内改变过优先级的进程占用CPU百分比
● id:空闲CPU百分比(Host.cpu.idle)
● wa:等待输入输出的CPU时间百分比
● hi:硬件中断
● si:软件中断
● st:实时
  1. 使用 sudo perf top -p 命令采集到的数据如下图所示:

发现排在第一位置的是read_hpet, 占用了71.13%,而这个read_hpet是和时钟源相关的,有理由怀疑是时钟源导致的节点CPU高。

  1. 【扩展排查】通过perf图去看调用关系

可以手动抓取 perf 调用图分析热点函数,步骤如下:

# 生成 perf 调用图
sudo perf record -o perf.data -e cycles -c 100000000 -p $(pidof -s observer) -g -- sleep 20
sudo perf script -i perf.data -F ip,sym -f > data.viz

当然也可以直接用obdiag gather perf命令来执行一键收集,此处省略了perf数据生成图片的操作,感兴趣的可以去查perf官网的资料。

其中热点函数跟 perf top 的结果一致。

查询相关资料,发现在Linux操作系统上tsc是首选时钟源------因为它的开销低很多,而hpet作为后备时钟源。一个千万次事件计数的基准测试显示,TSC花费约0.6秒,而HPET花费略微超过12秒,ACPI电源管理计时器花费约24秒。

  1. 确认机器时钟源

    cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    hpet

问题集群的时钟源为hpet,OceanBase官网文档中推荐时钟源为tsc,当 OBServer 服务器使用 hpet 作为时钟源类型时,获取系统时间的开销会比较大,进而可能导致内核态 CPU 使用率高

5. 解决办法

方法一:临时切换时钟源

# 第一步,查看当前系统可用的时钟源(输出包含 tsc 方可执行第二步)
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

# 第二步,临时切换时钟源(重启后失效)
sudo bash -c 'echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource'

方法二:永久切换时钟源

如果可用时钟源列表中没有 tsc,也能生效,只要 CPU 支持 稳定tsc 特性即可(可通过执行命令 cat /proc/cpuinfo | grep constant_tsc 验证是否支持 ) 。

第一步,执行sudo vi /etc/default/grub。

在原配置行 GRUB_CMDLINE_LINUX 后面的参数值中追加参数设置 clocksource=tsc tsc=reliable clocksource_failover=hpet (表示启用 tsc 作为时钟源,如果 tsc 不可用则用 hpet 兜底)

# 将如上参数配置项修改为如下形式
# 如果之前已经有 clocksource 等参数的,就直接替换
GRUB_CMDLINE_LINUX="原参数设置 clocksource=tsc tsc=reliable clocksource_failover=hpet"

第二步,生成 grub.cfg 文件

grub2-mkconfig -o /boot/grub2/grub.cfg

然后重启系统,以便设置生效。

可通过如下命令行验证当前的时钟源是否修改成功:

# 查看 当前系统的时钟源
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

参考文档:https://repost.aws/zh-Hans/knowledge-center/manage-ec2-linux-clock-source

6. 后续Action

obdiag已收纳该场景的需求,巡检项会在即将发布的obdiag 2.1.0 中带上。CPU场景的经验也会沉淀到obdiag的代码中,敬请期待。

7. 附录

相关推荐
颇有几分姿色17 分钟前
深入理解 Linux 内存管理:free 命令详解
linux·运维·服务器
AndyFrank1 小时前
mac crontab 不能使用问题简记
linux·运维·macos
筱源源1 小时前
Kafka-linux环境部署
linux·kafka
算法与编程之美2 小时前
文件的写入与读取
linux·运维·服务器
长弓三石2 小时前
鸿蒙网络编程系列44-仓颉版HttpRequest上传文件示例
前端·网络·华为·harmonyos·鸿蒙
xianwu5432 小时前
反向代理模块
linux·开发语言·网络·git
follycat2 小时前
[极客大挑战 2019]HTTP 1
网络·网络协议·http·网络安全
Amelio_Ming2 小时前
Permissions 0755 for ‘/etc/ssh/ssh_host_rsa_key‘ are too open.问题解决
linux·运维·ssh
banjin2 小时前
Oceanbase学习之一迁移mysql数据到oceanbase
oceanbase
OceanBase数据库官方博客3 小时前
云集电商:如何通过 OceanBase 实现降本 87.5%|OceanBase案例
oceanbase·分布式数据库·实践经验·架构选型·大存储降本