mysql存儲內存中（tmpfs）的問題

時間 2020-01-13

標籤 mysql 存儲內存 tmpfs 問題欄目 MySQL 简体版

原文原文鏈接

MySQL的相關參數：
default-storage-engine = INNODB
innodb_flush_method=O_DIRECT
tmpdir = /tmp/mysqltmp
/tmp/mysqltmp目錄爲tmpfs
php

發現error日誌中出現html

131119 15:12:55 InnoDB: Failed to set O_DIRECT on file ./BetBrainV4/Participant.ibd: OPEN: Invalid argument, continuing anywaymysql

131119 15:12:55 InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662linux

解決方式：
sql

1.建立memory或myisam的臨時表代替innodb；
2.修改innodb_flush_method爲非O_DIRECT，如O_DSYNC、fdatasync；
參考:
http://bugs.mysql.com/bug.php?id=26662
http://bugs.mysql.com/bug.php?id=45671數據庫

下面介紹一個解決方式的思路:編程

innodb_flush_method這個參數控制着innodb數據文件及redo log的打開、刷寫模式，對於這個參數，文檔上是這樣描述的：緩存

有三個值：fdatasync(默認)，O_DSYNC，O_DIRECT安全

默認是fdatasync，調用fsync()去刷數據文件與redo log的bufferasync

爲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個思考

一、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內存空間，不管從性能上看，仍是從內存資源的消耗來看，都是很是不明智的。

二、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也不宜太大。

下面是一段摘錄的備忘

http://www.orczhou.com/index.php/2009/08/innodb_flush_method-file-io/

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操做（將文件緩存刷到磁盤上）。

1、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下降文件的順序讀寫的效率。

2、Write階段

write(fd,buf,6)

在使用open打開文件得到文件描述符以後，咱們就能夠調用write函數來寫入數據了，write會根據前面的open參數不一樣，而表現不一樣。

3、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 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須要謹慎。

參考文章：

【附錄1】文章須要你瞭解什麼是「系統調用「，參考：

http://www.ibm.com/developerworks/cn/linux/kernel/syscall/part1/index.html

能夠簡單的理解爲：「系統調用「是在內核之上的一層封裝。由內核直接提供接口，「系統調用」須要陷入內核執行（內核態）。其中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效率差不少，這是爲何？

(全文完)

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。