首先在sql中查询计划事件的状态:SHOW VARIABLES LIKE 'event_scheduler'
成都创新互联公司,为您提供网站建设、成都网站制作、网站营销推广、网站开发设计,对服务封阳台等多个行业拥有丰富的网站建设及推广经验。成都创新互联公司网站建设公司成立于2013年,提供专业网站制作报价服务,我们深知市场的竞争激烈,认真对待每位客户,为客户提供赏心悦目的作品。 与客户共同发展进步,是我们永远的责任!
如果返回的是off表示当前是关闭状态,如果是on当前已经开启了计划任务。
在mysql程序的目录下找到my.ini文件,添加一个项:event_scheduler = 1
保存后重启mysql服务即可,重启服务可以在服务管理里面找到
也可以用脚本来实现:
mysql event_scheduler
开启event_scheduler sql指令:
SET GLOBAL event_scheduler = ON;
SET @@global.event_scheduler = ON;
SET GLOBAL event_scheduler = 1;
SET @@global.event_scheduler = 1;
相反,关闭event_scheduler指令:
SET GLOBAL event_scheduler = OFF;
SET @@global.event_scheduler = OFF;
SET GLOBAL event_scheduler = 0;
SET @@global.event_scheduler = 0;
1、进入数据库
MySQL use cpc;
Database changed
2、输入 show events\G; 指令;
mysql show events\G;
现象是,系统里的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’输出)如果在做重复的操作过程中一直保持稳定增长,那么一定有内存泄露