ホスティング会社の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が同期されない可能性があります。そのようなスナップショットの整合性をどのように(できるのでしょうか)保証できますか?
他に検討すべきオプションはありますか?
ありがとう
最初のアドバイス
データを失うわけにはいかない場合(つまり、ユーザーが新しいデータを入力した後、数秒で失われない場合)、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に別の値を試してくださいdata=ordered,barrier=1
を使用しますが、他の調整可能パラメータを試してください。特に ファイルシステムのエレベーター (CFQ、DeadlineまたはNoop)とそれらの再調整可能な調整可能パラメータ。ext4への移行とベンチマークの検討
前述のように、ext4は書き込みにext3よりも少ないバリアを必要とします。さらに、ext4はエクステントをサポートしているため、大きなファイルの場合、パフォーマンスが向上する可能性があります。したがって、再インストールせずにext3からext4に簡単に移行できるため、これは検討に値するソリューションです。 official documentation ;私は1つのシステムでそれを行いましたが、これを使用しました Debianガイド 。 Ext4はカーネル2.6.32以降は非常に安定しているため、本番環境で使用しても安全です。
最後の考慮事項
この回答は完全とはほど遠いですが、調査を開始するのに十分な資料を提供します。これは要件に大きく依存しているため(ユーザーレベルまたはシステムレベル)、申し訳ありませんが、簡単な答えを出すのは困難です。
警告:以下の不正確さがあるかもしれません。私はこれからたくさんのことを学んでいるので、塩を少し入れてください。これはかなり長いですが、操作しているパラメータを読んで、最後の結論にスキップすることができます。
SQLiteの書き込みパフォーマンスを心配できる層はいくつかあります。
太字で強調表示されているものを確認しました。特定のパラメータは
ext3ドキュメント でext3オプションの詳細を読んでください。
これらのパラメーターのいくつかの組み合わせでパフォーマンステストを実行しました。 IDはシナリオ番号であり、以下で参照されます。
シナリオ1として自分のマシンでデフォルトの構成で実行することから始めました。シナリオ2は私が「最も安全」であると想定するものであり、適切な場合/プロンプトに従って、さまざまな組み合わせを試しました。これはおそらく私が最終的に使用したマップで理解するのが最も簡単です:
挿入、更新、削除など、INTEGERのみ、TEXTのみ(ID列を含む)、または混在したテーブルで、多くのトランザクションを実行するテストスクリプトを作成しました。上記の各構成でこれを何度も実行しました。
下の2つのシナリオは#6と#17で、 "pragma Synchronization = off"があるため、最速であったことは当然です。次の3つのクラスターは、#7、#11、および#19です。これらの3つは、上記の「構成マップ」で青色で強調表示されています。基本的に、設定はディスク書き込みキャッシュがオン、バリアが0、データが「ジャーナル」以外に設定されています。 5秒(#7)と60秒(#11)の間でコミットを変更しても、ほとんど違いはないようです。これらのテストでは、data = orderedとdata = writebackの間に大きな違いはないようで、驚いた。
混合更新テストが真ん中のピークです。このテストの方が明らかに遅いシナリオのクラスターがあります。これらはすべてdata = journalの1つです。それ以外の場合、他のシナリオの間にそれほど多くはありません。
私は別のタイミングテストを行いました。これは、さまざまなタイプの組み合わせで、挿入、更新、および削除をより異質に組み合わせたものです。これらははるかに長い時間がかかったので、上のプロットには含めていません。
ここで、ライトバック構成(#19)が順序付けされた構成(#7および#11)よりも少し遅いことがわかります。私はライトバックがわずかに速いと予想していましたが、おそらくそれはあなたの書き込みパターンに依存するか、多分私はまだext3で十分に読んでいません:-)
さまざまなシナリオは、アプリケーションが実行する操作をある程度表しています。シナリオの候補リストを選んだ後、自動テストスイートのいくつかを使用してタイミングテストを実行しました。それらは上記の結果と一致していた。
さまざまなヒントやアドバイスを提供してくれた@Huygensに感謝します。