LinuxでO_DIRECTを使用する

まあ、あなたは経験について質問しているので、質問はやや主観的であり、議論の余地がありますが、大丈夫です。

Linusは、人々が一般的にO_DIRECTに帰属する用途に言及している間、IMO Linusは基本的にこれらの用途に対して正しいと言いました。直接I / Oを実行してもデバイスからプログラムステートメントに直接データを渡すことはできません。また、効率性を高めるために、先ほど読んだ内容が再び必要な場合に備えて、再度読みたくないでしょう。したがって、一種のキャッシュが必要です。これはカーネルがO_DIRECTなしでページキャッシュのために提供することです！なぜそれを使用しないのですか？さらに、より多くのプロセスが同時に同じファイルにアクセスしようとすると、O_DIRECTが災害になるという利点もあります。

O_DIRECTには用途があります。何らかの理由でブロックデバイスから直接データをインポートする必要がある場合です。パフォーマンスとは何の関係もありません。

パフォーマンスを向上させるためにO_DIRECTを使用している人は、通常、ページキャッシュアルゴリズムが悪いシステムやPOSIX勧告メカニズムのないシステム、または他の人が言ったことを盲目的に繰り返す人から来ます。これらの問題を回避するためのソリューションはO_DIRECTです。 Linuxの哲学であるOTOHは、実際の根本的な問題を解決しなければならないということであり、根本的な問題は、オペレーティングシステムがページキャッシュ操作を正しく実行できないことです。

私はO_DIRECTを使用します私のコンピュータでメモリエラーを見つける単純なcatの実装です。これはO_DIRECTの有効な使用です。これはパフォーマンスとは関係ありません。

実際、O_DIRECT はいこれらのいずれかを避けるべきです。

• キャッシュ汚染- キャッシュオーバーヘッドが意味がないことを知っていることがあります。たとえば、64GiBのRAMは、2GiBに過ぎない非常に大きなファイルを処理するときです。ユーザーが確認することを決定した32GiB急流ファイルは、キャッシュには適していないようです。これは独自のオーバーヘッドを持つ追加のアクティビティです。キャッシュから本当に便利なデータが削除される可能性があります。
• 二重バッファリング- たとえば、一部のRDBMS（MySQLなど）では、独自のキャッシュ定義を許可します。おそらくデータベースは、SQL計画などについて何も知らないカーネル仮想メモリよりキャッシュする方法と内容についてもっと知っているでしょう。

- 良く見えません。O_DIRECTより速いという意味ではなく、通常はそうではありません。。

パフォーマンスに関連しています。

興味深い例は、mongodbでmmapエンジンを使用することです。他の人が言ったように、しばらくデータを読み取る可能性がないので、O_DIRECTを使用するのが最善です。 mongodbでは、データベースログはO_DIRECTを使用して作成されますが、データとインデックスの書き込みはページキャッシュメカニズム（pdflush）として扱われます。 O_DIRECTはより少ない帯域幅を提供しますが、待ち時間も短く、事故発生時のデータ損失を防ぐことができないためです。予期しない中断（カーネルパニック、ディスク、または電源障害）。 O_DIRECT書き込みが不揮発性ストアにコミットされる前にまだバッファリングがあるため、データ損失が少なくなります。

O_DIRECTのもう一つの重要な機能は次のとおりです。注文する書く。繰り返しますが、書き込み順序は保証されません（不揮発性キャッシュディスクコントローラがあり、fifoスケジューラを使用しない限り、これはそれ自体複雑です）。したがって、mysqlはデータ/インデックスとロギングにO_DIRECTを使用しますが、通常は後者が最初にコミットすることを期待できます。

しかし、O_DIRECTはリソース割り当ての公平性を損なうことを覚えておくことが重要です。アプリケーションが高速化される理由の1つは、他のアプリケーションの速度が遅くなることです。

@Julianoがすでに言ったことについて。

実際の問題がデフォルトのファイルシステムキャッシュアルゴリズムの誤った動作であることを確認するには、posix_fadviseファイルシステムの使用方法に関する提案を提供できます。うまく実装されたfsの場合、パフォーマンスは向上します。 （同様の考慮事項を扱う他のトピックへのリンクは次のとおりです。https://stackoverflow.com/a/3755818/544721)