MySQL 数据库高负载故障分析

紧急处理

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

?

1

setglobal innodb_thread_concurrency=16;

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

?

1

setglobal max_user_connections=500;

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

?

1

setglobal innodb_stats_on_metadata=0;

故障分析

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

分析思路：

?

1

2

3

1、查看mysql的slow.log，看是否出现死锁，及其他报错

2、show processlist; 查看mysql都有哪些连接，判断这些connect是否正常

3、通过使用htop、dstat等命令查看负载高来源是CPU还是IO

htop、dstat 使用

epel源下载htop

?

1

2

3

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

 

yum install htop dstat -y

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

dstat常用命令

?

1

dstat -l -m -r -c  --top-io --top-mem --top-cpu

tcpdump使用

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

?

1

tcpdump -i eth0 -A -s 3000 port 3306 > /tmp/sql.log

引用perl

?

1

2

3

4

5

6

7

8

9

10

11

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

?

1

strace -p 22222

pt-query-digest

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

?

1

pt-query-digest db-slow.log

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

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