![MySQL 写入密集型设置,kjournald 执行大量 I/O](https://linux22.com/image/537854/MySQL%20%E5%86%99%E5%85%A5%E5%AF%86%E9%9B%86%E5%9E%8B%E8%AE%BE%E7%BD%AE%EF%BC%8Ckjournald%20%E6%89%A7%E8%A1%8C%E5%A4%A7%E9%87%8F%20I%2FO.png)
我在 Rackspacecloud 4Gb 节点上部署了 MySQL(实际上是 MariaDB 5.2)设置。所有表都是 InnoDB,InnoDB 缓冲池大小为 2G,大多数时候都处于 95% 满的状态。我使用 ext3 作为文件系统(不确定在云节点上是否可以用其他文件系统)。我的应用程序对两个统计表进行了大量写入。这两个表都有一个 auto_increment PK 和一个唯一索引。这些表每 10 分钟由 cron 作业清理一次。这个 cron 作业还会执行许多长时间运行的查询来处理原始统计数据。
问题是我不时会遇到很高的 I/O 峰值。看起来它们与 InnoDB 事务日志中的未检查点字节数有关。未检查点字节的平均数量为 18.6M,但当我看到这些峰值时,它会达到 80-90M。不确定是什么原因造成的。
Iotop 显示,当这些峰值出现时,kjournald 表现最佳。我使用“data=writeback”选项重新挂载了 FS,但无济于事,kjournald 仍然处于领先地位。我还尝试降低 swappiness 并增加根设备的队列/nr_requests,但这也无济于事。
我不知道下一步该做什么。我想知道为什么 kjournald 在只有元数据被记录的 FS 上会产生如此巨大的 I/O 负载。我应该尝试调整提交间隔吗?或者可能使用 ionice?
答案1
80-90米
它接近 EXT3 默认日志大小。看起来它已经满了,所以它开始刷新它。答案在很大程度上取决于你对这个文件系统一致性的关注程度,因为它要么给你很多选择,要么给你相当多的选择。
另外,如果这些统计表“每 10 分钟清理一次”,为什么不将它们放在内存中呢?