您的位置:

mysql服务器io负载较高,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只会在整个操作系统宕机时才可能丢数据。

注:重新开机后,该指令失效。可在服务启动时,设置如上两项。