用tmpfs加速mysql_mysql存储内存中（tmpfs）的问题

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效率差很多，这是为什么？

(全文完)