多くのファイルやディレクトリを生成するスクリプトがあります。このスクリプトは、多数のファイルとディレクトリを処理するプログラムのブラックボックステストを実行します。テスト回数が増え、テスト時間が長すぎます(2秒以上)。ラムディスクでテストを実行していると思いました。
でテストを進めました/dev/shm
。奇妙なことは、より速く実行されないことです。平均実行時間は通常のハードドライブとほぼ同じです。私も試しましたPerlで書かれたヒューズベースのRAMディスク。サイトはなくなりましたが、残ります。インターネットアーカイブ。 Fuse RAMディスクの平均ランタイムははるかに遅いです。たぶんPerlコードの実装が理想的ではないからです。
私のスクリプトの単純化されたバージョンは次のとおりです。
#! /bin/sh
preparedir() {
mkdir foo
mkdir bar
touch bar/file
mkdir bar/baz
echo qux > bar/baz/file
}
systemundertest() {
# here is the black box program that i am testing
# i do not know what it does exactly
# but it must be reading the files
# since it behaves differently based on them
find $1 -type f -execdir cat '{}' \; > /dev/null
singletest() {
mkdir actual
(cd actual; preparedir)
systemundertest actual
mkdir expected
(cd expected; preparedir)
diff -qr actual expected
}
manytests() {
while read dirname; do
rm -rf $dirname
mkdir $dirname
(cd $dirname; singletest)
done
}
seq 100 | manytests
実際のスクリプトは、より多くのエラーチェック、結果の収集、および要約を実行します。これはfind
私がテストしている実際のプログラムのダミープログラムです。
私のファイルシステム集約的なスクリプトがメモリサポートファイルシステムでなぜそれほど速く実行されないのか疑問に思います。 Linuxカーネルがファイルシステムキャッシュを非常に効率的に処理し、実際にはメモリベースのファイルシステムであるからでしょうか?
答え1
通常、すべてのタスクは最初にRAMで発生します。つまり、ファイルシステムがキャッシュされます。この規則には例外がありますが、これらのやや特殊な状況は通常、非常に具体的な要件に由来します。したがって、キャッシュフラッシュを開始するまでの違いはわかりません。
もう一つのことは、パフォーマンスが次に依存することです。たくさん正確なファイルシステムで - いくつかの目標は、多数の小さなファイルへのより簡単なアクセスであり、一部は大容量ファイルの効率的なリアルタイムデータ転送(マルチメディアキャプチャ/ストリーミング)であり、一部はデータの一貫性を強調し、一部は設計可能です。小さなメモリがあります。 /コードフットプリント。
ユースケースに戻り、ループ内に約20の新しいプロセスを作成し、そのほとんどは単一のディレクトリ/ファイルのみを生成します(()
サブシェルは一致するたびに作成およびfind
生成されますcat
)。ボトルネックは実際にはファイルシステムではありません。あなたのシステムが使用するASLRそして、速いエントロピー源がないので、システムのランダム性プールも非常に迅速に枯渇します。 Perlで書かれたFUSEも同様です。これは仕事に適したツールではありません。
答え2
主に小規模な取引で構成されたテストに対する私の意見より少し長い答えです。
テストする操作が不十分です。
ファイルシステムをストレステストするには、より大きなワークセットが必要です。
ボックスにどのくらいのメモリがあるかに応じて、数十または数千のフォルダ作成操作でさえ、顕著な違いはありません。したがって、バッファとして使用されるメモリを考慮して、ファイルシステムを完全にテストするようにワークロードを変更します。
システムメモリの利点とテスト結果に影響を与える可能性がある他の要素を相殺するためにテストを設計する方法はいくつかあります。
あるいは、bonnie ++などの標準化されたテストツールバーを使用することもできます。