MySQL的相关参数:default-storage-engine = INNODBinnodb_flush_method=O_DIRECTtmpdir = /tmp/mysqltmp/tmp/mysqltmp目录为tmpfs
发现error日志中出现
131119 15:12:55 InnoDB: Failed to set O_DIRECT on file ./BetBrainV4/Participant.ibd: OPEN: Invalid argument, continuing anyway
131119 15:12:55 InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662
解决方式:
1.创建memory或myisam的临时表代替innodb;2.修改innodb_flush_method为非O_DIRECT,如O_DSYNC、fdatasync;参考:http://bugs.mysql.com/bug.php?id=26662
下面介绍一个解决方式的思路:
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_SYNC方式打开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缓冲
2个思考
1、innodb_flush_method究竟应不应该使用O_DIRECT?所有MySQL调优的建议都说,如果硬件没有预读功能,那么使用O_DIRECT将极大降低InnoDB的性能,因为O_DIRECT跳过了操作系统的文件系统Disk Cache,让MySQL直接读写磁盘了。但是在我的实践中来看,如果不使用O_DIRECT,操作系统被迫开辟大量的Disk Cache用于innodb的读写缓存,不但没有提高读写性能,反而造成读写性能急剧下降。而且buffer pool的数据缓存和操作系统Disk Cache缓存造成了Double buffer的浪费,显然从我这个实践来看,浪费得非常厉害。说O_DIRECT造成MySQL直接读写磁盘造成得性能下降问题,我觉得完全是杞人忧天。因为从JavaEye的数据库监测来看,Innodb的buffer pool命中率非常高,有98%以上,真正的磁盘操作是微乎其微的。为了1%的磁盘操作能够得到Disk Cache,而浪费了98%的double buffer内存空间,无论从性能上看,还是从内存资源的消耗来看,都是非常不明智的。2、innodb_log_file_size究竟应该大一点,还是小一点?所有MySQL调优建议都说,innodb_log_file_size要越大越好,避免无谓的buffer pool的flush操作。但是在我的实践中来看,innodb_log_file_size开得太大,会明显增加innodb的log写入操作,而且会造成操作系统需要更多的Disk Cache开销。innodb_flush_method=O_DIRECT是必须的,而innodb_log_file_size也不宜太大。
下面是一段摘录的备忘
innodb_flush_log_at_trx_commit参数确定日志文件何时write、flush。innodb_flush_method则确定日志及数据文件如何write、flush。在Linux下,innodb_flush_method可以取如下值:fdatasync, O_DSYNC, O_DIRECT,那这三个值分别是如何影响文件写入的?首先我们需要先来了解Linux的文件I/O是如何工作的。先来看看Linux/Unix文件I/O的一个典型例子:(Linux 2.6.24测试,gcc编译)/**
A test about syscall of File I/O
Author:supu@TaobaoDBA
supu@taobao.com http://orczhou.com http://www.taobaodba.com
*/
#include "stdlib.h" /* for exit */
#include "unistd.h" /* for write fdatasync*/
#include "fcntl.h" /* for open */
int main(void){
int fd;
if((fd=open("/home/zzx/test.file",O_WRONLY|O_APPEND|O_DSYNC))<0){
exit(1);
}
char buff[]="abcdef";
if(write(fd,buff,6)!= 6){
exit(2);
}
if(fdatasync(fd)==-1){
exit(3);
}
exit(0);
}
程序描述了一般的文件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打开文件:O_WRONLY表示我们以"写"的方式打开,告诉内核我们需要向文件中写入数据;
O_APPDENT告诉内核以"追加"的方式写文件;
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。Fsync和fdatasync的区别等同于O_SYNC和O_DSYNC的区别。
Sync函数表示将文件在OS cache中的数据排入写队列,并不确认是否真的写磁盘了,所以sync并不可以靠。
忽略文件打开的过程,通常我们会说“写文件”有两个阶段,一个是调用write我们称为写数据阶段(其实是受open的参数影响),调用fsync(或者fdatasync)我们称为flush阶段。
回到MySQL,参数Innodb_flush_method(Linux)可以设定为:Fdatasync、O_DSYNC、O_DIRECT。我们看看这个三个参数是如何影响程序MySQL对日志和数据文件的操作:Open logFlush logOpen datafileFlush data
Fdatasyncfsync()fsync()
O_DSYNCO_SYNCfsync()
O_DIRECTfsync()O_DIRECTFsync()
fdatasync被认为是安全的,因为在MySQL总会调用fsync来flush数据。使用O_DSYNC是有些风险的,有些OS会忽略该参数O_SYNC。
我们看到O_DIRECT和fdatasync和很类似,但是它会使用O_DIRECT来打开数据文件。有数据表明,如果是大量随机写入操作,O_DIRECT会提升效率。但是顺序写入和读取效率都会降低。所以使用O_DIRECT需要谨慎。
参考文章:
【附录1】文章需要你了解什么是“系统调用“,参考:
可以简单的理解为:“系统调用“是在内核之上的一层封装。由内核直接提供接口,“系统调用”需要陷入内核执行(内核态)。其中fdatasync就是一个系统调用,该系统调用可以通知OS立刻将OS Cache中的数据Flush到磁盘文件中。
【附录2】这时候内核会为该该进程打开的文件分配一个文件描述符,并将该文件描述符返回给该进程。在内核的文件表中新建一个文件项,标记文件状态、文件当前偏移、以及I节点(v节点)的位置,内核还会打开该文件的I节点(这里记录文件的操作的函数指针,例如读操作、写操作)。
【附录3】O_RSYNC我的理解是,对于同一个文件描述符可以保证读数据安全。同一个文件描述符包括dup和fcntl函数dup的文件描述符,即共用同一个文件表项。O_RSYNC不是我们今天关注的,暂时忽略
未解问题:O_DIRECT在哪些OS(或者FS)上能够正常工作?
O_SYNC在哪写OS上不能正常工作呢?
内核的read、write是FS级别的还是内核(kernel)级别?
文章innodb_flush_method带来的性能影响中O_DSYNC、和fdatasync效率差很多,这是为什么?
(全文完)