针对innodb_flush_method参数的理解和对比测试(mycat+mysql)
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
二、测试结果
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的模式配置也是治标不治本)。
至于,生产环境如何设置一定要以压测结果为准,以实际效果为准,不能盲目信任经验值。
跟大家推荐一个学习资料分享群:747981058,里面大牛已经为我们整理好了许多的学习资料,有自动化,接口,性能等等的学习资料!人生是一个逆水行舟的过程,不进则退,咱们一起加油吧!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
HTTP Server Mock 从手工到平台的演变(二)
大家都知道,不管是 Web 系统、还是移动 APP,各自在与内部、外部系统之间进行数据交互时,大多数情况下都是依赖接口。在基于接口约定开发的模式下,依赖接口的产出时间如果延迟,将直接影响了整个研发调试的效率;如果不能对接口进行及早测试,那发现问题的时间就要被推迟了。既然双方约定了接口格式,为何不按照这个规范直接测试,何必在乎依赖接口什么时候产出,优先做到及早自测,后续只要替换接口联调通过即可。下面主要讲解基于 HTTP 协议的 API 接口模拟,从手工 Mock 到平台的演变过程。 遇到的问题 曾经遇到的困扰:在研发过程中接口调试对接难的问题: 场景一: 【需求阶段】Portal 前、后端约定基于接口开发 【开发阶段】前端开发完毕,后端接口尚未开发完毕,前端只能硬编码数据进行测试,造成接口对接调试延后,而且每次进行更多场景的数据调试,需要频繁重启服务、本地部署; 研发自测阶段无法及早开展,依赖接口约束大。 场景二: 【需求阶段】新功能开发,Portal 依赖计费的接口,双方约定基于接口开发(内部、外部依赖接口场景均通用) 【开发阶段】Portal 在开发进行中,计费尚未开发完毕,Por...
- 下一篇
回归网易 9 个月来的测试团队转型之路
在外游荡一年回到网易,进到平台交友事业部,专注于移动互联网 APP 研发测试领域,在将近一年来的时间里,经历了开发、测试团队的转型,下面跟大家讲述讲述带领测试团队从挖掘痛点的转型之路,希望能给各位一点帮助。 测试团队现状 这个部门人员朝气蓬勃,个人认为更像一个创业型的公司,初期技术资源都投入到产品功能需求开发中,对于产品质量稍作妥协,不需要太严格的过程控制和质量把控,相比开发资源而言,测试的投入资源不是那么急需。 随着用户量的上升,各种类型的移动设备问题错综复杂,用户对产品的质量有要求,部门老大对质量越来越重视,狠抓这块,从 2017 年 Q4、2018 年 Q1 分别招入两批测试人员,整个技术团队对于质量把控的诉求越来越强烈了,到后来整个测试团队跟随开发团队的规模壮大而壮大起来了。 测试技能现状 所有产品线的测试手段都是以手工测试为主,自动化辅助手段较少,回归测试成本高,Android、iOS 独占测试人员忙于业务的功能性需求的黑盒测试,非功能性需求无法满足。 Android、iOS 与后端 Server 进行数据交互的 API 规范定义是一致的,早期无相关测试人员参与,导致发现 A...
相关文章
文章评论
共有0条评论来说两句吧...