本文目录一览:
- 1、MySQL CPU占用过高怎么办
- 2、记一次mysql磁盘io高的问题排查
- 3、mysql中cpu负载很高,是什么原因
- 4、如何定位导致mysql服务器io压力大的进程
- 5、Mysql服务器负载很高,性能问题排查思路是怎样的
- 6、如何查看mysql io高的表
MySQL CPU占用过高怎么办
MySQL CPU占用过高原因主要有以下几种
CPU过时(比较旧的CPU)
RAM资源不足(RAM记忆体)
解决办法如下:
①临时解决方案
首先是ctrl+alt+delete快捷键打开工作管理员
然后找到下方图一中的mysqld.exe
右击移至详细资料
再来右击设定优先顺序
按照下方图二的步骤
根据占用情况调整成低于标准或者低
这个方法只能临时解决
②实际解决方法是更换CPU
总结:根据正常的mysql使用,即使大量数据往来也不会造成CPU占用过高,目前推论应该是CPU比较过时的原因,治标不治本的临时解决方案。
备注:如采取方案②你需要备份你的资料,因为更换CPU会有很大的机会需要重新安装你的作业系统。
记一次mysql磁盘io高的问题排查
现象是,系统里的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天前的日志记录
记录一下,希望对有需要的朋友也起一点提示
mysql中cpu负载很高,是什么原因
mysql中cpu负载很高,是什么原因
1、确定高负载的类型 htop,dstat命令看负载高是CPU还是IO
看具体是哪个用户哪个进程占用了相关系统资源,当前CPU、内存谁在使用
2、监控具体的sql语句,是insert update 还是 delete导致高负载
抓取mysql包分析,一般抓3306端口的数据 看出最繁忙的sql语句了
3、检查mysql日志
分析mysql慢日志,查看哪些sql语句最耗时
检查mysql配置参数是否有问题,引起大量的IO或者高CPU操作
innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要参数
4、检查硬件问题
如何定位导致mysql服务器io压力大的进程
1.你可以在root账户下,运行iostat,vmstat,查询看看。
分析磁盘IO,要用到两个命令:iostat 和 sar。
iostat -d -x 10 3
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
主要字段含义如下:
r/s 每秒读操作数。
w/s 每秒写操作数。
rsec/s 每秒从设备读取的扇区数量。
wsec/s 每秒向设备写入的扇区数量。
avgrq-sz I/O 请求的平均扇区数。
avgqu-sz I/O 请求的平均队列长度。
await I/O 请求的平均等待时间,单位为毫秒。
svctm I/O 请求的平均服务时间,单位为毫秒。
%util 处理 I/O 请求所占用的时间的百分比,即设备利用率。
#sar -pd 10 3
输出的主要字段含义如下:
DEV 正在监视的块设备
tps 每秒钟物理设备的 I/O 传输总量
rd_sec/s 每秒从设备读取的扇区数量
wr_sec/s 每秒向设备写入的扇区数量
avgrq-sz I/O 请求的平均扇区数
avgqu-sz I/O 请求的平均队列长度
await I/O 请求的平均等待时间,单位为毫秒
svctm I/O 请求的平均服务时间,单位为毫秒
%util I/O 请求所占用的时间的百分比,即设备利用率
Unix/Linux 系统磁盘 I/O 性能监控自动化脚本示例
2.用iotop可以看到是哪些进程IO占用高,不过需要2.6.20以上的kernel
Mysql服务器负载很高,性能问题排查思路是怎样的
对于包括 mysql 在内的大多数数据库系统而言
性能问题的排查主要有以下方向:
1. 需求的不合理造成的性能问题
比方说,不需要实时更新的内容,被要求做成实时更新
2. 架构的不合理造成的性能问题
比方说,不适合数据库保存的数据,被存放在数据库中
或者,频繁访问但是很少变更的数据,没有做缓存
3. 查询语句的不合理造成的性能问题
比方说,重复执行相同的 SQL 会造成资源浪费
或者,大量复杂的 join 语句会导致查询效率低下
4. 数据库设计的不合理造成的性能问题
比方说,盲目追求三范式、四范式,有时候并没有必要
5. 硬件配置的不合理造成的性能问题
比方说,数据库服务器的 io 性能、CPU 、网络状况,都会影响性能
以上这些都是性能问题定位和调优的方向
如何查看mysql io高的表
IO过高是指输入输出过高了这个有许多原因都会导致mysqlIO过高了,小编见过apache处理数据缓存导致mysqlIO过高问题当然也有其它关于mysql本身问题导致mysqlIO过高的问题了,下面给各位整理总结一下关于mysqlIO过高处理办法。
scriptec(2);/script
1、日志产生的性能影响:
由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。MySQL的日志包括错误日志(ErrorLog),更新日志(UpdateLog),二进制日志(Binlog),查询日志(QueryLog),慢查询日志(SlowQueryLog)等。当然,更新日志是老版本的MySQL才有的,目前已经被二进制日志替代。
在默认情况下,系统仅仅打开错误日志,关闭了其他所有日志,以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中,都至少需要打开二进制日志,因为这是MySQL很多存储引擎进行增量备份的基础,也是MySQL实现复制的基本条件。有时候为了进一步的性能优化,定位执行较慢的SQL语句,很多系统也会打开慢查询日志来记录执行时间超过特定数值(由我们自行设置)的SQL语句。
一般情况下,在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中,会该系统带来比较大的IO负担,而带来的实际效益却并不是非常大。一般只有在开发测试环境中,为了定位某些功能具体使用了哪些SQL语句的时候,才会在短时间段内打开该日志来做相应的分析。所以,在MySQL系统中,会对性能产生影响的MySQL日志(不包括各存储引擎自己的日志)主要就是Binlog了。
2、mysql内执行如下指令:
set global sync_binlog=500;
当每进行500次事务提交之后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
set global innodb_flush_log_at_trx_commit=2;
默认值1代表每一次事务提交或事务外的指令都需要把日志写入(flush)硬盘,这是很费时的。特别是使用电池供电缓存(Battery backed up cache)时。设置为2代表不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘,所以你一般不会丢失超过1-2秒的更新。设成0会更快一点,但安全方面比较差,即使MySQL挂了也可能会丢失事务的数据。而值设置为2只会在整个操作系统宕机时才可能丢数据。
注:重新开机后,该指令失效。可在服务启动时,设置如上两项。