概述
转载来自：https://www.2cto.com/database/201701/586258.html
紧急处理
第一: 先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果 非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务. 处理方法:
| 1 |
|
第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了. DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的. 限制单用户连接数在500以下. 如:
| 1 |
|
(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因) 另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数 innodb_stats_on_metadata=0
| 1 |
|
故障分析
注：一般mysql的配置文件都是初始配置好的，紧急处理的方法有可能不适用，这事就要分析突然产生高负载的原因有哪些？
分析思路：
| 1 2 3 |
|
htop、dstat 使用
epel源下载htop
| 1 2 3 |
|
htop是加强版的top，这里对其使用不错介绍
dstat常用命令
dstat -l -m -r -c --top-io --top-mem --top-cpu
tcpdump使用
抓包分析，默认mysql端口为3306
| 1 |
|
引用perl
| 1 2 3 4 5 6 7 8 9 10 11 |
|
使用strace 或 pstack查看具体进程状态
查看系统调用是否有问题，进程是否堵塞，是否有Broken pipe
| 1 |
|
pt-query-digest
分析mysql慢日志，查看哪些sql语句最耗时
| 1 |
|
总结： 有时候不需要全部操作就能找到问题的所在，这次故障中个人是通过show processlist找到不正常的连接，查看是从哪里连过来的，然后到特定的服务器上，查看指定的那个服务状态是否正常。
故障分析：后端API服务抛异常，导致一个SELECT频繁去执行，先重启后端API，然后分析报错，找相关人解决。
最后
以上就是优秀钢笔为你收集整理的MySQL 数据库高负载故障分析的全部内容，希望文章能够帮你解决MySQL 数据库高负载故障分析所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复