189 8069 5689
现象是，系统里的java连接mysql超时了，
创新互联网站建设由有经验的网站设计师、开发人员和项目经理组成的专业建站团队，负责网站视觉设计、用户体验优化、交互设计和前端开发等方面的工作，以确保网站外观精美、网站建设、网站制作易于使用并且具有良好的响应性。
于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况
发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子
用mpstat查看cpu情况
好明显，都在等io
用iostat查看io情况，%util的值，一直在80%，99%之间变化
以为磁盘有问题，用dd测下速看看
从上面的结果看，也还好，没问题
以为可能磁盘有坏道，用下面命令也扫了一遍，没问题
结果也没有坏的块，这个过程，很耗时。
用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的
想看看mysql，研究写哪个文件时，最耗时的
从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下
我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了
清了之后，再用iostat查看
%util一下子就降下来了，用iotop查看mysql进程的io也下降了
cpu的iowait也下降了
定义一个事件，让mysql定时清理30天前的日志记录
记录一下，希望对有需要的朋友也起一点提示
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’输出）如果在做重复的操作过程中一直保持稳定增长，那么一定有内存泄露
最近接了一个锅,进入新公司接手了一个进入交付阶段的项目.在code review的时候发现很多问题,然后开始修复bug.
在测试阶段突然发现几乎所有涉及到更新的操作都失败,下面贴出异常信息.
第一次 出现的时候百度了一下,猜想可能是多服务部署资源冲突,重启服务故障消失.所以没有特别重视
第二次 出现的时候只有测试环境部署,不存在多机资源冲突的问题,猜想是多线程资源交叉导致的,于是给可能导致资源竞争的地方加上了分布式锁.
由于无法重现故障,所以并没有确认问题得到解决.
第三次 故障依旧,当发现问题依然存在的时候,开始认真反思,发现自己解决问题的思路明显有问题,过于片面,一直都只在应用层面寻求解决问题的办法,而且解决问题的方式也只是在尝试百度出来的方法.并没有去思考更深层的问题.
在Mysql5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；
INNODB_TRX ## 当前运行的所有事务
INNODB _LOCKS ## 当前出现的锁
INNODB_LOCK_WAITS ## 锁等待的对应关系
通过查询 INNODB_TRX 发现
当前事务中又两个RUNNING状态开始时间在一个小时之前
开始一直以为是锁表了
查看了 INNODB _LOCKS 事务信息之后发现有4行数据被锁住了一直没有释放
从这里开始发现问题了,应用已经抛了异常,事务理所当然的应该回滚才对,为什么资源依然没有释放,导致持续的阻塞呢?
其实最开始的异常信息就已经给出了答案,回到开始的地方,再看异常信息就很清楚了,应用里面的异常类是 MySQLTransactionRollBackException
是一个回滚异常, 这就说明在事务回滚的时候出了问题资源没有得到释放
然后开始查询 MySQLTransactionRollBackException 相关的信息
这个时候 innodb_rollback_on_timeout =0(默认配置)这个MySQL的配置开始进入我的视线,
举个栗子
事务在锁等待超时后是回滚事务内所有的statement还是最后一条语句；
0表示rollback最后一条语句，默认值； 有点坑爹啊( 细思极恐 )
1表示回滚事务内所有的statements；(此参数是只读参数，需在my.cnf中配置，并且重启生效；)
吃过一次亏,这次并没有盲目的相信百度到的信息
于是开始测试
一、验证innodb_rollback_on_timeout=off的情况
1.session A
开启事务,事务未提交,锁住id=1的数据
2.session B
开启事务,执行更新id=2的数据成功(事务未提交,锁住id=2),然后请求id=1等待锁超时,id=2的数据更改为222.
3.session C
请求id=2的数据50秒后显示等待锁超时
执行 SELECT * FROM information_schema.INNODB_TRX;
可发现有资源一直未释放,具体到测试数据中就是id=2的资源一直被锁定,线程一直被挂起.
总结:通过实验基本可以确定是业务资源交叉导致死锁之后资源没释放造成的持续阻塞，
二.验证innodb_rollback_on_timeout=on
修改配置后将验证innodb_rollback_on_timeout=off的步骤再走一遍
发现锁等待只能在业务层面尽量避免
on/off的区别在于session C进入时不会持续阻塞,session B异常后全部回滚