MySQL优化班13期课后作业,20180911

7.1、当发现系统已经用到了swap,该怎么处理
7.2、不用监控系统,纯靠人肉,如何快速发现MySQL的性能瓶颈
已邀请:

aaron8219 - Oracle DBA

赞同来自:

7.1、你都用什么系统级工具监控呢?(swap的那题是上节课的吧,重复了^^)
CPU:
sar:监控cpu,磁盘,内存(很少用)
top:监控系统的整体负载(load average一般不超过5,w也可以直接查看),主要查看cpu的繁忙程度
perf top:perf调优套件中的一个命令,类似top,用于对系统的性能进行实时监控

内存:
vmstat:监控内存,swap,磁盘IO,cpu等使用率,比较全面监控工具
free:整体查看内存分配情况,可以作为判断是否有内存泄漏的依据(CentOS 6与7的判断方法略有不同)

磁盘IO:
iostat:监控磁盘使用率,估算IOPS值
iotop:监控由某些函数和系统调用引起的IO冲高
pt-ioprofile:可以打印与磁盘IO相关的信息

中断IRQ:
mpstat:监控CPU中断的调用情况,来判断是由哪些设备引发的性能问题

综合:
dstat:比以上几个更全面的监控工具,界面彩色显示较华丽,监控内容可根据指定参数自定义排序
nmon:AIX机器专用,可以监控cpu,内存,磁盘io等各种性能指标,并通过excel宏生成图表,很好用

7.2、不用监控系统,纯靠人肉,如何快速发现MySQL的性能瓶颈?
1)show processlist;
看总共有多少SQL在执行,执行时间是否过长。
重点关注state为以下几种:cleaning up,opening tables,sending data,statistics

2)show global status like '%thread%';
查看连接数,尤其是threads_running的数量,不宜超过CPU逻辑核数的1.5倍

3)show status like 'Innodb_buffer_pool_%';
计算innodb buffer pool命中率,如果比值很低,说明page经常被age out,性能不佳,可能是innodb_buffer_pool_size设置小了
公式:Innodb_buffer_read_hit_ratio=((1-Innodb_buffer_pool_reads)/Innodb_buffer_pool_read_requests)*100
Innodb_buffer_pool_wait_free的值如果很大,说明空闲page不够用,有性能瓶颈

4)show engine innodb status\G
主要关注以下内容:
last deadlock:如果间隔很近,说明业务中经常会出现死锁,频繁的死锁通常由高并发导致
History list length:如果值很大,说明有较多未被清理的update undo,业务存在大量更新或删除操作
Pages flushed up to: 如果和Log flushed up to以及Log sequence number的值相差很大,说明脏页刷新效率低下,有性能瓶颈
 

要回复问题请先登录注册