ファイルシステムを集中的に使用するスクリプトが RAM ディスク上で高速化されないのはなぜですか

ファイルシステムを集中的に使用するスクリプトが RAM ディスク上で高速化されないのはなぜですか

多数のファイルとディレクトリを作成するスクリプトがあります。このスクリプトは、多数のファイルとディレクトリで動作するプログラムのブラック ボックス テストを実行します。テスト数が増え、テストに時間がかかりすぎました (2 秒以上)。テストは RAM ディスクで実行していると思いました。

私はテストを で実行しました/dev/shm。不思議なことに、実行速度は速くなりませんでした。平均実行時間は、通常のハードディスクとほぼ同じでした。また、Perl で書かれたヒューズベースの RAM ディスク. ウェブサイトは消えてしまいましたが、インターネットアーカイブヒューズ 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 で行われ、ファイル システムはキャッシュされます。このルールには例外もありますが、これらのかなり特殊なケースは通常、非常に特殊な要件から生じます。したがって、キャッシュのフラッシュが開始されるまで、違いはわかりません。

もう一つは、パフォーマンスはたくさん正確なファイル システムに基づいて、大量の小さなファイルへのより容易なアクセスを目的としたもの、大きなファイルとの間のリアルタイム データ転送 (マルチメディア キャプチャ/ストリーミング) を効率的に行うもの、データの一貫性を重視するもの、メモリ/コード フットプリントを小さくするように設計できるものなどがあります。

ユースケースに戻ります。1回のループパスで約20の新しいプロセスが生成され、そのほとんどは1つのディレクトリ/ファイルを作成するだけです(()サブシェルを作成し、一致するたびにfind生成することに注意しcatてください)。ボトルネックは実際にはファイルシステムではありません(システムが自動調整エントロピーの高速なソースがなければ、システムのランダム性プールもかなり早く枯渇してしまいます。Perl で書かれた FUSE についても同じことが言えます。これはこの作業に適したツールではありません。

答え2

テストが主に小規模なトランザクションで構成されているという私のコメントよりもやや長い応答です。

テストするには作業負荷が不十分

ファイルシステムのストレステストを行う場合は、より大きな作業セットが必要になります。

マシンに搭載されているメモリの量にもよりますが、フォルダ作成操作を何万回行っても、両者の間に目立った違いは見られません。そのため、バッファとして使用されるメモリを考慮して、ワークロードを変更し、ファイルシステムを十分にテストしてください。

システム RAM の利点やテスト結果を歪めるその他の要素を無効にするテストを考案する方法はさまざまです。

または、bonnie++のような標準化されたテストスイートを使用することもできます。

関連情報