MySQL 数据库高负载故障分析
紧急处理
第一: 先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果 非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务. 处理方法:
|
1
|
set
global
innodb_thread_concurrency=16;
|
第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了. DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的. 限制单用户连接数在500以下. 如:
|
1
|
set
global
max_user_connections=500;
|
(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因) 另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数 innodb_stats_on_metadata=0
|
1
|
set
global
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
|
yum
install htop dstat -y
|
dstat常用命令htop是加强版的top，这里对其使用不错介绍
|
1
|
dstat
-l -m -r -c --top-io
--top-mem --top-cpu
|
抓包分析，默认mysql端口为3306
|
1
|
tcpdump
-i eth0 -A -s 3000 port 3306 > /tmp/sql.log
|
|
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语句
|
查看系统调用是否有问题，进程是否堵塞，是否有Broken pipe
|
1
|
strace
-p 22222
|
分析mysql慢日志，查看哪些sql语句最耗时
|
1
|
pt-query-digest
db-slow.log
|
总结： 有时候不需要全部操作就能找到问题的所在，这次故障中个人是通过show processlist找到不正常的连接，查看是从哪里连过来的，然后到特定的服务器上，查看指定的那个服务状态是否正常。
故障分析：后端API服务抛异常，导致一个SELECT频繁去执行，先重启后端API，然后分析报错，找相关人解决。