MySQL监控&性能瓶颈排查

当CPU长时间超过100%的时候该怎么办,
说说如何快速定位性能瓶颈?
top,vmstat,ps

1.服务可用性
2.服务性能
3.服务负载趋势

监控的意义&目的

业务/数据库服务是否可用
通过事务实时性能数据变化感知业务的变化
数据库性能变化趋势判断服务器资源是否足够

数据可靠性

业务数据是否可靠
服务可用，不代表数据就是正确的
有可能误操作删除数据，或者其他意外原因丢失数据
或者主从复制延迟，导致在从数据库无法读取到最新数据
通过模拟随机业务逻辑来验证数据可靠性

监控之关键指标

常规运行情况汇总
CPU：%user，%sys，%idle，%iowait，是否发生中断不均衡
内存：free，cached，swap，是否有内存泄漏和OOM
I/O：iops、吞吐、时延、利用率(%util)
网卡：吞吐、注意小包发送频率
mysqladmin ping 探活

sys占比user高,是哪里的问题?
除了vmstat、sar外，还有哪些趁手的硬件及操作系统层监控工具?

系统监控

常规工具
top、free、ps、df
sysstat(sar、vmstat、mpstat、iostat)、dstat、iotop
netstat、ethstatus、arping

其他工具
perf
pstack

硬盘容量观测
df -Th
df -i

datadir
sys root
sys tmp

脚本地址
https://github.com/zhishutech/mysqldba/blob/master/mysql-tools/dba_login.sh

· top
load avg不小，
CPU是主要的瓶颈、
可用内存还不少，
I/O负载暂时看不出来

什么情况下表示发生内存泄露了，怎么防范?

free -h
free -mt
free -gt

OOM=out of memory

[root@backup ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1460         180         668           8         610        1118
Swap:          2047           0        2047

free详解

used，已经使用的内存总量
free，剩余物理内存
shared，已废弃不用
buffers，写缓冲
cached，读缓冲
实际可再分配内存：used + free + shared + buff/cache

典型内存泄漏场景:
当buffers+cached总和远小于used时，发生内存泄漏的风险等级为“高”。
绝大多数,都是numa引起的内存溢出风险

available

当发现系统已经用到了swap，该怎么处理?
建议直接在bios层关闭

cpu消耗高的原因大概有几个 1)函数的运算 2)排序的进行 3)锁等待和争用

sar详解

-u，Report CPU utilization
-d，Report activity for each block device
-r，memory utilization statistics

[root@backup ~]# sar -u
Linux 3.10.0-693.el7.x86_64 (backup)    10/02/2022      _x86_64_        (2 CPU)

10:42:42 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:42:44 PM     all      0.25      0.00      0.00      0.00      0.00     99.75
10:42:46 PM     all      0.25      0.00      0.25      0.25      0.00     99.25
10:42:48 PM     all      0.25      0.00      0.25      0.00      0.00     99.50
10:42:50 PM     all      0.00      0.00      0.25      0.00      0.00     99.75
Average:        all      0.19      0.00      0.19      0.06      0.00     99.56

案例

1. swap  导致 sys高
2. 锁等待 导致sys高
3. 硬件中断
4. 短链接
5. 时间戳
热表 中有 timestamp 列, 参数文件配置了 time_zone=SYSTEM
高并发场景下 导致sys高

MySQL频繁的创建连接,短链接造成 sys高

[root@backup ~]# sar -d
Linux 3.10.0-693.el7.x86_64 (backup)    10/02/2022      _x86_64_        (2 CPU)

10:42:42 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
10:42:44 PM    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:42:44 PM  dev253-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:42:44 PM  dev253-1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00