2
innodb_flush_method = O_DIRECT与O_DSYNC性能对具有LVM磁盘分区的ext3的影响
在我的一个生产环境中，我们有两个实例在RedHat集群上运行，并且一个生产实例与该集群相关联。 我们有125G主内存，instance1占用了24G InnoDB缓冲池，instance2占用了12G，这与RedHat集群无关。数据日志和事务日志都位于带有ext3文件系统的LVM磁盘分区上。 为了提高性能和提高I / O吞吐量，我决定更改innodb_flush_method为O_DIRECT。 参考MySQL文档： InnoDB数据和日志文件位于SAN上的位置，已发现将设置innodb_flush_method为O_DIRECT可以使简单SELECT语句的性能降低三倍。 提到高性能MySQL Ver 2和3，它指出InnoDB开发人员使用发现了错误innodb_flush_method=O_DSYNC。O_SYNC并且O_DSYNC类似于fsync()和fdatasync()：O_SYNC同步数据和元数据，而O_DSYNC仅同步数据。 如果所有这些看起来都像是在没有任何建议的情况下进行很多解释，则以下是建议： 如果您使用类似Unix的操作系统，并且您的RAID控制器具有备用电池的写缓存，则建议您使用O_DIRECT。如果不是，则默认设置或O_DIRECT将是最佳选择，具体取决于您的应用程序。 谷歌搜索，我得到这个基准测试报告：在O_DSYNCVSO_DIRECT 基准报告： =================== 1B行复杂事务测试，64个线程 * SAN O_DIRECT：读/写请求：31560140（每秒8766.61个） * SAN O_DSYNC：读/写请求：5179457（每秒1438.52） * SAN fdatasync：读/写请求：9445774（每秒2623.66） *本地磁盘O_DIRECT：读/写请求：3258595（每秒905.06） *本地磁盘O_DSYNC：读/写请求：3494632（每秒970.65） *本地磁盘fdatasync：读/写请求：4223757（每秒1173.04。 但是，O_DIRECT禁用OS级别的缓存，可以禁用双重缓存，这会显示出更好的I / O吞吐量。 O_DIRECT而不是一起去O_DSYNC好吗？这两个选项有些令人困惑。哪个选项可以显示出更好的I / O吞吐量并增强性能，而不会对数据，读/写（特别是在生产中）产生任何影响？根据您的个人经验有更好的建议吗？ 我可以在帖子中看到Rolando Update ： 这两个参数仍然有些混乱。在可以看到大多数使用的生产配置模板的地方O_DIRECT，没有任何推荐的地方O_DSYNC。 系统 MySQL 5.1.51-enterprise-gpl-pro-log 红帽企业Linux服务器5.5版 具有Raid Controller的DELL DRAC，具有电池写回缓存512MB Dell PERC控制器H700带有备用电池（BBU）。 附加信息 mysql>显示类似'innodb_thread_concurrency'的变量； …