ext3にdata = writebackおよびバリア= 0でマウントする必要がありますか？

Question

ホスティング会社のVM=でサーバーを実行しており、専用ホスト（AMD Opteron 3250、4コア、8GB RAM、ソフトウェアRAIDで2 x 1TB）にサインアップしました、ext3）。

パフォーマンステストの実行中に、SQLiteの一部の変換（挿入、削除、更新の組み合わせ）に2010 MacBook Proの10倍から15倍の時間がかかっていることに気付きました。

たくさんグーグルして読んだ後、マウントオプションを確認しました。

 data=ordered,barrier=1

私たちはいくつかの実験を行い、最高のパフォーマンスを得ました

 data=writeback,barrier=0

私はこれらを読み、彼らがしていることの基本を理解しましたが、私がこのように走ることが良い考えであるかどうかについて、私には良い感覚/感じがありませんか？

ご質問

上記の構成は、ホストされたサービスについて考慮するのが賢明ですか？

停電やハードクラッシュが発生した場合、データが失われたり、ファイルが破損したりする可能性があります。 15分ごとにDBのスナップショットをとっていた場合、状況は緩和されるかもしれませんが、スナップショットがとられたときにDBが同期されない可能性があります。そのようなスナップショットの整合性をどのように（できるのでしょうか）保証できますか？

他に検討すべきオプションはありますか？

ありがとう

Huygens · Accepted Answer

最初のアドバイス
データを失うわけにはいかない場合（つまり、ユーザーが新しいデータを入力した後、数秒で失われない場合）、UPSのようなものがなければ、私は削除しませんバリアの書き込み、どちらも書き戻しに切り替えません。

書き込みバリアの削除
書き込みバリアを削除すると、クラッシュや停電の場合、ファイルシステムはfsckを実行してディスク構造を修復する必要があります（バリアがONの場合でも、ほとんどのジャーナリングファイルシステムはジャーナルのリプレイで十分だったとしてもfsck）。書き込みバリアを削除する場合、可能であれば、ハードウェアでのディスクキャッシュを削除することをお勧めします。これにより、リスクを最小限に抑えることができます。ただし、そのような変更の影響をベンチマークする必要があります。このコマンドを試すことができます（ハードウェアがサポートしている場合）hdparm -W0 /dev/<your HDD>。
マウントオプションjournal_async_commit。を使用する場合、ext4はメタデータの変更に2つのバリアを使用しますが、ext4は1つしか使用しないことに注意してください

Ted T'soが説明 ext3の初期にいくつかのデータ破損が発生した理由（バリアはデフォルトでオフでしたカーネル3.1まで）、ジャーナルはある方法で配置されていますジャーナルログラップが発生しない限り（ジャーナルは循環ログ）、データはsafeの順序でディスクに書き込まれます-最初にジャーナル、次にデータ-ハードディスクでも書き込みの順序変更がサポートされています。
基本的に、ジャーナルログがラップすると、システムクラッシュや停電が発生するのは不運です。ただし、data=orderedを保持する必要があります。さらにdata=ordered,barrier=0でベンチマークを試みてください。

数秒のデータを失う余裕がある場合は、両方のオプションdata=writeback,barrier=0をアクティブにすることができますが、commit=<nrsec>パラメータも試してみてください。マニュアルでこのパラメータ here を確認してください。基本的に、ext3ファイルシステムがデータとメタデータを同期する期間である秒数を指定します。
また、ダーティページ（ディスクへの書き込みが必要なページ）に関するいくつかのカーネル調整パラメータをいじってベンチマークしようとすることもできます。これらの調整可能パラメータに関するすべてを説明する良い記事があります。それらと遊ぶ方法。

バリアに関する概要
調整可能なパラメータのさらにいくつかの組み合わせをベンチマークする必要があります：

data=writeback,barrier=0をhdparm -W0 /dev/<your HDD>と組み合わせて使用します
data=ordered,barrier=0を使用
data=writeback,barrier=0を他のマウントオプションcommit=<nrsec>と組み合わせて使用し、nrsecに別の値を試してください
オプション3を使用し、ダーティページに関してカーネルレベルでさらに調整可能を試してください。
安全なdata=ordered,barrier=1を使用しますが、他の調整可能パラメータを試してください。特にファイルシステムのエレベーター（CFQ、DeadlineまたはNoop）とそれらの再調整可能な調整可能パラメータ。

ext4への移行とベンチマークの検討
前述のように、ext4は書き込みにext3よりも少ないバリアを必要とします。さらに、ext4はエクステントをサポートしているため、大きなファイルの場合、パフォーマンスが向上する可能性があります。したがって、再インストールせずにext3からext4に簡単に移行できるため、これは検討に値するソリューションです。 official documentation ;私は1つのシステムでそれを行いましたが、これを使用しました Debianガイド。 Ext4はカーネル2.6.32以降は非常に安定しているため、本番環境で使用しても安全です。

最後の考慮事項
この回答は完全とはほど遠いですが、調査を開始するのに十分な資料を提供します。これは要件に大きく依存しているため（ユーザーレベルまたはシステムレベル）、申し訳ありませんが、簡単な答えを出すのは困難です。

NeilB · Answer

警告：以下の不正確さがあるかもしれません。私はこれからたくさんのことを学んでいるので、塩を少し入れてください。これはかなり長いですが、操作しているパラメータを読んで、最後の結論にスキップすることができます。

SQLiteの書き込みパフォーマンスを心配できる層はいくつかあります。

太字で強調表示されているものを確認しました。特定のパラメータは

ディスク書き込みキャッシュ。最近のディスクにはRAMキャッシュがあり、回転するディスクに対するディスクの書き込みを最適化するために使用されます。これを有効にすると、データが順不同のブロックに書き込まれるため、クラッシュが発生した場合、部分的に書き込まれたファイルになる可能性があります。hdparm-W/dev/...で設定を確認し、hdparm -W1/dev/...で設定します（オンにする場合は-W0、オフにする場合は-W0）。。
バリア=（0 | 1）。「barrier = 0で実行する場合は、ディスクの書き込みキャッシュを有効にしないでください」とオンラインでたくさんのコメント。 http://lwn.net/Articles/283161/ で障壁の議論を見つけることができます
data =（journal | ordered | writeback）。これらのオプションの説明については、 http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html を参照してください。
commit = N。 N秒ごとにすべてのデータとメタデータを同期するようにext3に指示します（デフォルトは5）。
SQLiteプラグマ同期= ON |オフ。 ONの場合、SQLiteは続行する前にトランザクションが「ディスクに書き込まれる」ことを確認します。これをオフにすると、基本的に他の設定はほとんど関係なくなります。
SQLiteプラグマcache_size。 SQLiteがメモリ内キャッシュに使用するメモリの量を制御します。私は2つのサイズを試しました。1つはDB全体がキャッシュに収まるサイズ、もう1つはキャッシュが最大DBサイズの半分でした。

ext3ドキュメントでext3オプションの詳細を読んでください。

これらのパラメーターのいくつかの組み合わせでパフォーマンステストを実行しました。 IDはシナリオ番号であり、以下で参照されます。

scenarios I tried

シナリオ1として自分のマシンでデフォルトの構成で実行することから始めました。シナリオ2は私が「最も安全」であると想定するものであり、適切な場合/プロンプトに従って、さまざまな組み合わせを試しました。これはおそらく私が最終的に使用したマップで理解するのが最も簡単です：

map relating scenarios to parameters

挿入、更新、削除など、INTEGERのみ、TEXTのみ（ID列を含む）、または混在したテーブルで、多くのトランザクションを実行するテストスクリプトを作成しました。上記の各構成でこれを何度も実行しました。

plot showing timings for scenarios

下の2つのシナリオは＃6と＃17で、 "pragma Synchronization = off"があるため、最速であったことは当然です。次の3つのクラスターは、＃7、＃11、および＃19です。これらの3つは、上記の「構成マップ」で青色で強調表示されています。基本的に、設定はディスク書き込みキャッシュがオン、バリアが0、データが「ジャーナル」以外に設定されています。 5秒（＃7）と60秒（＃11）の間でコミットを変更しても、ほとんど違いはないようです。これらのテストでは、data = orderedとdata = writebackの間に大きな違いはないようで、驚いた。

混合更新テストが真ん中のピークです。このテストの方が明らかに遅いシナリオのクラスターがあります。これらはすべてdata = journalの1つです。それ以外の場合、他のシナリオの間にそれほど多くはありません。

私は別のタイミングテストを行いました。これは、さまざまなタイプの組み合わせで、挿入、更新、および削除をより異質に組み合わせたものです。これらははるかに長い時間がかかったので、上のプロットには含めていません。

mixed types and insert/update/delete

ここで、ライトバック構成（＃19）が順序付けされた構成（＃7および＃11）よりも少し遅いことがわかります。私はライトバックがわずかに速いと予想していましたが、おそらくそれはあなたの書き込みパターンに依存するか、多分私はまだext3で十分に読んでいません:-)

さまざまなシナリオは、アプリケーションが実行する操作をある程度表しています。シナリオの候補リストを選んだ後、自動テストスイートのいくつかを使用してタイミングテストを実行しました。それらは上記の結果と一致していた。

結論

commitパラメータはほとんど違いがないように見えたので、5秒のままにします。
ディスク書き込みキャッシュをオンにして、barrier = 0、data = ordered。これを悪い設定だと思ったものをオンラインで読んだり、多くの状況でこれをデフォルトにすべきだと思ったものを私は読んだ。最も重要なことは、あなたが情報交換の意思決定を行い、自分がどのようなトレードオフを行っているかを知っていることだと思います。
SQLiteでは同期プラグマを使用しません。
SQLitecache_sizeプラグマを設定して、DBがメモリに収まるようにすると、予想通り、一部の操作のパフォーマンスが向上しました。
上記の構成は、リスクが少し高くなることを意味します。 SQLiteバックアップAPI を使用して、部分書き込み時のディスク障害の危険性を最小限に抑えます。N分ごとにスナップショットを取り、最後のMを保持します。私はパフォーマンステストの実行中にこのAPIをテストしましたが、この方法を使用する自信が得られました。
さらに必要な場合は、カーネルをいじくり回すこともできますが、そこに行かなくても十分に改善されました。

さまざまなヒントやアドバイスを提供してくれた@Huygensに感謝します。