SSD 下 MySQL IO 优化.pdfVIP

SSD 下的 MySQL IO 优化 一 目录 一 目录二 背景三 SSD 特性四 基于 SSD 的数据库优化五 A 项目 MySQL 主从关系图六 程序 切换 前调优6.1 修改系统 IO 调度算法6.2 修改 innodb_ io_capacity = 40006.3 修改 innodb_ max_dirty_pa es_pct = 256.4 修改 innodb_ io_capacity = 20006.5 修改 innodb_ io_capacity = 15006.6 关闭 innodb_adaptive_flushin 6.7 打开 innodb_adaptive_flushin 6.8 设置 innodb_ max_dirty_pa es_pct = 206.9 设置 innodb_ io_capacity = 1000七 程序切换 后调优7.1 设置 innodb_ max_dirty_pa es_pct = 30，innodb_ io_capacity = 15007.2 设置 innodb_ max_dirty_pa es_pct = 40，innodb_ io_capacity = 20007.3 分析八 小结九 参考 二 背景 在阅读这篇文章 前，读者需要注意的是，为了维护隐私，用 MySQL 服务器的 D 段代替 完整 IP，并且略去一些私密信息。 A 项目，因 I/O 出现规律性地剧烈波动。每 15 分钟落地一次，innodbBuffPoolPa esFlushed 参数监控波峰和波谷交替出现，磁盘 I/O 同样如此，并且 until 达到 100% 。经过排查，排除了触 发器、事件、存储过程、前端程序定时器、系统 crontab 的可能性。最终定位为 InnoDB 日志切换 ，但是否完全是日志造成的影响，还有待进一步跟踪和分析。 找到问题的可能所在，试图在 24 主库上做了如下调整： 关闭 Query Cache ；设置 InnoDB Lo 大小为 1280M；设置 innodb_ max_dirty_pa es_pct 为 30，innodb_ io_capacity 保持 200 不变。 做了如上调整以后，I/O 趋于平稳，没有再出现大的波动。 为了保险起见，A 项目方面决定采用配有 SSD 的机型，对主库进行迁移，同时对 24 的从库 27 进行迁移。待迁移完成后，在新的主库 39 上，针对 SSD 以及 MySQL InnoDB 参数进行优化 。待程序切换完成后，再次对针对 SSD 以及 MySQL InnoDB 参数进行优化。也就是说在上线前 后进行优化，观察 I/O 状态。 三 SSD 特性 众所周知，SSD 的平均性能是优于 SAS 的。SSD 能解决 I/O 瓶颈，但互联网行业总要权衡 收益与成本的。目前内存数据库是这个领域的一大趋势，一方面，越来越多的应用会往 NoSQL 迁移。另一方面，重要数据总要落地，传统的机械硬盘已经不能满足目前高并发、大规模数据的 要求。总的来说，一方面，为了提高性能，尽可能把数据内存化，这也是 InnoDB 存储引擎不断 改进的核心原则。后续的 MySQL 版本已经对 SSD 做了优化。另一方面，尽可能上 SSD。 SSD 这么神秘，接下来我们看看它有哪些特性： 随机读能力非常好，连续读性能一般，但比普通 SAS 磁盘好；不存在磁盘寻道的延迟时间， æ´å¤ç²¾å½©æ»ç¥è®¿é® 1 随机写和连续写的响应延迟差异不大。erase-before-w rite 特性，造成写入放大，影响写入的性能 ；写磨损特性，采用 Wear Levelin 算法延长寿命，但同时会影响读的性能；读和写的 I/O 响应延 迟不对等 （读要大大好于写），而普通磁盘读和写的 I/O 响应延迟差异很小；连续写比随机写性 能好，比如 1M 顺序写比 128 个 8K 的随即写要好很多，因为随即写会带来大量的擦除。 总结起来，也就是随机读性能较连续读性能好，连续写性能较随机写性能好，会有写入放大 的问题，同一位置插入次数过多容易导致损坏。 四 基于 SSD 的数据库优化 基于 SSD 的数据库优化，我们可以做如下事情： 减少对同一位置