VC中文网-VC-MFC编程论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 607|回复: 1
打印 上一主题 下一主题

针对innodb_flush_method参数的理解和对比测试(mycat+mysql)

[复制链接]

14

主题

79

帖子

100

金币

团长

Rank: 10Rank: 10Rank: 10

积分
291

初来乍到小资新兵论坛好爱者社区QQ达人

跳转到指定楼层
楼主
发表于 2018-12-3 17:43:26 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
mysql的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、刷写模式,对这个参数,文档上是这样描述的:

有三个值:fdatasync(默认),O_DSYNC,O_DIRECT

默认是fdatasync,挪用fsync()去刷数据文件与redo log的buffer

为O_DSYNC时,innodb会使用O_SYNC体例打开和刷写redo log,使用fsync()刷写数据文件

为O_DIRECT时,innodb使用O_DIRECT打开数据文件,使用fsync()刷写数据文件跟redo log

首先文件的写操作包含三步:open,write,flush

上面最常提到的fsync(int fd)函数,该函数作用是flush时将与fd文件描述符所指文件有关的buffer刷写到磁盘,并且flush完元数据信息(好比修改日期、建立日期等)才算flush成功。

使用O_DSYNC体例打开redo文件暗示当write日志时,数据都write到磁盘,并且元数据也需要更新,才返回成功。

O_DIRECT则暗示我们的write操作是从MySQL innodb buffer里直接向磁盘上写。

这三种模式写数据体例具体如下:

fdatasync模式:写数据时,write这一步其实不需要真正写到磁盘才算完成(可能写入到操作系统buffer中就会返回完成),真正完成是flush操作,buffer交给操作系统去flush,并且文件的元数据信息也都需要更新到磁盘。

O_DSYNC模式:写日志操作是在write这步完成,而数据文件的写入是在flush这步通过fsync完成

O_DIRECT模式:数据文件的写入操作是直接从mysql innodb buffer到磁盘的,其实不消通过操作系统的缓冲,而真正的完成也是在flush这步,日志还是要经过OS缓冲





别离对这个三类模式进行对比测试:

一、测试条件

1、1000并发测试单表的增、删、改、查操作,测试表已经设置索引,基础数据量是一千五百多万条(未做分表分库)

2、测试环境:haproxy+2个mycat节点+3台mysql(第一台mysql为主节点,负责写,另外两台负责读)

mysql办事器配置:8G内存,8核1.80Ghz CPU

3、mysql优化后配置参数:

max_connections=2000

innodb_buffer_pool_size=4G

join_buffer_size=1M

sort_buffer_size=1M

thread_cache_size=8

innodb_buffer_pool_instances=8

innodb_page_cleaners=4

innodb_purge_threads=1 #使用零丁的清除线程按期回收无用数据的操作

innodb_max_dirty_pages_pct=90 #innodb主线程刷新缓存池中的数据,使脏数据比例小于90%

wait_timeout=300

###从节点增加如下配置

innodb_doublewrite=off

innodb_page_cleaners=8

innodb_read_io_threads=64

innodb_write_io_threads=64

read_buffer_size=1M

2、测试结果

1、datasync(默认),O_DSYNC这两种模式的磁盘IO比较高(只截取主节点mysql的监控图,因为两个从节点通过主节点同步数据,IO压力基本一致)









2、O_DIRECT模式的磁盘IO明显低了好多





这说明O_DIRECT模式是将数据直接从MySQL innodb buffer向磁盘写入,其写入磁盘的速度应该是会低于从操作系统buffer往磁盘写。

3、datasync(默认),O_DSYNC这两种模式的free内存下降很快(特别是datasync模式)









通过linux中查看,free内存减少,相应的cache就会增多,这与大量将数据写入到操作系统buffer中有关。





同时对比序号1中的磁盘IO转变情况图就发现,free内存越少,IO就越大,这与页交换频繁相合适(页换出越大,磁盘写入的压力越大):





4、O_DIRECT模式的free内存下降比较慢





5、对比其他测试结果如下:





从对比数据可以看出,O_DSYNC对CPU的压力最大,datasync次之,O_DIRECT最小;整体SQL语句措置性能和响应时间看,O_DSYNC都较差;O_DIRECT在SQL吞吐能力上较好(仅次于datasync模式),但响应时间却是最长的。

三、初步结论

终上结果做出阐发如下:

(1)在类unix操作系统中,文件的打开体例为O_DIRECT会最小化缓冲对io的影响,该文件的io是直接在用户空间的buffer上操作的,并且io操作是同步的,因此非论是read()系统挪用还是write()系统挪用,数据都包管是从磁盘上读取的;所以IO方面压力最小,对CPU措置压力上也最小,对物理内存的占用也最小;可是由于没有操作系统缓冲的作用,对数据写入磁盘的速度会降低明显(表示为写入响应时间的拉长),但不会明显造成整体SQL请求量的降低(这有赖于足够大的innodb_buffer_pool_size)。

(2)O_DSYNC体例暗示以同步io的体例打开文件,任何写操作都将阻塞到数据写入物理磁盘后才返回。这就造成CPU期待加长,SQL请求吞吐能力降低,insert时间拉长。

(3)fsync(int filedes)函数只对由文件描述符filedes指定的单一文件起作用,并且期待写磁盘操作结束,然后返回。fdatasync(int filedes)函数类似于fsync,但它只影响文件的数据部分。而除数据外,fsync还会同步更新文件的元信息到磁盘。

默认datasync模式,整体表示较好,因为充分利用了操作系统buffer和innodb_buffer_pool的措置性能,但带来的负面效果是free内存降低过快,最后致使页交换频繁,磁盘IO压力大,这会严重影响大并发量数据写入的稳定性。也就是说拥有了高性能,但不会有高稳定性(特别是mycat集群,在大量数据写入和各节点mysql数据同步压力下,IO是很大的)。为了解决这个问题,可以有个折中的体例,按时的对操作系统进行echo 3 >/proc/sys/vm/drop_caches,清理一下OS缓存,可以及时回收一部分内存(回收顺间对性能会有所影响)。

O_DIRECT模式网上一些评论认为是性能最好的,但本次测试的结果来看,性能其实不是很高,可是稳定性确实比较高,在大并发量读写操作中,能够较长时间运行,只是在第一次启动系统后测试,该模式一开始的响应时间确实比较长,到后面才恢复到较低水平(阐发的原因是因为有两个mysql节点酿成写模式了,可能重启mysql呈现读写状态转变,在做这个测试时由于开发人员还配了Galera,两节点同时写入是基于row级的,所以开始很容易引起锁,响应时间就变得很慢),如下所示:





总结:对mycat读写分手中,写数据压力小,读数据压力大的情况下,并且内存够大,innodb_buffer_pool_size配置够大的情况下,其实三种模式应该都行,读数据的性能基本是依赖于缓存,如果从稳定性和内存使用情况来考虑,用O_DIRECT模式会更好些,并通过优化查询以弥补响应时间不敷快的问题。对读写压力都很大或只是写的压力大的情况下,建议用datasync模式,并配上按期清理系统缓存的机制。如果我们充分应用了mycat的分表分库和读写分手机制,那么对整体系统的性能和稳定性都有帮忙(因为大库和大表,城市严重降低数据的写入和读出性能,这样的话光是靠innodb_flush_method的模式配置也是治标不治本)。

至于,生产环境如何设置一定要以压测结果为准,以实际效果为准,不克不及盲目信任经验值。

更多内容回复查看:
游客,如果您要查看本帖隐藏内容请回复
C VC C++ MFC 汇编 函数 脚本 辅助 多开 注入 内存 插件 破解 基址 窗口 大漠 绑定 编程 交流 论坛 实例 源码
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

VC中文网 - 豫ICP备14012807号|小黑屋|联系客服|金币冲值|VC中文网

GMT+8, 2019-11-20 07:44 , Processed in 0.273438 second(s), 30 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表
pk10投注技巧分享