【Mysql】主机cpu 之-sys使用率过高

最新推荐文章于 2025-10-12 19:05:42 发布
转载 最新推荐文章于 2025-10-12 19:05:42 发布 · 3.7k 阅读 · 6
文章标签：

#数据库 #数据结构与算法 #操作系统

本文分析了MySQL中InnoDB线程同步机制，特别是当sys CPU使用率过高时的情况。问题源于kernel_mutex全局锁在高并发下的冲突，以及频繁的malloc()调用导致的系统mutex竞争。大量线程在spin_lock上自旋等待，以及malloc()调用中的系统mutex_lock()和unlock()操作，加剧了上下文切换。解决方案包括检查内存分配不均（如NUMA问题）和使用strace进行诊断。
学习大神的http://mp.weixin.qq.com/s/hXtCzSnlVfo9Cq92538ipw自己整理一点思路
1.0top看cpu消耗,发现sys比usr要高不少，这非常不正常
  1. 如下

  4. 利用perf看sys cpu消耗，也就是内核态cpu在做什么

  6. sys cpu看来大部分都消耗在_spin_lock上。但是内核在很多对资源的申请和释放的时候都会通过spin lock对临界资源进行保护。需要进一步分析__spin_lock的来源。


1.1使用pstack看 MySQL所有线程的调用栈:

  1. root@localhost:~# pstack 18246

  3. 很多线程hang在了malloc()调用上,继续看
最低0.47元/天 解锁文章
cml2016
关注
分析sys高问题的方法总结
zhaoxin1989的博客
04-02 1708
分析sys高问题的方法总结，bpftrace，execsnoop-bpfcc，perf top，pidstat，ps -eo，top -b -d，trace，perfetto
linux 系统内如何查看当前CPU详细信息
weixin_42730667的博客
10-07 8806
linux 系统内可以通过sysfs 文件系统查看/sys/devices/system/cpu目录内当前所使用的cpu详细信息，不仅可以查到单核cpu，还可以查看多核cpu以及NUMA系统内的cpu信息，还可以查看每个cpu包含的cache详细信息，以便对代码进行进一步优化。 /sys/devices/system/cpu 该目录是cpu详细信息根目录： 首先看到/sys/devices/system/cpu/cpu<id>为命名的目录，代表该cpu有多少个cpu核数，每个cpu核有一个
CPU内存飙高，linux系统排查
cxn511的博客
09-29 2076
前段时间一直运行的模型因为访问量激增，突然出现了CPU内存翻倍无法自己下降的情况，必须重启服务器。虽然平时负责算法研发和移植工作多，但是自己一直对高性能系统都很感兴趣。所以当时除了配合服务端的人排查问题，也去请教了公司一直做后台开发的大佬，学习了一番。对于Linux系统，程序功能执行结束而内存一直无法释放，本质的原因是该程序的进程尚未结束。但Linux系统的内存管理其实是非常复杂的一个系统，当初系统内存回收机制的设计本身就是有一定的概率会找不到无用内存的。因此，当发现CPU内存飙高无法自降时，需要从代码以及
cpu瓶颈 top的内核sy占用较高
07-19 2406
反应服务器的应用连接较慢，由于应用和数据库在同一台服务器上。先从os上top查看下 [oracle@server115 ~]$ top -c top - 11:58:28 up 31 days, ...
服务器内核版本占用cpu,cpu瓶颈 top的内核sy占用较高
weixin_42508785的博客
07-30 2030
反应服务器的应用连接较慢，由于应用和数据库在同一台服务器上。先从os上top查看下[oracle@server115 ~]$ top -ctop - 11:58:28 up 31 days,1:53, 5 users, load average: 1.55, 1.51, 1.51Tasks: 247 total, 1 running, 226sleeping, 1 stopped, ...
MySQL限制CPU资源使用_使用 systemd 限制系统资源的使用
weixin_39975366的博客
02-19 906
文章目录[隐藏]简单介绍示例使用简单验证会话级别限制其它限制简单介绍在基于 Linux-3.x 内核版本的很多发行版都提供了 Systemd 来管理系统和服务. 同时也将 cgroup 功能加到了 slice, scope 和 service 三个单元中, 详见 sec-Default_Cgroup_Hierarchies. 基于这些特性我们可以很方便的通过 systemd 来限制服务或者进程对系...
MySql CPU激增原因分析
weixin_45448080的博客
04-19 1188
通过root登录数据库开启慢SQL查询日志，set global slow_query_log = ‘ON’，并设置慢SQL过滤时间set global long_query_time = 1（超过1秒视为慢SQL），指定慢SQL日志文件存放路径set global slow_query_log_file = ‘/var/lib/mysql/test_1116.log’。其中重点字段包括Comand 、Time 、State、Info,可以查看当前所有连接线程中命令、持续时间、状态、对应的SQL信息。
〖Python 数据库开发实战 - MySQL篇⑧〗- MySQL的配置文件与常用的配置方案
热门推荐
易编橙 · 终身成长社群，相遇已是上上签！
07-17 4万+
今天这一章节，我们来讲解一下 MySQL 的配置文件。既然开始写数据库的学习章节，就不能简单的讲一下 "增、删、改、查" ，再讲讲 "创建索引"、"回滚事务"等等。 学数据库就要学明白，毕竟将来是靠技术赚钱的。要学习明白怎么用，怎么配置，学懂学透彻了；当然了 MySQL 的配置有上百个，所以这里会挑选其中最重要的一些参数给大家介绍一下，其他的参数等到用到的时候再来介绍吧。...
AWS RDS MySQL 8 CPU飙升快速分析指南：从报警到解决
最新发布
探索云原生与智能化驱动下的安全运维新范式。关注DevSecOps、可观测性、AIOps等前沿领域，与您共赴技术前沿。
10-12 53
从宏观到微观，从现象到本质。通过AWS控制台快速定位方向，使用精准SQL查询深入分析，最终针对不同的问题模式实施相应的优化方案。记住，预防胜于治疗。建立完善的监控告警体系，定期进行性能评审，才能在问题发生前发现潜在风险，确保数据库的稳定高效运行。附录：常用命令速查-- 极简问题诊断（30秒快速检查）-- 检查数据库大小希望这份指南能帮助您在下次遇到RDS CPU问题时，能够从容应对，快速解决！
总结导致oracle数据库主机CPU sys%高的一些原因
Vic的博客
02-03 3471
今天我分享下简单总结导致oracle数据库主机CPU sys%高的一些原因。 在日常的数据库运维中，操作系统CPU使用率一直是我们衡量系统负载的一个比较贴切的指标，例如USER%可以更好的反馈数据库对CPU的使用情况，进而我们再次去数据库中找出导致CPU消耗高的源头，wa%可以反馈IO等待消耗的CPU时间百分比，当wa的值高时，可以说明IO等待比较严重。 然而，当CPU SYS%异常增高的时候，我们都知道是系统内核消耗了大量的cpu，但常常是束手无措。...
Linux如何查看哪个进程sys占用率最高？
luke_wang的专栏
12-08 1万+
使用top命令看到CPU usr占用只有0.5%，但sys占用超过11%。想知道是哪个进程/线程sys占用这么多。可以按以下步骤来分析： 1）按1 显示各CPU占用情况； 2）按f，然后按j，按Return，选择P 最后使用的CPU； 3）按H 显示线程； 4）按c 显示命令； 根据CPU#查看P列对应的命令。       参考：http://www.cnblogs.com/zhoug2...
一个内存碎片化导致系统SYS CPU利用率过高问题分析
lonely_geek的博客
10-22 2114
1、场景描述 生产机器pg_update升级进程完成后，调用postgres多进程进行SQL压测，发现性能大幅下降，SYS CPU占用很高 2、问题分析 1）机器共2个NODE节点，postgres基本都是跑在NODE1上，跑到后期，出现严重内存占用不均匀，NODE1上内存基本耗尽，NODE0还有不少内存。查看NUMA分配策略： 策略为默认策略，preferr...
记录一次 CPU sy 过高的排查经历
一七令
01-02 1万+
机器大概：这台机器是跑 PHP 的 4C 统计机器，同时可能会有多个进程在进行。 使用 Top 观察如下 %Cpu(s): 46.7 us, 35.6 sy, 0.0 ni, 17.7 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st 有一个很明显的现象 sy 占用很高，通常这个值要比较小才好。 Sy 定义： system : time running kernel processes。表示CPU在执行内核代码占用的cpu时间。 查了下相关的文章，主要都是说上下文切换导致的。
system占用cpu过高_慌了！系统CPU飙高和频繁GC，我要怎么排查？
weixin_39557373的博客
12-16 2083
来源：http://t.cn/EI9JdBu处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，...
Linux系统中CPU占用率较高问题排查思路与解决方法
liu_chen_yang的博客
04-21 1万+
文章目录前言方法一方法二案例分析场景描述解决过程解决办法总结 这篇文章主要给大家介绍了关于Linux系统中CPU占用率较高问题排查思路与解决方法，文中通过示例代码介绍的非常详细，对大家学习或者使用Linux具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧 前言 作为 Linux 运维工程师，在日常工作中我们会遇到 Linux服务器上出现CPU负载达到100%居高不下的情况，如果CPU 持续跑高，则会影响业务系统的正常运行，带来企业损失。 很多运维的同学遇到这种状况往往会不知所措，对于CPU过载
DSC集群压测解决SYS进程占比高的问题
liuguigeng56的专栏
02-09 1873
DMDSC集群压测解决SYS进程占比高的问题,达梦共享存储集群，达梦数据库spinlock进程占比较高问题处理。
top命令各个监控项的含义
01-06 1350
注意： us: 用户空间占用CPU百分比 —— 用户态程序发起的syscall消耗的时间也是算在us里面的，因为用户进程通过syscall陷入内核态，相应内核态代码会代表该用户态进程在内核态运行(并且有一个task_struct结构保存当前进程上下文)，所以，这段时间也是算在us里面。 sy: 内核空间占用CPU百分比 —— 指的是系统上下文切换的消耗，该监控项数值比较高，说明服务器开了太多的进程或者线程。 ...
关于cpu的分析--us,sys百分比代表什么
aican_yu的专栏
10-22 2488
top us 用户空间占用CPU百分比 sy 内核空间占用CPU百分比 ni 用户进程空间内改变过优先级的进程占用CPU百分比 id 空闲CPU百分比 wa 等待输入输出的CPU时间百分比 hi 硬件中断 si 软件中断   wa 数值高的话，一般是由io阻塞引起的。考虑数据库或文件读写有问题 在top下按1,显示逻辑cpu信息 Summar
CPU使用率过高问题排查及Linux之top命令用法详解
Maynor的博客
06-08 7136
公司连续2天服务器告警CPU使用率过高问题，查看日志无果，尝试使用top命令排查问题。
**如何监控MySQL的连接使用率和性能？**
06-04
<think>嗯，用户现在想了解如何监控MySQL的连接使用率和性能，看来他们之前已经询问过最大连接数的问题，现在想更深入地监控和管理数据库。用户引用了五篇资料，但核心需求很明确：需要实用的监控方法和工具推荐。从引用材料来看，用户可能是个数据库管理员或开发人员，正在寻找专业级的监控方案。引用1和3提到性能监控的重要性，引用2和4分别介绍了第三方工具和连接池监控思路，引用5则提供了索引监控的SQL语句。这些材料质量不错，但用户需要的是整合后的实操方案。在之前的回复中，我已经详细解释过max_connections的配置，现在需要延续这个专业深度。用户可能面临的实际场景是：数据库偶尔出现性能瓶颈，需要提前发现连接数不足或响应延迟的问题。他们真正的需求不仅是监控工具列表，更是如何建立完整的性能监控体系。从技术角度，这个问题可以拆解为三个层面：基础指标监控（如连接数、活动线程）、高级性能分析（如慢查询、锁竞争）和工具链搭建。特别要注意引用5提到的performance_schema，这是MySQL内置的强大工具，应该作为重点推荐。用户可能没意识到但同样重要的是：监控数据的解读和告警策略。比如Threads_connected接近max_connections时该如何处理，或者如何区分短时峰值和持续过载。这些实战经验需要整合进回答。关于工具推荐，考虑到不同用户的技术栈：中小企业可能更适合开源方案如Prometheus，而大企业可推荐ApplicationsManager这类商用方案（引用2提到它的深度监控能力）。连接池监控部分（引用4）需要单独说明，因为Java应用的连接池管理和数据库原生连接不是同一维度。需要特别强调时间序列数据的价值——比如用grafana展示连接数变化曲线，比单纯看数字直观得多。同时要提醒监控频率设置，过于频繁的采集可能影响数据库性能本身。</think> 监控MySQL连接使用率和性能需要结合**系统命令、内置工具、SQL查询和第三方工具**，以下是分步骤的实用方案： --- ### **一、核心监控指标** #### 1. **连接使用率** - **当前连接数**：`SHOW STATUS LIKE 'Threads_connected';` - **最大连接数**：`SHOW VARIABLES LIKE 'max_connections';` - **使用率计算公式**： ``` $$ \text{连接使用率} = \frac{\text{Threads\_connected}}{\text{max\_connections}} \times 100\% $$ ``` > 安全阈值：建议 ≤80%（超过需扩容或优化） #### 2. **连接状态分布** ```sql SHOW STATUS LIKE 'Threads_%'; -- 重点关注： -- Threads_running（活跃查询线程） -- Threads_created（历史创建连接数） -- Threads_cached（缓存中的线程） ``` #### 3. **连接来源分析** ```sql SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host; ``` --- ### **二、内置工具监控** #### 1. **`SHOW PROCESSLIST`** 实时查看连接状态和执行的SQL： ```sql SHOW FULL PROCESSLIST; -- 显示完整SQL（避免截断） ``` > 关键列：`Command`（如`Query`/`Sleep`）、`Time`（执行时长）、`State`（状态） #### 2. **Performance Schema** 启用后（需配置）可获取深度数据： - **连接池监控**（引用[4]思路）： ```sql SELECT * FROM performance_schema.threads; ``` - **索引使用率**（引用[5]）： ```sql SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage; ``` #### 3. **Sys Schema** 预置诊断视图（MySQL 5.7+）： ```sql -- 连接等待最多的主机 SELECT * FROM sys.host_summary_by_statement_latency; -- 慢SQL分析 SELECT * FROM sys.statement_analysis; ``` --- ### **三、第三方工具整合** #### 1. **Prometheus + Grafana** - **部署Exporter**：使用 `mysqld_exporter` 采集指标 - **关键Dashboard指标**： - 连接数时序曲线 - 活跃查询占比 - 每秒查询量（QPS） - 慢查询计数 #### 2. **Applications Manager**（引用[2]） - **深度监控能力**： - 自动预警连接池枯竭 - 事务锁竞争分析 - 复制延迟检测 #### 3. **Percona Monitoring & Management (PMM)** 开源方案提供： - **Query Analytics**：解析SQL执行计划 - **资源利用率关联**：CPU/内存与连接数的关联分析 --- ### **四、关键场景诊断** #### 1. **连接泄露** - **现象**：`Threads_created`持续增长，但`Threads_cached`不增加 - **定位**：检查长时间`Sleep`的连接： ```sql SELECT * FROM information_schema.processlist WHERE COMMAND='Sleep' AND TIME > 300; -- 5分钟以上空闲连接 ``` #### 2. **连接池过载** - **现象**：`Threads_running`持续接近`max_connections` - **优化**： - 调整`thread_cache_size` - 启用连接复用（如PHP的`pconnect`） - 检查应用侧连接池配置（引用[4]） --- ### **五、最佳实践建议** 1. **基线建立**：业务低峰期记录正常指标范围 2. **自动化告警**： - 连接使用率 >80% - `Threads_running` > 50% max_connections - 慢查询数突增 3. **定期优化**： - 每月分析索引使用率（引用[5]） - 清理不活跃账号（减少冗余连接） > 通过组合内置指标和可视化工具（如Grafana），可构建实时监控看板实现快速响应[^1][^2][^3]。 --- **相关问题**： 1. MySQL慢查询日志如何配置并分析性能瓶颈？ 2. 如何通过`EXPLAIN`优化高延迟SQL语句？ 3. 数据库连接池配置参数有哪些调优策略？ 4. Prometheus监控MySQL时需关注哪些关键指标？
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值