MySQL 数据库高负载故障分析

时间：2022-02-25 23:40:01

紧急处理

第一: 先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果 非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务. 处理方法:

set global innodb_thread_concurrency=16;

第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了. DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的. 限制单用户连接数在500以下. 如:

set global max_user_connections=500;

(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因) 另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数 innodb_stats_on_metadata=0

set global innodb_stats_on_metadata=0;

故障分析

注：一般mysql的配置文件都是初始配置好的，紧急处理的方法有可能不适用，这事就要分析突然产生高负载的原因有哪些？

  • 分析思路：
1、查看mysql的slow.log，看是否出现死锁，及其他报错
2、show processlist; 查看mysql都有哪些连接，判断这些connect是否正常
3、通过使用htop、dstat等命令查看负载高来源是CPU还是IO

htop、dstat 使用

epel源下载htop

# rpm -ivh http://mirrors.aliyun.com/epel/epel-release-latest-6.noarch.rpm

yum install htop dstat -y

htop是加强版的top，这里对其使用不错介绍

  • dstat常用命令
dstat -l -m -r -c  --top-io --top-mem --top-cpu

MySQL 数据库高负载故障分析

  • tcpdump使用

抓包分析，默认mysql端口为3306

tcpdump -i eth0 -A -s 3000 port 3306 > /tmp/sql.log
  • 引用perl
tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | perl -e '
while(<>) { chomp; next if /^[^ ]+[ ]*$/;
if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER)/i) {
if (defined $q) { print "$qn"; }
    $q=$_;
    } else {
    $_ =~ s/^[ t]+//; $q.=" $_";
    }
}'

# 这里引用，找到最频繁的SQL语句
  • 使用strace 或 pstack查看具体进程状态

查看系统调用是否有问题，进程是否堵塞，是否有Broken pipe

strace -p 22222
  • pt-query-digest

分析mysql慢日志，查看哪些sql语句最耗时

pt-query-digest db-slow.log

总结： 有时候不需要全部操作就能找到问题的所在，这次故障中个人是通过show processlist找到不正常的连接，查看是从哪里连过来的，然后到特定的服务器上，查看指定的那个服务状态是否正常。

故障分析：后端API服务抛异常，导致一个SELECT频繁去执行，先重启后端API，然后分析报错，找相关人解决。
标签：

相关文章