解决mysql占用IO过高

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只会在整个操作系统宕机时才可能丢数据。

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

时间: 2024-11-09 00:34:21

解决mysql占用IO过高的相关文章

解决Mysql占用cpu,内存高故障案例

故障: 晚上大概7点钟左右,收到播放中心投诉,说视频播放很慢,加载很久不出来.一开始,哥以为是tomcat服务又挂了.所以到tomcat服务器上查看下catalina.out输出日志.却没发现任务错误信息. 分析: 想了想,视频加载慢,会不会是数据库问题呢?果断上mysql数据库(从库)看下top如下:   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND    37258 mysql    20   0 17.

找出导致Mysql机器IO过高的SQL

近期一次mysql机器io过高导致入库缓慢,这里记录下解决和问题查找的过程. 首先通过top看到wa比较高,wa意思是CPU花在等待IO上的时间占比, 进而通过iostat -x 2看到如下图, rrqm/s:   每秒进行 merge 的读操作数目.即 delta(rmerge)/swrqm/s:  每秒进行 merge 的写操作数目.即 delta(wmerge)/sr/s:           每秒完成的读 I/O 设备次数.即 delta(rio)/sw/s:         每秒完成的

关于mysql占用CPU过高,问题解决

使用SHOW PROCESSLIST 查看 原因: 使用了 一个触发器 不断的去删除日志,保证每个用户的日志只有10条 去掉之后,CPU使用率从97% 降到了 17%. 利用show columns from 表名 查看 和 SQL 对比 查出 根本原因 : 删除条件里面 有一个 没有加索引,添加了索引后CPU在6%到40%波动,由于CPU单核,又加了很多触发器,所以去掉了这个 会频繁被触发的触发器. lower_case_table_names=1可以忽略表名大小写 SHOW VARIABLE

Linux服务器查看占用IO较高的进程

1.开启block_dump,此时会把io信息输入到dmesg中echo 1 > /proc/sys/vm/block_dump统计当前占用IO最高的10个进程:dmesg |awk -F: '{print $1}'|sort|uniq -c|sort -rn|head -n 102.测试完后,关闭block_dumpblock_dump参数echo 0 > /proc/sys/vm/block_dump

解决update-apt-xapi占用资源过高的问题

最近云主机出现了个报错,查看系统日志发现是update-apt-xapi任务占用资源过高,甚至内存占完了无法开辟内存 云主机:Ubuntu 14.04.5 LTS update-apt-xapi是干嘛的呢? 网上搜索出来,这个任务是系统用来更新内部资源包的,默认会自动在后台启动.主要是索引软件包的扩展数据,不是必要的系统依赖, 解决方案一: 建议直接卸载 sudo apt-get autoremove --purge apt-xapian-index sudo apt-get autoremov

【转】如何解决ensp 占用cpu过高问题

对于ENSP在开启模拟路由器后,cpu占用率高的问题,大家可以通过开启虚拟化技术来达到降低cpu占用率: 第一步,在BIOS中开启虚拟化技术: 一般最新的处理器和主板都支持虚拟化技术,所以您需要检查一下您的主板厂商是否支持并且要知道如何启用或禁用BIOS中的VT. 首先,开机时进入BIOS界面(各种机器的按键不同,有的是F10,有的是F1或者F2),然后,以我的机器为例,请按照下图进行设置: 第二步,打开VirtualBox管理器界面,选中AR_Base,单击 设置 按钮: 第三步,在AR_Ba

Mysql占用过高CPU时的优化手段

Mysql占用CPU过高的时候,该从哪些方面下手进行优化?占用CPU过高,可以做如下考虑:1)一般来讲,排除高并发的因素,还是要找到导致你CPU过高的哪几条在执行的SQL,show processlist语句,查找负荷最重的SQL语句,优化该SQL,比如适当建立某字段的索引:2)打开慢查询日志,将那些执行时间过长且占用资源过多的SQL拿来进行explain分析,导致CPU过高,多数是GroupBy.OrderBy排序问题所导致,然后慢慢进行优化改进.比如优化insert语句.优化group by

记一次性能测试:mysql占用磁盘IO过高 的解决过程

在一次性能测试时,发现mysql的cpu使用率不高,但是磁盘io很高, 一开始考虑是mysql的慢日志比较多,但是查看后发现慢日志并不多,而且只有一台mysql. 进入实例,查看sync_binlog变量 mysql> show variables like '%sync_binlog%' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 |

mysql占用服务器cpu过高的原因以及解决办法

排查方法 : > mysql -uroot -p      #登陆数据库 >********                    #输入数据库密码 mysql> show processlist; show processlist 命令详解: processlist命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句. +-----+-------------+--------------------+-------+---------+-------+--------