MYSQL 内存排查

Posted 2023-04-11

参考技术A 1.查参数配置

目前积累的使用经验中，存储过程&函数&触发器&视图 在mysql场景下是不适合的。性能不好，又容易发现内存不释放的问题，所以建议尽量避免.

2.存储过程&函数

3.视图

4.触发器

5.1 总内存使用

5.2 分事件统计内存

5.3 账号级别统计

5.4 线程对应sql语句，内存使用统计

5.5 打开所有内存性能监控，会影响性能，需注意

5.6 系统表内存监控信息

6.top 命令

8.ps命令

9.pmap 命令
pmap是Linux调试及运维一个很好的工具，查看进程的内存映像信息

用法1：执行一段时间记录数据变化，最少20个记录，下面69265是MySQL pid

用法2：linux 命令pmap MySQL pid导出内存，下面69265是MySQL pid

RSS就是这个process实际占用的物理内存。
Dirty: 脏页的字节数（包括共享和私有的）。
Mapping: 占用内存的文件、或[anon]（分配的内存）、或[stack]（堆栈）。
writeable/private：进程所占用的私有地址空间大小，也就是该进程实际使用的内存大小。

1.首先使用/top/free/ps在系统级确定是否有内存泄露。如有，可以从top输出确定哪一个process。

2.pmap工具是能帮助确定process是否有memory leak。确定memory leak的原则：writeable/private (‘pmap –d’输出）如果在做重复的操作过程中一直保持稳定增长，那么一定有内存泄露

MySQL数据库运维之主从复制延迟问题排查

上篇文章介绍了单机环境下的MySQL主从异步复制和主从半同步复制的搭建过程。搭建过程很简单，但是在实际使用过程中，更多的是解决问题，本篇文章将介绍一下MySQL主从复制中常见的问题以及如何定位问题和如何解决问题。

一、从库复制延迟问题

1、可能的原因如下
（1）主从服务器处于不同的网络之中，由于网络延迟导致；
（2）主从服务器的硬件配置不同，从服务器的硬件配置（包括内存，CPU，网卡等）远低于主服务器；
（3）主库上有大量的写入操作，导致从库无法实时重放主库上的binlog；
（4）主库上存在着大事务操作或者慢SQL，导致从库在应用主库binlog的过程过慢，形成延迟；
（5）数据库实例的参数配置问题导致，如：从库开启了binlog，或者配置了每次事务都去做刷盘操作；

2、主从同步延迟问题判断
（1）根据从库上的状态参数判断

在输出结果中找到Seconds_Behind_Master参数，这个参数表示的是从库上的IO线程和SQL线程相差的时间，然后根据该参数值判断，这个值只是初步判断，不能由这个值来下结论，有如下几种情况：
a、0：表示无延迟，理想状态；
b、NULL：表示从库上的IO线程和SQL线程中，有某一个线程出现问题，可以再次查看Slave_IO_Running和Slave_SQL_Running的值是否都为Yes；
c、大于0：表示主从已经出现延迟，这个值越大，表示从库和主库之间的延迟越严重；
d、小于0：这个值在官方文档中没有说明，通常不会出现。如果出现，那恭喜你中奖了，撞见MySQL的bug了；

（2）根据主从库上面当前应用的二进制日志文件名称或者重放日志的位置来判断
① 同时打开两个MySQL的命令行窗口，分别打开主库和从库，在第一个窗口上执行查看主库当前状态的命令

② 在第二个从库的命令行窗口执行如下命令

③ 比较从库上的Master_Log_File和Relay_Master_Log_File文件之间是否有差异
a、如果有差异，则说明主从延迟很严重；
b、如果没有差异，则比较Read_Master_Log_Pos和Exec_Master_Log_Pos的差异，这俩参数分别表示从库当前读取到的主库的二进制日志文件位置点和已经执行到的位置点；
c、如果上述输出都没有差异，可以通过主库上"show master status"和从库上"show slave status"的结果作比较。主要比较主库的"File"和从库的"Master_Log_File"，主库上的"Position"和从库上的"Read_Master_Log_Pos"；

3、主从延迟解决办法
（1）判断是否由于网络导致
方法：测试主从库之间的网络延迟，比如测试ping延迟。同时可以检查主从同步的时候是否使用了主库的域名来同步，而域名解析速度可能会特别慢。或者使用其他测试工具；
（2）判断是否由于硬件环境导致
方法：确认主从库的硬件配置是否相差较大，如果配置参数相差较大，可以排查从库上的CPU，内存，IO使用率来判断是否因为硬件配置导致；
（3）判断是否在主库上有大量的DML操作
方法：可以再主库上通过"show full processlist"命令查看当前正在执行的sql，查看是否有大量正在执行的SQL，或者观察主库的CPU和内存使用率，判断是否有高并发操作；
（4）判断是否有慢SQl，可以再主库上临时打开慢SQL记录，临时打开方法如下

（5）检查从服务器参数配置是否合理
① 查看从库是否开启了binlog日志，从库上执行如下命令查看

如果开启了binlog日志，而且从库未充当其他库的主库时，可以将从库上的binlog关闭，否则会增加从库负担，每次重放完成主库的binlog还要记录到自身的binlog

② 查看从库上的sync_binlog参数的值，这个参数表示的是事务提交多少次之后，由MySQL来将binlog_cache中的数据刷新到磁盘，有以下几种值：
0：表示事务提交之后，MySQL不做刷新binlog_cache到磁盘的操作，而是由操作系统来定时自动完成刷盘操作，这种操作对性能损耗最少，但是也最不安全；
n：表示提交n次事务之后，由MySQL将binlog_cache中的数据刷新到磁盘，如果开启，会对性能有一定程度的损耗。所以，从库上如果延迟很严重，可以考虑将该参数的值设为0；

③ 如果从库中要同步的数据库使用的是InnoDB存储引擎，可以查看innodb_flush_log_at_trx_commit参数。这个参数表示事务执行完成之后，多久的频率刷新一次日志到磁盘上，可用的值有如下几种：
0：表示MySQL会将日志缓冲区中的数据每秒一次地写入日志文件中，并且日志文件的刷盘操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作，效率最搞，但是安全性也比较低，可能会丢失数据；
1：每一次事务提交都需要把日志写入磁盘，这个过程是特别耗时的操作；
2：每一次事务提交之后，不会自动触发日志刷盘的操作，而是由操作系统来决定什么时候来做刷新日志的操作，在操作系统挂了的情况下才会丢失数据；
如果在主从延迟非常严重的情况下，可以将从库的该参数设置为0，以提高从库上重放主库二进制日志的效率。

注意：上述设计到修改MySQL数据库实例的操作中，修改之后会立刻生效，但是重启实例之后，会失效，如果要永久修改，则需要编辑mysql配置文件，然后重启。

至此，主从复制延迟的常见原因就介绍完毕，还有更多其他原因需要实际问题实际解决，此处并未提到，欢迎大家评论提出！下篇文章将介绍MySQL数据库的数据备份与恢复！

后续文章将更新在个人小站上，欢迎查看。