InnoDBテーブルとext4のキャッシュ相互作用解析

InnoDBテーブルとext4のキャッシュ相互作用解析

• 一般に、ファイルへの書き込み動作は、ファイルの属性（メタデータのメタデータ）（を含むディレクトリのファイル属性、iノード、等）には2つの部分、データ自体の書き込み動作、書き込み動作から成ります。
• なぜO_DIRECT直接IOは、ページ・キャッシュをバイパス/（これまでのfsyncに必要なキャッシュをバッファ）、それはディレクトリキャッシュとiノードキャッシュメタデータであることも、ストレージデバイスにフラッシュすることができます。そして、カーネルとファイルシステムを更新するので、ファイルシステムには、いくつかの保証を保証することができずにfsyncを（）の同期メタデータはしません進行中のデータセキュリティO_DIRECTで問題の原因、InnoDBはまたO_DIRECT_NO_FSYNCの方法を提供しますので。

A、InnoDBの関連

全体的に1

上の図から、我々は、ディスクの必要性へのInnoDBデータが通過していることがわかります

1. InnoDBのバッファプール、REDOログ・バッファ。このアプリケーションは、InnoDBのバッファシステム自体です。
2. ページキャッシュ/バッファ・キャッシュ（O_DIRECTによってバイパスすることができます）。このVFSは、バッファ層です。
3. iノードキャッシュ/ディレクトリバッファ。これは、バッファ層VFSです。O_SYNCまたはFSYNCによってリフレッシュする必要があります（）。
4. ライトバックバッファ。（パラメータ記憶制御装置は、バイパスに設けられていてもよいです）
5. ディスク上のboradバッファ。（ディスクコントローラパラメータを設定することによってバイパスすることができます）

ここでは、用語は、データの一時記憶を表現する用語「キャッシュ」（通常キャッシュ）の一時的な使用に書き込まれたデータを表現するために（通常はバッファ）を読んで「バッファー」を使用します。名前は、基礎となるストレージデバイスとメモリの速度差に起因する意味として、一時的にバッファリングするための基礎となるストレージ装置IOを「低速」でヒット「赤」。キャッシュは、主に一時的に遅く、再び基盤となるストレージ・デバイスにアクセスすることなく、このデータへのその後のアクセスのために、メモリ内のデータをディスクから読み取る「保存します」。

RDSのデフォルトでは、いくつかのパラメータ

innodb_flush_method = O_DIRECT

innodb_flush_log_at_trx_commit = 1

innodb_flush_log_at_timeout = 1

2 InnoDBの

バッファ層は、ホストメモリに配置され、その主な目的は、自分のアプリケーション層のデータを管理影響InnoDBの遅い応答時間を避けるために、操作を読み取りおよび書き込みすることです。

REDOログ・バッファとInnoDBのバッファプール：InnoDBの層は、主に二つのバッファを含みます。

一時的にREDOログREDOログ・ログの書き込みを保存するためのログバッファをやり直し、InnoDBのバッファプールに格納InnoDBのデータがダーティページであること、データを書き込みデータをバッファリングするだけでなく、InnoDBのにディスクデバイスから読み取ります。

ホストの電源がオフまたはMySQLの異常なダウンタイムされている場合は、あなたが唯一のタイムリーなリフレッシュにない場合は、上のチェックポイントから前にロールへのInnoDB REDOログを使用する（PGはまた、redoログ）とREDOログ・バッファことができますので、InnoDBのバッファプールは、速やかに、ディスクにフラッシュされることはありませんREDOログ・データの損失によるディスク、および前でもやり直しロールを使用して、不揮発性ディスクメディアへの実際のレコードが存在しないため、ユーザーが提出したトランザクションは、負けます。

リフレッシュタイミングパラメータバッファ制御REDOログはinnodb_flush_log_at_trx_commitあり、REDOログ・バッファと制御パラメータがプールリフレッシュモードバッファINNODB innodb_flush_methodあります。これら2つのパラメータのための記事の詳細は非常に大きく、我々は解決するために、バッファの観点から、主にここにあります。

innodb_flush_log_at_trx_commit：2.1ブラシログに影響を与えます

innodb_flush_log_at_trx_commitのコントロールREDOログ・バッファは現在、三つの異なるパラメータ値をサポートしています0,1,2

<5.6.6：毎秒、データバッファREDOログがディスクにフラッシュされます

= 5.6.6：ディスクにデータをリフレッシュするためにあらゆるinnodb_flush_log_at_timeout秒。

ノート：

• 1のデフォルト設定は、完全なACID準拠のために必要とされます。ログは各コミットトランザクションで書かれており、ディスクにフラッシュされています。

  ログの書き込みに加えてフラッシュトランザクションのコミット

• 0に設定すると、ログが書かれており、1秒間に1回ディスクにフラッシュ。ログがフラッシュされていないためにトランザクションが事故で失われることがあります。

  トランザクションは、ディスクへの書き込みもフラッシュ、1秒のフラッシュ時間はありません、ログバッファのログ書き込み専用コミットすると、

• 各トランザクションがコミットした後、2に設定すると、ログが書かれており、1秒間に1回ディスクにフラッシュ。ログがフラッシュされていないためにトランザクションが事故で失われる可能性があります

  ログの書き込みではなく、フラッシュ、1秒のフラッシュ時間を行うディスクへ

2.2エフェクトブラシとブラシログデータ：innodb_flush_method

innodb_flush_methodの制御InnoDBのバッファプールは、現在、四つの異なるパラメータ値をサポートしています。

• fdatasync
• O_DSYNC
• O_DIRECT
• O_DIRECT_NO_FSYNC

1. innodb_flush_methodは、「ログファイル」リフレッシュモードを指定する、唯一の「データファイル」リフレッシュモードを指定しました。
2. 最初の3つのパラメータはO_DIRECT_NO_FSYNC添加開始5.6.7から、使用する前にのみバージョン5.6.6および5.6.6で許可しました。つまり、データを同期するためにO_DIRECTでファイルを開きますが、fsyncをせずに（）。このため、比較的新しいLinuxカーネルとファイルシステムの一部の、あなたは、データのセキュリティを確保O_DIRECTを使用して、メタデータは、非揮発性ディスクメディアにフラッシュされることを確実にするためではない、具体的にfsync（）の同期を行うことができます。たとえば：XFSは、このパラメータを使用することはできません。その後、ページ・キャッシュをバイパスO_DIRECT、なぜ使用のfsync（）と次のように更新し、我々は次のセクションを捧げました。
3. O_DIRECT_NO_FSYNCに加えて、InnoDBはリフレッシュすることにfsync（）を使用して、「データファイルを。」ここでは例外O_DIRECT_NO_FSYNCです。
4. あなたはO_DIRECT、O_DIRECT_NO_FSYNCを指定した場合、データファイルがO_DIRECT開いています

集まります

オープンログ	オープンログ	フラッシュログ	オープン・データ・ファイル	フラッシュのデータ・ファイル
fdatasync		FSYNC（）		FSYNC（）
O_DSYNC	O_SYNC			FSYNC（）
O_DIRECT		FSYNC（）	O_DIRECT	FSYNC（）
O_DIRECT_NO_FSYNC		FSYNC（）	O_DIRECT
All_O_DIRECT（percona）	O_DIRECT	FSYNC（）	O_DIRECT	FSYNC

ノート：

• fsync：InnoDB使用してfsync()、データとログファイルの両方のフラッシュへのシステムコールを。fsyncデフォルト設定です。

  ログデータのfsyncはなくOSのバッファバイパスへ

• O_DIRECT：InnoDB用途O_DIRECT（またはdirectio()データファイルを開くにはSolaris上）、および用途はfsync()、両方のデータをフラッシュし、ファイルをログに記録します。このオプションは、いくつかのGNU / Linuxバージョン、FreeBSDの、およびSolarisで使用可能です。

  Oはないログについて、周りのデータのバッファリング

• O_DIRECT_NO_FSYNC：InnoDB使用のO_DIRECTI / Oをフラッシュする時に、しかしスキップfsync()各書き込み操作の後にシステムコールを。

  周りのデータのOSのバッファリング、ログに関する同期なし、ではありません

FSYNCとO_DIRECTとは何ですか？

書き込みディスクは、3つのアクションに分割されています。

[1]は、ファイルを開くために開きます

[1]書き込み書き込みファイル（およびオープンバインディング）

[2]フラッシュフラッシュ動作（ディスクブラシにファイルキャッシュ）

• たとえば、開いています：open("test.file",O_WRONLY|O_APPDENT|O_SYNC))

• • O_SYNC：データがディスクに書き込まれている場合のみ、ファイルにデータを書き込む場合、書き込み操作が完了していない（書き込みのみ成功を返す）、および（などなど、ファイルの長さ、）属性データファイルに対応する完了前に更新する必要があります演算子成功した書き込み（メタデータ）の操作
  • O_DIRECT：書き込み操作は、デバイス（ディスク）に直接OSCacheの、読み取り/書き込みをスキップします/読み込み、ファイルを開きます。何OSCacheのは存在しないので、読み取りを削減し、シーケンシャルファイルO_DIRECT効率を書き込みます。

• 書き込み動作は、ディスクキャッシュに直接書き込むか、書き込みするためのオープンな方法によって決定されます

• ディスクブラシのキャッシュをフラッシュし、O_DIRECTなぜには、以下のセクションを参照してください、フラッシュに直接書き込む必要があります

二、システムキャッシュ関連（重要）

原則1 O_DIRECT

私たちは、ファイルおよび書き込みデータを開き、VFSとファイルシステムは、ハードウェア層列、ショーキーデータ構造下図にデータを書き込む方法です。

https://www.usenix.org/legacy/event/usenix01/full_papers/kroeger/kroeger_html/node8.html

• メインデータとブロックデータ構造体をバッファリングするpage_cache /バッファキャッシュメモリ。
• iノードキャッシュバッファのiノード
• ディレクトリ構造のデータをバッファリングするためのディレクトリ・キャッシュ。

オペレーティング・システムおよびファイル・システムに応じて、ファイルへの一般の書き込み動作は、ファイル属性には2つの部分、データ自体の書き込み動作、書き込み動作（メタデータは、メタデータ）ファイルが含む属性（ここから成りディレクトリ、iノードなど）。

	表紙	バッファキャッシュ	iノードキャッシュ	dictoryキャッシュ
O_DIRECT	書き込みバイパス	書き込みバイパス	書き込み＆フラッシュなし	書き込み＆フラッシュなし
O_DSYNC /はfdatasync（）	書き込み＆フラッシュ	書き込み＆フラッシュ	書き込み＆フラッシュなし	書き込み＆フラッシュなし
O_SYNC / FSYNC（）	書き込み＆フラッシュ	書き込み＆フラッシュ	書き込み＆フラッシュ	書き込み＆フラッシュ

• またはコールはfdatasync全ページキャッシュの書き込み特定のデータ（）瞬間の後、キャッシュバッファ、すべての対応するページキャッシュのためのリフレッシュと各IO時にキャッシュバッファ提出される：差O_DSYNCとはfdatasyncは（）ということですリフレッシュ。O_SYNCおよびFSYNC（）共感との差。
• ページキャッシュとバッファキャッシュの主な違いは、実際のファイルデータが配向していることがあるブロック指向のデバイスです。、あなたがそのメイク用のmkfsファイルシステムページのキャッシュを使用してキャッシュをバッファリングするファイルVFSのトップへの道を開くために）（オープンを使用して、あなたが使用している場合、LinuxオペレーティングシステムLinuxオペレーティング・ブロック・デバイス上でこの方法をddは、あなただけのバッファキャッシュを使用します。
• O_DSYNCとO_SYNC差があることである：データは、データがディスクに書き込まれるのみファイルに書き込まれたときに、O_DSYNCはカーネルに伝えるために、書き込み動作は（成功を返す前に書き込み）完全ではありません。より厳しいO_DSYNCよりO_SYNCは、成功するために、書き込み操作を完了するために更新する必要があります（そのようなファイルのinode、ディレクトリ関連の変更など）に対応するデータファイルを、データがディスクに書き込まれていないだけ必要とし、属性。O_SYNCはよりO_DSYNCよりも、いくつかの操作を行うに見られます。
• オープン（）referense O_ASYNCがあるが、それは主に端末、擬​​似、ソケット、及びパイプ/ FIFOは、デバイスは、読み書きできる場合IO、送信信号（SIGIO）を駆動するための信号を、この信号のキャプチャアプリケーション・プロセスのために使用されますIO操作します。
• O_SYNCとO_DIRECTが書き込みに同期され、それが唯一の成功を書くに戻ります。

背中を見て、私たちはより良い理解されているinnodb_flush_log_at_trx_commitの構成を見ていきます。

なぜO_DIRECT直接IOは、ページ・キャッシュをバイパス/（これまでのfsyncに必要なキャッシュをバッファ）、それはディレクトリキャッシュとiノードキャッシュメタデータであることも、ストレージデバイスにフラッシュすることができます。

そして、カーネルとファイルシステムを更新するので、ファイルシステムには、いくつかの保証を保証することができずにfsyncを（）の同期メタデータはしません進行中のデータセキュリティO_DIRECTで問題の原因、InnoDBはまたO_DIRECT_NO_FSYNCの方法を提供しますので。

2つのO_DIRECT長所と短所

推奨innodb_flush_methodパラメータ値のほとんどは、さえperconaサーバーのブランチでもALL_O_DIRECTを提供し、O_DIRECTで推奨されているログファイルもO_DIRECT開く]を使用しています。

優位

• これInnoDBが使用するInnoDBのバッファプールを残すために、データを読み書きするために多くのメモリをオペレーティングシステムで少ないメモリを取る避けて、ページキャッシュのバイパスO_DIRECT /バッファキャッシュ：オペレーティングシステムのメモリを節約できます。
• 保存CPU：メインポールの送信、割り込みやDMAモードへのメモリ記憶装置。O_DIRECTシステムは、CPUを節約するために、ストレージ・デバイスへのDMA動作を使用するために使用する演算子を求めるプロンプトが表示されます。

恵まれません

• バイトアライメント：書き込みデータに必要O_DIRECT方法、メモリは、（異なるカーネルおよびファイルシステム異なるによる整列方法）バイト整列です。これは、追加のアライメント動作の必要性の書き込み中のデータが必要です。あなたはでき/sys/block/sda/queue/logical_block_size揃え、一般的に512バイトのサイズを知っています。
• IOをマージすることはできません。バイパスO_DIRECT page cache/buffer cache直接書き込みストレージデバイス、メモリ内のデータの同じ部分にあれば繰り返し書き込みがヒットし、することはできませんので、page cache/buffer cacheマージ機能が有効に書き込むことができません。
• 書き込みの効率を低下させるため：O_DIRECTファイルを開く場合は、読み取り/書き込み操作はキャッシュ、ストレージ・デバイス上の直接の読み取り/書き込みをスキップされます。そこにはキャッシュがありませんので、ファイルの読み込みと書き込みの順序は、比較的低効率O_DIRECT方式このような小さなIO要求を使用しているため。一般に、（ログを効率もあればそうログが比較的低くなり、順次書き込まれる）、すべてのアプリケーションおよびシナリオのセットinnodb_flush_methodにO_DIRECTを使用していない100％が適用可能です。

パラメータ最適化吊りプレート3のext4

• noatimeオプション

  値がiノードに記録されていないatimeの時間を読んで、頻繁にディスクに書き込まれた読み取りを減らすことができます

• nodiratime

  このオプションは、ディレクトリのatimeの更新を禁止されているので、あなたは、このような順序は、atimeののディレクトリのls値を更新しないことができます

• nodelalloc

  無効に遅延アロケーション、事前割り当てブロックは、ext4をの良好な特性があるページキャッシュに割り当てられたブロック番号、サイズの大きいファイルをスピードアップすることができます

• nobarrier

  予期せぬクラッシュ後の高速リカバリのためのREDOログ・データベースフィールドに似ジャーナル領域があるとして、現代のext4ファイルシステムをジャーナリング：実際には、単にバリアは、WALログ・ファイル・システム（書き込み先行ロギング）手段を確保することです。最初のディスク領域に書き込まジャーナルデータを書き込む必要があり、その後、ディスクの実際の位置に対応するデータを書き込みます。ディスクのディスク書き込み速度を高速化するために、ディスクの製造業者は、データは、一般的にディスクキャッシュに書き込まれ、キャッシュに組み込まれています。.. キャッシュは、書き込み速度を高速化はもちろん、優れたものであるが、一般的にデータをキャッシュするために、ディスクキャッシュを持つことができることをリフレッシュするための実際のデータを引き起こし、ジャーナル・オブ・オーダーもので、最適ながディスクにフラッシュようにソートされました。システムがクラッシュしたら、次のブートディスクは、参照ジャーナルの領域を復元するが、今回は、実際のジャーナル・レコードの配列データは順序がデータになりますが、別の「復元」矛盾するリフレッシュ。その名の「フェンス」への障壁、最初のジャーナルを確保するために、「フェンス」を追加し、対応するデータはシステムクラッシュ後のディスクリカバリの正確さを保証するために、このように、ディスクにフラッシュして、常に最初に書かれたレコードですが、書き込みパフォーマンスはかなり大きな影響。

• 注文したデータ=

  ユーザーのニーズに応じて様々なモードを使用してログインするext4をサポートします。メタデータを記録順序やモード、書き込みデータをログからのメタデータに書き込まれます;それはメタデータのみを記録しているライトバックのext4サポートモードは、あるいはジャーナルモード（最も信頼性の高いモード）、それはまた、メタデータを記録しますそしてデータ。すべてのデータがログを経なければならないので、ジャーナルモードは、ファイルシステムの一貫性を確保するための最良の選択ですが、それはまた、最も遅いですが、あることに注意してください。

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

data= journal 
      All data are committed into the journal prior to being
			written into the main file system.  Enabling this mode will 
			disable delayed allocation and O_DIRECT support.

data= ordered	(*)
      All data are forced directly out to the main file
		  system prior to its metadata being committed to the journal.

data= writeback 
      Data ordering is not preserved, data may be written
			into the main file system after its metadata has been
			committed to the journal.

第三に、メモリ関連

バッファ層は、その主な目的は、記憶制御装置レベルでデータをバッファリングすることであり、オンボードキャッシュメモリコントローラに対応配置されて、ブロック・デバイスは、読み出しおよび書き込み動作の遅い応答時間は、IOに影響防ぎます。

データ記憶層にブラシ等FSYNC（）である場合、第一の層は、メモリコントローラに送られます。一般的なストレージ・コントローラはRAIDカードで、今最も1GまたはRAIDカードのより大きな記憶容量を有します。このバッファは、マシンの電源をオフにした後、「揮発性メモリ」のデータは、まだ基礎となるディスクストレージメディアに同期されることを保証するために、電池/コンデンサ搭載、一般的に揮発性の記憶装置です。

ストレージコントローラについて、我々はいくつかのエリアにその必要性の注意を持っています：

1. ライトスルーバック/ライト：かバッファに対して、メモリコントローラは、2つの方法を介して一般的なライトバックとライトを提供します。書き込みバックモードでは、オペレーティングシステムが成功を返します。バッファに直接書き込むために要求を提出したデータを書き込み、スルーモード次の書き込みは、オペレーティング・システムは、基礎となるメディアに成功を返す前に、要求が実際にディスクに書き込まなければならない提出されたデータを書き込みます。
2. バッテリ/コンデンサ区別：「揮発性」バッファダウンマシン内のデータが迅速底層上にディスク媒体にフラッシュすることができることを保証するために、メモリコントローラは、バッテリ/コンデンサを確保しています。電池容量フェージング、すなわち一般的な問題の間隔、車載バッテリの充放電は、電池の容量を確保するように制御されなければなりません。バッテリの充放電の過程において、メモリ・ライト・バック・コントローラは、自動的にライトを介して変化するように設けられています。このサイクル（サイクルサイクルをご覧ください）。あなたが見つけた場合に充放電を、LSIカードがMegaCliで見ることができ、一般的に90日であること、すべてのIO要求の応答時間が突然スローダウンしながら、ああ、問題がある可能性がありますに一度。イベント説明のMegaCli -AdpEventLog -GetEvents -f mr_AdpEventLog.txt -aALLログで：バッテリーは、充放電の発生が発生したかどうかを判断することができ、充電を開始しました。
3. あなたはアプリケーションに応じてできるように、25％の読み取り/ 75％書き込みます。grep「アクセラレータRatioAccelerator比|キャッシュの区別を提供するために、HPのSmartアレイは、読み取りと書き込み（アクセラレータ比）、hpacucli CTRLすべてのshow設定詳細：/書き込みの比率を読みますバッファ・キャッシュの比率を設定するための実際の状況は、読みとの書き込みキャッシュ。
4. オープン直接IO：RAIDカードバイパスに上位装置の直接IOの方法を利用することができるようにするために、あなたがレイドオープンDIRECTIOの方法を設定する必要があります。/ opt /のMegaRAID / MegaCli / MegaCli64 -LDSetProp -Direct -immediate -Lall -aALL
5. LSIフラッシュ襲撃：私たちは、「揮発性」、上記の基本的なデバイスへのバッファ・メモリ・コントローラは、より高速ではないのでことを、私たちは今、不揮発性バッファを持っている場合、バッファ、および数百Gの能力？カードメーカーのベテランとしてレイド、LSIは、現在、このようなメモリコントローラを有し、ライトバックバッファメモリコントローラ依存アプリケーションの比較の使用は、ストレージ・コントローラのこの種の使用を考慮することができます。
6. 書き込み障壁：現在のキャッシュRAIDカード、表示されていないので、ファイルシステムのジャーナリングのLinuxの一貫性を確保するために、デフォルトでは書き込み障壁を開きます、つまり、Linux用の電池やキャパシタの保護がある場合、それはリフレッシュしていきます」。揮発性「バッファ、それが大幅IO性能を低下させるであろう。あなたは、「揮発性」のバッファを確保するための基盤となるバッテリーは、基礎となるディスクデバイスにブラッシングすることを確信しているのであれば、あなたはでき -o nobarrierをマウントしたディスクに時間を追加します。

第四に、関連するディスクコントローラ

バッファ層は、ディスクコントローラボードキャッシュの対応に置かれます。規則でソートされますストレージデバイスのファームウェア（ファームウェア）は、実際に行くメディアへの書き込みに同期されます。あなたはより多くのディスク書き込み操作を行うことができ、頭部の動きを作ってみることができますのでここでは主に、シーケンシャル書き込み、機械式のディスクを確保します。

一般に、DMAコントローラは、CPUリソースを節約することができるディスク、DMAコントローラによるダイレクトメモリアクセス、この層に配置されます。

機械的なハードディスク用等の一般的なディスク・デバイスなしバッテリー容量、ので、電源は機械内部のディスクキャッシュにあるとき、私たちは強く、ディスクキャッシュ閉鎖することをお勧めしますように、すべてのデータは、メディアへの時間的に同期することができることを保証することはできません。

参照

メモリとディスク速度の問題は一致していない、またはディスクの速度が遅すぎる：メディアから最終的にInnoDBは、我々はクッションのすべての種類を介して行っている、彼らの目的は非常に明確で、それが解決することです。

また、実際には、データは/キャッシュまたはアプリケーション自体をバッファリングするかどうかを最も知っているが、VFS、ストレージコントローラとディスクのみスロー基盤となるストレージ・デバイスを軽減するために（重複したIOをマージするために、順序はランダム書き込みの書き込みになります）遅延によって書き込むことができます遅い応答の問題によって引き起こされます。アプリケーションのデータベースタイプはバッファを管理することで、その後、オペレーティングシステムと基本的な設備のバッファを回避しようとしますので。

しかし実際には、ソリッドステートドライブSSDおよびPCIeフラッシュカード、メモリ、および、ソフトウェアとハ​​ードウェアエンジニアにとって大きな課題を改善することができ、必要に応じてディスクが大幅に、これらのバッファを低減し、ハードウェアとソフトウェアの出現との間に現在の速度差に起因します。

https://www.ibm.com/developerworks/cn/linux/l-anatomy-ext4/index.html

https://www.cnblogs.com/DataArt/p/10229913.html

http://en.wikipedia.org/wiki/Disk_buffer

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarrieronoff.html

http://en.wikipedia.org/wiki/Direct_memory_access