我在 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 分钟清理一次”，为什么不将它们放在内存中呢？