我有一个MySQL（实际上，MariaDB 5.2）安装在Rackspacecloud 4Gb节点上。 所有的表都是InnoDB，InnoDB的缓冲池大小是2G，大部分时间是95％。 我使用ext3作为文件系统（不知道我是否可以在云节点上使用其他任何东西）。 我的应用程序做了很多写入两个统计表。 两个表都有一个auto_increment PK和一个唯一索引。 这些表格每10分钟由一个cron工作清理。 这个cron作业还会处理一些长时间运行的查询来处理原始统计信息。
问题是，我不时得到高I / O尖峰。 看起来它们与InnoDB事务日志中的一些未检查字节有关。 未检测字节的平均数是18.6M，但是当我看到这些尖峰时，它达到了80-90M。 不知道是什么原因在这里。
Iotop表明，当这些峰值发生时，kjournald是最佳performance者。 我用“数据=回写”选项重新安装了FS，但没有效果，仍然排在最前面。 我也尝试减lessswappiness并增加根设备的queue / nr_requests，但这也没有帮助。
我不知道下一步该怎么做。 我想知道为什么kjournald只在元数据被logging的情况下在FS上产生如此巨大的I / O负载。 我应该尝试调整提交间隔吗？ 或者可能使用ionice？
80-90M
它接近EXT3默认日志大小。 看起来它已经满了，然后开始刷新它。 答案在很大程度上取决于你关心这个文件系统的一致性，因为它给你很多的select，或者很less的select。
另外，如果这些统计表是“每10分钟清洗一次”，为什么不记忆呢？