重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
直接用MYSQL库,肯定是阻塞方式的,就是说,你的SQL语句,网络传到服务器,服务器执行完,再把结果通过网络发回来,你调用的接口才会返回;所以,崩溃的话,肯定是自己代码有BUG的了,不会是异步导致的;
秀峰网站制作公司哪家好,找创新互联公司!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作,到程序开发,运营维护。创新互联公司成立于2013年到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
mysql有最大连接数设置,如果,没有关闭连接,会导致阻塞。
可以使用下面命令查看最大连接数:
show variables like '%max_connections%';
查看当前mysql连接数:
show processlist;
产生死锁的四个必要条件:
(1) 互斥条件:一个资源每次只能被一个进程使用。
(2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
(3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
(4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之
一不满足,就不会发生死锁。
现象是,系统里的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天前的日志记录
记录一下,希望对有需要的朋友也起一点提示