strace排查mysql单核飙高问题

本文探讨了一个MySQL实例在空闲状态下CPU占用率高达100%的现象。通过strace跟踪发现频繁创建临时表的问题,并最终定位到innodb_buffer_pool_size配置错误为根本原因。
部署运行你感兴趣的模型镜像

背景:发现新装的mysql空跑(除了prometheus监控),单核100%,比较奇怪……

使用strace看看到底发生了啥:

strace -o /tmp/strace_output.txt -T -tt -f -e trace=read,open -p 'mysql_pid'

查看输出文件:

153207 10:41:20.846346 open("/dev/shm/#sql_a7cd_2.MAD", O_RDWR|O_CLOEXEC) = 66 <0.000008>
153207 10:41:20.846620 open("/dev/shm/#sql_a7cd_2.MAI", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW|O_CLOEXEC, 0660) = 65 <0.000009>
153207 10:41:20.846958 open("/dev/shm/#sql_a7cd_2.MAD", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW|O_CLOEXEC, 0660) = 66 <0.000009>

发现的不停的有临时表被打开(strace玩的不熟,只能解读到这里),来来回回就这么点输出内容,看来真的是空跑啊

情况无比诡异。为啥会有临时表的创建…

root@[(none)] 04:13:08 >show variables like 'innodb_buffer_pool_size';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| innodb_buffer_pool_size | 5242880 |
+-------------------------+---------+

也是醉了,5M,再看下配置文件,果然,innodb_buffer_pool_size=64木有单位…

好吧~ 尘归尘土归土


学习链接:
1. binlog rotate引发的MySQL阻塞事件
2. Strace命令
3. 使用truss、strace或ltrace诊断软件的”疑难杂症”

您可能感兴趣的与本文相关的镜像

ACE-Step

ACE-Step

音乐合成
ACE-Step

ACE-Step是由中国团队阶跃星辰(StepFun)与ACE Studio联手打造的开源音乐生成模型。 它拥有3.5B参数量,支持快速高质量生成、强可控性和易于拓展的特点。 最厉害的是,它可以生成多种语言的歌曲,包括但不限于中文、英文、日文等19种语言

排查 CPU 使用率过导致系统响应缓慢的问题,通常需要从多个层面入手,包括系统级监控、进程分析、应用性能调优以及可能的外部资源依赖问题。以下是一个系统性的排查和解决流程: ### 3.1 系统级监控与初步诊断 首先,应使用系统监控工具获取当前 CPU 使用情况的全局视图。Linux 系统中可以使用 `top` 或 `htop` 实时查看各进程的 CPU 占用情况,也可以使用 `mpstat` 或 `vmstat` 获取更详细的 CPU 使用统计信息。 例如,使用 `top` 命令查看占用 CPU 最的进程: ```bash top ``` 也可以使用 `ps` 命令结合排序功能快速定位 CPU 占用进程: ```bash ps -eo %cpu,pid,comm --sort -%cpu | head ``` 通过这些命令可以快速识别出哪些进程正在消耗大量 CPU 资源[^1]。 ### 3.2 进程级分析 一旦发现某个或某些进程占用 CPU 较,下一步是深入分析这些进程的行为。可以使用 `perf`、`strace` 或 `gdb` 等工具进行系统调用跟踪和性能剖析。例如,使用 `strace` 跟踪某个进程的系统调用: ```bash strace -p <PID> ``` 对于 Java 应用程序,可以使用 `jstack` 获取线程堆栈信息,识别是否存在死循环、线程阻塞问题: ```bash jstack <PID> ``` 此外,`perf` 工具可以帮助识别热点函数,从而定位性能瓶颈: ```bash perf top -p <PID> ``` 这些工具可以帮助进一步确认是哪个函数或操作导致了 CPU 使用率升[^1]。 ### 3.3 应用层优化 对于应用层,常见的 CPU 使用率的原因包括: - **死循环或递归调用**:代码中存在逻辑错误导致无限循环。 - **频繁的垃圾回收(GC)**:在 Java 等语言中,GC 频繁触发可能导致 CPU 资源被大量占用。 - **算法复杂度**:未优化的算法可能导致计算资源浪费。 - **数据库操作未优化**:如 MySQL 中存在慢 SQL 查询,也可能导致 CPU 使用率升[^3]。 针对这些问题,应结合日志、性能分析工具(如 `JProfiler`、`VisualVM`)进行优化。 ### 3.4 内核与调度层面排查 在内核层面,CPU 使用率过可能与进程调度、中断处理、软中断(softirq)处理等有关。可以使用 `mpstat` 查看 CPU 各个部分(如 user、system、iowait)的使用情况: ```bash mpstat -P ALL 1 ``` 如果发现 `system` 占比较,可能与内核调度、系统调用频繁有关;如果 `softirq` 占比较,可能与网络或 I/O 操作频繁有关。此时应进一步分析软中断的类型和来源。 ### 3.5 系统资源竞争与外部依赖 有时 CPU 使用率并非由本地计算密集型任务引起,而是由于资源竞争(如锁竞争、线程阻塞)或外部依赖(如网络请求、数据库访问)导致线程频繁切换和等待。可以使用 `pidstat` 查看进程上下文切换情况: ```bash pidstat -w -p <PID> 1 ``` 如果发现上下文切换频繁,可能意味着存在线程调度或资源竞争问题。 ### 3.6 解决方案建议 - **优化代码逻辑**:修复死循环、减少不必要的计算、优化算法。 - **限制资源使用**:使用 `cgroups` 或容器限制进程 CPU 使用上限。 - **异步处理与并发控制**:合理使用线程池、异步任务处理机制。 - **数据库优化**:对慢 SQL 进行索引优化、减少全表扫描、使用缓存等。 - **升级硬件或横向扩展**:在资源瓶颈无法通过优化解决时,考虑增加 CPU 核心或部署负载均衡。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值