MySQL InnoDBを使用してさまざまなファイルシステムのパフォーマンスのベンチマークを探しましたが、見つかりませんでした。
私のデータベースワークロードは、一般的なWebベースのOLTPで、約90%が読み取り、10%が書き込みです。ランダムIO。
Ext3、ext4、xfs、jfs、Reiserfs、Reiser4などの人気のあるファイルシステムのうち、MySQLに最適なファイルシステムはどれですか。
データをどれだけ重視していますか?
真剣に、各ファイルシステムには独自のトレードオフがあります。先に進む前に、私はXFSとReiserの両方の大ファンですが、Ext3を頻繁に実行しています。そのため、ここでは実際のファイルシステムのバイアスはなく、ただお知らせしているだけです...
ファイルシステムがコンテナに過ぎない場合は、アクセス時間が最も短いものを使用してください。
データに重要な値がある場合は、XFSを回避する必要があります。どうして?ジャーナルされているファイルの一部を回復できない場合ブロックがゼロになるでデータを作成するため回復できません。この問題は Linuxカーネル2.6.22で修正 です。
ReiserFSは、ハードクラッシュしないことを前提として、優れたファイルシステムです。ジャーナルリカバリは正常に機能しますが、何らかの理由でパーティション情報が失われた場合、またはファイルシステムのコアブロックが吹き飛ばされた場合、ディスク上に複数のReiserFSパーティションがある場合、リカバリメカニズムが基本的にディスク全体をセクターごとにスキャンし、ファイルシステムの開始と「考える」ものを探します。 ReiserFSで3つのパーティションがあり、1つだけがブローされている場合、回復プロセスが他の2つのシステムからのフランケンシュタインの混乱をつなぎ合わせるときにこれが引き起こす混乱を想像できます...
Ext3は「遅い」ので、「32,000個のファイルがあり、それらすべてがls
を実行しているのを見つけるには時間がかかります。」何千もの小さな一時テーブルが至る所にある場合は、少し悲しみがあります。新しいバージョンには、ディレクトリトラバーサルを大幅に削減するインデックスオプションが含まれるようになりましたが、それでも問題が発生する可能性があります。
私はJFSを使用したことがありません。私がこれまでに読んだすべてのレビューは、「しっかりしているが、ブロックで最速の子供ではない」という線に沿ったものであるとコメントすることができるだけです。調査に値するかもしれません。
十分な短所は、長所を見てみましょう:
XFS:
ReiserFS:
Ext3:
ご覧のとおり、それぞれに独自の癖があります。問題は、あなたにとって最も風変わりなものはどれですか?
また、ファイルシステムなしでInnoDBを実行し、ファイルシステムのオーバーヘッドなしでパフォーマンスを向上できることにも注意してください。お勧めするかどうかはわかりませんが、以前は問題なく使用していました。
さらに、90%の読み取りと10%の書き込みで実行している場合、InnoDBのトランザクション機能が必要でない限り、読み取りパフォーマンスを向上させるためにMyISAMへの移植を検討する可能性があります。
ここでの回答は非常に非推奨であり、Googleの結果で次のようになるので、更新する必要があります。
生産環境では、XFS。毎回。 XFSはジャーナルされ、非ブロッキングです。本番環境でInnoDBを使用する最新の(2011/2012)MySQLデータベースの次の変数があることを確認します。
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT
EXT3またはEXT4も使用しないでください。ある日、BTRFSがそこに到着します。
EXT3、そしておそらくEXT4は、スマートではなく、iノードレベルでロックします。
ソース:-www.mysqlperformanceblog.com- http://dev.mysql.com/doc/internals/en/index.html -Sasha PachevによるMySQL内部の理解- https:/ /www.facebook.com/note.php?note_id=101502109016109 - http://oss.sgi.com/projects/xfs/training/ -一部のスイングキット、試行錯誤。
編集:アップデート。 EXT4は2013年半ばの時点でかなりうまくいっているようです!それでもBTRFSは適切なオプションではありません。そして、RHELはXFSを新しいデフォルトのファイルシステムにするかもしれません。繰り返しますが、EXT3は使用しないでください。
短いバージョンは、MySQLがファイルシステムで作成したことを確認した推奨事項に最も近いのがXFSですが、ext3も問題ないはずです。年の終わり。
クラスターファイルシステムCXFSを実行している場合、OCFS2とGFSはすべて問題ありません。
Reiserの派生物とJFSに対しては強く警告しますが、ニースはどちらもより広く展開されているXFSとext4によってほとんど打ち負かされていません。
それほど大きな違いはないでしょう。ディストリビューションが十分であれば、ディストリビューションがデフォルトとして使用するものをすべて使用してください。
他のことを調整するためにあなたの努力を費やしてください-十分なramを取得します-吸わないraidコントローラーを取得します-データベースのアプリケーションの不完全な(ab)使用を修正します行われて)。
ただし、mysql tmpdirを配置するファイルシステムを注意深く検討してください。これはパフォーマンス、特にディスクベースのfilesort()を行うクエリに影響します(詳細はEXPLAINを参照してください)。
遅延割り当てをサポートするファイルシステムは、ここに本当に便利だと思います。キャッシュに保存するのに十分なRAMがある場合、短期間のファイルではIOを完全に回避できるためです。XFSなどそれらが割り当てられる前に削除されて閉じられるファイルを書くことを全く気にしません。
もちろん、tmpfsにtmpdirを置くことはパフォーマンスの観点から魅力的ですが、スペースを使い果たし、そうでなければ(ディスクの一時ファイルが使用されていても)クエリが失敗するというリスクにつながります。
さまざまなファイルシステムで実行されているMySQLのベンチマーク「切り上げ」に関する最近の記事は見つかりません。あなたが説明するワークロードを考えると、ファイルレベルの断片化が大きな問題になるとは思えません。正式なベンチマークがないと、信頼できることは何も言えませんが、上で述べたすべてのファイルシステムは、ほぼ同じ球場で実行されることになります(つまり、パフォーマンスの数値ではすべて同じ桁数) 。
ファイルシステムはストレージエンジンがアクセスしている大きなエクステントを管理しているだけなので、データベースは実際にショーを実行しています。
それでも、これらすべてのファイルシステムでパフォーマンスのまとめを行うのは興味深いでしょう。 (ただし、MySQLには熱意がないので、私はそれを実行しません。Postgres、OTOHのベンチマークは興味深いかもしれません...)
Linuxで利用できる注目すべきFSは次のとおりです。
XFS(読み取り速度が遅い)は、システムリソースが軽く、大きなファイルでは高速であることがわかっていますが、多数の小さなファイルを処理するには不十分です。
ReiserFS(書き込み速度が悪い)は、システムリソースにあまり優しくありませんが、多数の小さなファイルで非常にうまく機能します。
EXT3はその中間にあり、すべてのフィールドで許容できるパフォーマンスを発揮します(これがdefaultlinux FSと見なされた理由)。
私はまだReiserFS4ではなくEXT4を使用していませんが、いくつかのベンチマークを調べてみました。読み取り速度に関しては、ReiserFSが最もパフォーマンスが高いようです。
これを見てください: ReserFS4 X Ext4 X Ext
安定性、セキュリティ、成熟度の点からExt3をお勧めしますが、読み取り速度が最も重要な場合は、ReiserFSを検討する必要があります。
FSを選択する前に、CPU使用率、安定性、セキュリティなども考慮する必要があることを忘れないでください。
そしてもちろん、特定の環境でパイロット、テスト、ベンチマークを作成することは、何が最も効果的かを判断する最良の方法です。
PS:より多くのベンチマークを投稿したはずですが、複数のリンクを投稿することはできません。