老王:最近我的MySQL数据库很慢.... 很忧伤,这可肿么办?
帅萌:老王,老王你莫心慌,听我跟你唠~
MySQL性能有问题,先应该关注的是慢查询日志(slow log)。
MySQL性能慢,多半是SQL引起的(慢查询日志会把执行慢的SQL,一五一十的记录下来,就像你的身体一样诚实..)需要根据慢查询日志的内容来优化SQL。
其次,除了MySQL慢查询日志,还需要更多的关注liunx系统的指标和参数。
top 命令帮你观察大橘(局)。
观察 load average 1分钟 、5分钟、 15分钟的平均负载值。
然后是us% 用户使用的CPU占比,如果us%太高,极有可能索引使用不当。
sy%系统内核使用的CPU占比,如果sy%太高,要注意MySQL的连接数和锁等信息。
wa% io使用CPU的占比,如果wa%太高,要关注MySQL是否使用了硬盘临时表,或者大量刷盘等操作,也有可能是硬盘太慢,或硬盘故障,可以使用iostat等工具来观察。
还需要关注各个逻辑CPU之前的负载是否均衡(可能是中断不均衡导致性能问题),可以使用mpstat命令来进行详细观察。
MySQL是数据库服务,不建议跟其他应用混跑。
其次是内存的使用信息,先通过free来观察。
要观察 是否使用了SWAP,剩余多少内存,是否发生内存泄漏。
说到SWAP,就要说到NUMA,通过numactl来观察NUMA的使用情况,建议关闭NUMA。至于为什么,建议阅读《NUMA架构的CPU -- 你真的用好了么?》 。
内存泄漏观察方法 buff/cache 和used 对比。 如果发生了内存泄漏,解决方案:
重启MySQL 。
升级到最新的小版本MySQL 。
还可以通过vmstat 来观察每秒的进程、内存、swap、io、cpu等详情情况。
然后要关注IO的使用情况,可以通过 iostat -x来观察,主要观察。
rrqm/s #每秒读取的扇区数。
wrqm/s #每秒写入的扇区数。
avgrq-sz #平均请求扇区的大小 。
avgqu-sz #是平均请求队列的长度。
await #每一个IO请求的相应时间。
%util #在统计时间内所有处理IO时间,除以总共统计时,暗示了设备的繁忙程度。
MySQL观察层面
主要关注tps、qps、并发连接数(Threads_connected)、并发活跃线程数(Threads_running)、临时表(tmp_disk_tables)、锁(locks_waited, Innodb_row_lock*)等指标。
关注当前是否有不良线程状态,例如:copyto tmp table、Creating sort index、Sorting result、Creating tmp table、长时间的Sending data等。
关注InnoDB buffer pool page的使用情况,主要是Innodb pages_free、Innodb wait_free两个 。
关注InnoDB的redo log刷新延迟,尤其是checkpoint延迟情况,并关注unpurge list大小。
关注innodb status中是否有long semaphore wait的情况出现。
观察是否有大事物的阻塞。
在观察MySQL运行状态方面,帅萌丢一个py脚本。写的时间久,迭代N个版本,不过这个版本很方便....(其他的在项目里拆起来有点费劲)。但是编程这方面越写越精,需要磨练,各位可以参考一下,相信你们会写的更棒。
如果实在看不懂的请联知数堂zizi老师,我负责挖坑,他负责教你会,带你飞。
还提供一个SOS.sh脚本,当性能遇到问题,可以根据实际情况进行修改,并自行把相关内容打包,以便探讨和交流。
(杨奇龙老师的图)
、##参考 知数堂-叶问(20181218)
、##感谢,有赞杨奇龙老师提供的帮助,以及图片支持。