以下のコマンドを使用してより高速にアクセスするために、ファイルをRAMにロードできることを ここ から読みました。
cat filename > /dev/null
ただし、上記の説明が本当に正しいかどうかをテストしたかったのです。そこで、以下のテストを行いました。
以下のように2.5GBのテストファイルを作成します。
dd if=/dev/zero of=demo.txt bs=100M count=10
ここで、ファイルアクセス時間を以下のように計算します。
mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m19.191s user 0m0.007s sys 0m1.295s
コマンドが示唆するように、今度はファイルをキャッシュメモリに追加する必要がありました。だから、私はしました、
cat demo.txt > /dev/null
ここで、ファイルがキャッシュにロードされていると仮定します。そこで、ファイルを再度ロードする時間を計算します。これが私が得た価値です。
mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m18.701s user 0m0.010s sys 0m1.275s
ステップ4をさらに5回繰り返して時間を計算しました。これらは、取得した値です。
real 0m18.574s user 0m0.007s sys 0m1.279s
real 0m18.584s user 0m0.012s sys 0m1.267s
real 0m19.017s user 0m0.009s sys 0m1.268s
real 0m18.533s user 0m0.012s sys 0m1.263s
real 0m18.757s user 0m0.005s sys 0m1.274s
だから私の質問は、ファイルがキャッシュにロードされても時間が変わるのはなぜですか?ファイルがキャッシュにロードされるので、各反復で時間が下がるはずですが、そうではないようです。
いやいやいや!
これはそれが行われる方法ではありません。 Linux(カーネル)は、いくつかのファイルをキャッシュに入れ、必要なときにいつでもそれらを削除することを選択できます。何かがキャッシュにあるかどうかを本当に確認することはできません。そして、このコマンドはそれを(大きく)変更しません。
あなたが提供したリンクのアドバイスは、多くの点で非常に間違っています!
/dev/null
にcat
する必要はありません。 Linuxにファイルをもう一度読み取るように強制しているため、これは実際には非常に愚かなことです。たとえば、1つのファイルを4回読み取る予定の場合です。それを気にしない場合、最初の読み取りは非常に遅くなり、後続の3つの読み取りは速くなるはずです(キャッシュのため)。この「トリック」を使用している場合、最初の読み取りは非常に遅くなり、4以降の読み取りはすべて高速になります(ただし、nullではありません)。 Linuxに処理させるだけです。したがって、ここでの結論は、この種のトリックを行わないでください。これは通常、逆効果です。
ただし、(RAMサイズと比較して)いくつかの小さなファイルがRAMからアクセスすることで本当にメリットがあることがわかっている場合は、 tmpfs
mount を使用して、ファイルをそこに保存できます。最近のディストリビューションでは、/tmp
フォルダーは通常tmpfs
フォルダーです。
私が個人的に価値があると思ったもう1つの方法は、たとえばBTRFSを使用してFSレベルでファイルを圧縮することです(ただし、これには、ファイルにアクセスするプログラムがファイルを解凍する機能が必要です)。もちろん、ファイルは圧縮の恩恵を受けるはずです。そうでなければ、これは役に立ちません。このようにすると、Linuxが圧縮ファイルをRAMに保持し(サイズが小さいため)、アプリケーションがIOバインドされている場合は、10GBではなく100MBをディスクからロードすることを確信できます。はるかに高速である必要があります。