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'的变量; …