TFカード・ストレージのパフォーマンス・チューニング事例

この記事では、実際のケースに基づいたTFカードストレージのパフォーマンスチューニングのアイデアを紹介します。

この記事を読む前に、次の3つの記事を読むことをお勧めします：

これは体系的な問題であり、単一の理由によるものではなく、トラブルシューティングのプロセスにはより多くのテスト/検証が含まれ、多くの実験は複数の最適化ポイントの組み合わせです。一つの実験に時間がかかり、多くの実験が並行して行われるため、本稿ではもはや時系列の形で一歩一歩進むのではなく、すべての問題点とそれに対応するトラブルシューティングと最適化の方法を一つずつ列挙していきます。

背景

あるビデオ・ストレージ・プロジェクトで、TFカードの書き込み性能低下によるビデオ・フレーム・ロスの問題が発生しました。プロジェクトの業務ブロック図を以下に示しますが、以下の業務シナリオでフレームロスが発生します：

• 双方向ビデオストレージ、コードストリームレートは12Mbps、8Mbps、ビデオはカードがいっぱいになると、書き込みを上書きするには、ループにされている、最も古いビデオファイルを削除します。
• ファイルログ、レコードデバイスの操作情報は、理論的な速度は11.5Kbpsを超えない、ファイルサイズは、最も古いログを上書きするために、ファイル内部のセルフサイクルの上限に達した後、2MBを超えません。

記憶媒体はTFカードで、おそらくこの問題は、TFカードが周期的に上書きされ、かなり明白なパターンで一度書き込まれた後に発生します。

II.トラブルシューティングのポイントと最適化手法

まず、CPUがボトルネックになっているのか、IOがボトルネックになっているのかを確認します。

iostatコマンドでiowaitとidleの両方が高い（60％～80％）ことがわかり、基本的にIOボトルネックによる問題であることが確認できました。IOボトルネックである場合、以下の原因が考えられます：

• チップTFカードコントローラの問題
• TFカード自体が問題で、よく "カードを選ぶ "と言いますが、問題のあるカードもあれば、問題のないカードもあります。
• ビジネス・レイヤーの非論理的なカード書き込みロジックに起因する問題

TFカードのコントローラーに問題があるのでしょうか？

同じカードを使って、ddコマンドを使って異なるプラットフォームでテストし、書き込みレートを検証することができます。ddテストはキャッシュの影響を除外する必要があることに注意してください、あなたはそれをサポートしていない場合は、キャッシュをバイパスするためにdirectにoflagオプションを設定することができます、あなたはまた、fsyncにCONVオプションを設定することができます、2つの違いは次のとおりです：前者はあなたが書き込むたびにストレージメディアに直接書き込まれ、後者はまだキャッシュに入りますが、コマンドの終了前にストレージメディアにすべてのデータをフラッシュします。両者の違いは、前者は毎回直接記憶媒体に書き込み、後者はまだキャッシュに入りますが、コマンドが終了する前にすべてのデータを記憶媒体にフラッシュするということです。

また、書き込み性能はTFカードの状態などに関係するため、複数のカードで複数回検証するのがベストです。

この実験を通じて、私は私のチップと別のベンチマークチップの書き込み性能が約20％悪いことが判明し、チップTFカードコントローラの性能にまだ差があることを示しています。この問題は、サプライヤーに直接スローされ、彼らはSDカードプロトコルアナライザを介してSDカードのコマンド解析をキャッチすることができ、ここで詳細に入ることはありません。

TFカードに問題はありませんか？

ピッキング・カード」に問題がないことを確認することが重要です：問題のあるブランドやモデルもあれば、そうでないものもあります。

この問題には2つの解決策があります：

• 一つは、他のブランド/モデルのカードを直接デバイスに装着し、問題がまだ発生しているかどうかを検証することです。問題がもはや存在しない場合、それは元のカードが故障していることを証明することができ、問題がまだ存在する場合、それは何の意味もなく、他の実験と組み合わせてさらに分析する必要があります。

今回、市場に出回っているTFカードの主流ブランド/モデルをマッピングしてみたところ、カードごとの性能差はまだかなり大きく、特にランダム書き込み性能は、同じClass 10カードでも、ランダム書き込み性能が1MB/s以下のカードもあれば、ランダム書き込み速度がシーケンシャル書き込み速度を下回らないカードもあり、10MB/s以上で安定するカードもあります。これは、TFカード内部のウェアレベリングアルゴリズムとオーバープロビジョニング（Over-Provisioning）に大きく関係しています。これは、オーバープロビジョニングと同様に、TFカード内部のウェアレベリングアルゴリズムに大きく関係しています。

評価に使用した出荷用カードは、極端な場合、ランダム書き込み速度が1MB/秒程度と、中間の下の方でした。

ビジネス・レイヤーの書き込みカード・ロジックに問題はありますか？

問題のあるTFカードをddコマンドでテストしたところ、書き込み速度も低く、2MB/s前後で変動しており、ビジネス要件（12Mbps + 8Mbps = 2.5MB/s）を満たしていないことが判明しました。フォーマット後、書き込み速度が約5MB/sに達することがわかり、カードへの書き込み方法が不合理であったため、カードが低性能状態に陥ったことが間接的に証明されました。

winhexを使用して問題のファイルを分析したところ、ファイルの断片化が非常に強いことがわかりました。下の図に示すように、179MBのビデオファイルは合計1430クラスタを占めますが、1399の断片があり、基本的に連続したクラスタは残っていないほどファイルが断片化されています。他のファイルも基本的には同じです。

ファイル操作のロジックを整理すると、以下のような問題点が見つかりました：

• マルチファイル同時書き込み操作：2つのビデオファイルとログファイルの通常のシナリオは、いくつかのシナリオは、キャプチャ、緊急ビデオや他の操作に重畳され、これらのファイルの削除のタイミングが異なります。

• ドキュメントの修正にはシナリオがあります：

  • mp4ファイルは、3秒ごとに更新されるフロントインデックスを使用しています。
  • ログファイルは16KBごとにカードを書き込み、ファイル内で循環します。ファイルサイズは2MBに固定され、ファイル内で自己循環します。

• ファイル書き込み時のデータ整列の問題：mp4モジュールには256KBの出力キャッシュがありますが、インデックスを更新するとキャッシュ内のデータが空になり、データ書き込み時に整列の問題が発生します。

• キャッシュが適切に設定されず、高い割合を占め、最終的にファイルを閉じるときに、大量のデータをキャッシュから記憶媒体にフラッシュする必要があり、時間がかかります。

アイデアの最適化

• クラスタサイズを4MBに設定したのは、ブロック内に複数のファイルが存在する状況を避けようとするためです。この結果、例えばイメージファイルの実際のサイズは約1MBですが、4MBのスペースも占有することになり、ある程度スペースの無駄が生じます。
  
  
• 各書き込みカードのサイズが256KBの整数倍になるように関連コードロジックを調整し、データアライメントの問題を解決。
• ビジネス・レイヤは、各ファイル・ハンドルに2MBのデータが蓄積された後、メディアにデータを積極的にブラシします。これにより、IO圧力がファイルの書き込みプロセス全体に均等に分散され、ファイルが閉じられたときにホットスポットが発生するのを防ぎます。
• コードストリームのバッファを増やし、バッファリングを使用して、時折発生するIOホットスポットに対処します。
• ファイルを変更する頻度を減らす：mp4ファイルの場合、インデックスの更新頻度を減らしてください。カードを抜くと、ビデオファイルの最後の数秒のデータが再生できなくなります。

ストレージ性能のその他の最適化アイデア

1. TFカードのバスレートを上げてください。例えば、クロック周波数を50MHzから100MHzに上げ、理論的なレート制限を25MB/秒から50MB/秒に対応させます。
2. ビジネスレベルでバッファがない場合、setvbuffを使用してキャッシュを設定することで、断片的な書き込み操作を1つの大きな書き込み操作の塊にまとめることができ、データのアライメント問題の最適化に加えて、IO回数を減らすことができます。
3. 直接IO、基礎となるキャッシュをブロックアウト、ビジネス・レイヤーから直接、カードの書き込みタイミングを制御
4. IOを最適化するためのキャッシュ比率の調整（dirty_ratioなどのパラメータの調整など
5. ファイルシステムの性能の違いは、exFATファイルシステムなど、ヒューズとnofuseの2つのバージョンがあり、前者はユーザー状態で実装されており、後者はカーネル状態で実装されており、業界では一般的に後者は前者よりも効率的であると考えています。
6. たとえば、fflushはユーザー状態からカーネル状態へのデータのブラッシングしかできません。fsyncは、データが記憶媒体にブラッシングされることを保証できますが、メタデータも更新されます。fdatasyncはfsyncの最適化バージョンで、ファイルのサイズが変更された場合にのみメタデータを更新します。fclose/closeは、ファイルがクローズされた後にデータが記憶媒体にスワイプされることを保証しません。

詳しくはご覧ください。

3. linuxperf.com/?p=33
4. pdfs.semanticscholar.org/faf8/22b071...
5. flashdba.com/storage-for...
6. smallbusiness.chron.com/block-size-...
7. techterms.com/definition/...
8. www.anandtech.com/show/2738/7