分享

文件系统I/O与mysql相关参数关系

 redersun 2012-03-03
文件系统I/O与mysql相关参数关系

Linux的文件I/O是如何工作的?

一般的文件I/O操作的三个过程open、write、fdatasync,分别是打开文件、写文件、flush操作(将文件缓存刷到磁盘上)。

一、Open阶段

open("test.file",O_WRONLY|O_APPDENT|O_SYNC))

系统调用Open会为该进程一个文件描述符fd【附录2】。这里使用了O_WRONLY|O_APPDENT|O_SYNC打开文件:

  1. O_WRONLY表示我们以"写"的方式打开,告诉内核我们需要向文件中写入数据;
  2. O_APPDENT告诉内核以"追加"的方式写文件;
  3. O_DSYNC告诉内核,当向文件写入数据的时候,只有当数据写到了磁盘时,写入操作才算完成(write才返回成功)。和O_DSYNC同类的文件标志,还有O_SYNC,O_RSYNC,O_DIRECT。
    • O_SYNC比O_DSYNC更严格,不仅要求数据已经写到了磁盘,而且对应的数据文件的属性(例如文件长度等)也需要更新完成才算write操作成功。可见O_SYNC较之O_DSYNC要多做一些操作。
    • O_RSYNC表示文件读取时,该文件的OS cache必须已经全部flush到磁盘了【附录3】
    • 如果使用O_DIRECT打开文件,则读/写操作都会跳过OS cache,直接在device(disk)上读/写。因为没有了OS cache,所以会O_DIRECT降低文件的顺序读写的效率。

二、Write阶段

write(fd,buf,6)

在使用open打开文件获得文件描述符之后,我们就可以调用write函数来写入数据了,write会根据前面的open参数不同,而表现不同。

三、Flush阶段

fdatasync(fd) == -1

write操作后,我们还调用了fdatasync来确保文件数据flush到了disk上。fdatasync返回成功后,那么可以认为数据已经写到了磁盘上。像这样的flush的函数还有fsync、sync。

  1. Fsync和fdatasync的区别等同于O_SYNC和O_DSYNC的区别。
  2. Sync函数表示将文件在OS cache中的数据排入写队列,并不确认是否真的写磁盘了,所以sync并不可以靠。

忽略文件打开的过程,通常我们会说“写文件”有两个阶段,一个是调用write我们称为写数据阶段(其实是受open的参数影响),调用fsync(或者fdatasync)我们称为flush阶段。

回到MySQL,参数Innodb_flush_method(Linux)可以设定为:Fdatasync、O_DSYNC、O_DIRECT。我们看看这个三个参数是如何影响程序MySQL对日志和数据文件的操作:


Open log Flush log Open datafile Flush data
Fdatasync
fsync()
fsync()
O_DSYNC O_SYNC

fsync()
O_DIRECT
fsync() O_DIRECT Fsync()

fdatasync被认为是安全的,因为在MySQL总会调用fsync来flush数据。使用O_DSYNC是有些风险的,有些OS会忽略该参数O_SYNC

我们看到O_DIRECT和fdatasync和很类似,但是它会使用O_DIRECT来打开数据文件。有数据表明,如果是大量随机写入操作,O_DIRECT会提升效率。但是顺序写入和读取效率都会降低。所以使用O_DIRECT需要谨慎。

 

mysql   innodb 对应相关参数:

innodb_flush_method有三个值,分别是fdatasync,O_DSYNC和O_DIRECT,其中fdatasync是默认值。它们控制了InnoDB刷新日志和数据的模式。

fdatasync:InnoDB使用fsync()函数去更新日志和数据文件。
O_DSYNC:InnoDB使用O_SYNC模式打开并更新日志文件,用fsync()函数去更新数据文件。
O_DIRECT:InnoDB使用O_DIRECT模式打开数据文件,用fsync()函数去更新日志和数据文件。

我们看到O_DIRECT和fdatasync和很类似,但是它会使用O_DIRECT来打开数据文件。有数据表明,如果是大量随机写入操作,O_DIRECT会提升效率。但是顺序写入和读取效率都会降低。所以使用O_DIRECT需要谨慎。

 

其他相关知识:

Linux上的块设备的操作可以分为两类:

第一类是使用C标准库中的fopen/fread/fwrite 系列的函数,我们可以称其为 buffered I/O。

具体的I/O path如下

Application<->Library Buffer<->Operation System Cache<->File System/Volume Manager<->Device

library buffer是标准库提供的用户空间的buffer,可以通过setvbuf改变其大小。

第二类是使用Linux的系统调用的open/read/write 系列的函数,我们可以称其为 non-buffered I/O。

I/O Path

Application<-> Operation System Cache <->File System/Volume Manager<->Device

此外,我们可以通过设置open的O_DIRECT标志来实现Direct I/O(或者叫Raw I/O),即绕过OS Cache,直接读取Device ( that's what we want^o^ ), 等于将OS cache换成自己管理的cache。不过,Linus在邮件列表中建议不这么做,而是使用posix_fadvice, madvice。[2]中表明Direct I/O比buffered I/O的性能高很多。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多