ファイルシステム集約的なスクリプトがRAMディスクから高速ではない理由

ファイルシステム集約的なスクリプトがRAMディスクから高速ではない理由

多くのファイルやディレクトリを生成するスクリプトがあります。このスクリプトは、多数のファイルとディレクトリを処理するプログラムのブラックボックステストを実行します。テスト回数が増え、テスト時間が長すぎます(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も同様です。これは仕事に適したツールではありません。

おすすめ記事