☰

ファイルをキャッシュにロードした後のファイルアクセス時間

tag-icon • tag-icon cache ram
ファイルをキャッシュにロードした後のファイルアクセス時間

私はで読んだここより高速なアクセスのために、次のコマンドを使用してファイルをRAMにロードできます。

cat filename > /dev/null

しかし、私は上記の言葉が本当かどうかをテストしたいと思いました。だから、次のテストをしてみました。

  1. 以下のように2.5GBのテストファイルを生成します。

    dd if=/dev/zero of=demo.txt bs=100M count=10

  2. 次に、次のようにファイルアクセス時間を計算します。

    mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m19.191s user 0m0.007s sys 0m1.295s

  3. コマンドが提案したように、ファイルをキャッシュメモリに追加する必要があります。だから私はそうでした。

    cat demo.txt > /dev/null

  4. ここで、ファイルがキャッシュにロードされたとします。それで、ファイルを再読み込みするのにかかる時間を計算してみました。これが私が得る価値です。

    mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m18.701s user 0m0.010s sys 0m1.275s

  5. 時間を計算するために手順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

だから私の質問は、ファイルがキャッシュにロードされても時間が変わるのはなぜですか？ファイルがキャッシュにロードされるので、各反復の時間が短縮されると予想しましたが、そうではありません。

答え1

いいえ、いいえ！

そのようなことは起こりませんでした。 Linux（カーネル）は、一部のファイルをキャッシュに保存し、必要に応じて削除することを選択できます。キャッシュに何もないのか、実際にはわかりません。このコマンドはその内容を大幅に変更しません。

あなたが提供したリンクのアドバイスは多くの点で間違っています！

  1. キャッシュはオペレーティングシステムに関するものです。この機能を利用するcatためにこのファイルは必要ありません。/dev/nullLinuxがファイルをもう一度読むように強制するので、これは実際に非常に愚かなことです。たとえば、ファイルを4回読みたい場合です。気にしないと、最初の読み取りは遅くなり、その後3つの読み取りが速くなります（キャッシュのため）。この「トリック」を使用すると、最初の読み取りが非常に遅くなります。4後続の項目はより速くなければなりません（ただし空にしてはいけません）。Linuxで処理するようにしてください。。
  2. このコマンドは、LinuxがそれをRAMに保持したい場合にのみ役立ちます。したがって、システムがアイドル状態のときに頻繁に実行する必要があります。しかし、私が言ったように、これはまた愚かなことです。 Linuxが実際にファイルをRAMにキャッシュしているかどうかはわかりません。キャッシュしても、RAMまたはディスクからファイルを読み取るのに時間がかかります（キャッシュしない場合）。 ) キャッシュされているか、すでにキャッシュされている) キャッシュから削除された)
  3. 大きなファイルに対してこれを繰り返し実行することは、基本的にLinuxが生成した他のファイルを犠牲にしてファイルがRAMに存在する必要があると思うように欺くことです。実際にもっと頻繁に使用してください。

したがって、ここで重要な点は次のとおりです。このトリックを実行しないでください。通常は非生産的です。

しかし、、RAMサイズと比較して、いくつかの小さなファイルがRAMアクセスを介して実際に利点を得ることができることがわかっている場合は、次のように使用できます。tmpfs 山そこにファイルを保存してください。最新のディストリビューションでは、/tmpフォルダは通常tmpfs。

個人的に価値があると考えるもう1つのオプションは、BTRFSを使用して、たとえばFSレベルでファイルを圧縮するか、手動でファイルを圧縮することです（ただし、ファイルにアクセスするプログラムに解凍する機能が必要です） ）。もちろん、ファイルは圧縮によって利点を得ることができます。それ以外の場合、これは役に立ちません。これにより、Linuxが圧縮されたファイルをRAM（より小さいため）に保持するという確信が得られます。アプリケーションがIOバインドされている場合、ディスクから10 GBの代わりに100 MBをロードする方がはるかに高速です。

答え2

テストを繰り返し、次のコマンドを実行しました。

dd if=/dev/zero of=/mnt/disk8/Marc/2GB.bin bs=100M count=20

次に、ターゲットがHDDであるにもかかわらず、ファイルがどれだけ早く作成されるかを確認します。

20+0 records in
20+0 records out
2097152000 bytes (2.1 GB, 2.0 GiB) copied, 0.6319 s, 3.3 GB/s

何が起こったのか:

  • ファイルはディスクに書き込まず、RAMに書き込まれます。理由：vm.dirty_ratioデフォルトは20です。これは、空きRAMの20％を書き込みキャッシュとして使用することを意味します。
  • しばらくすると、サーバーダッシュボードでHDDの書き込み速度を確認できました。理由：vm.dirty_expire_centisecs1500に設定します（私のUnraidサーバーのデフォルト値、Linuxのデフォルト値は3000）。これは、HDDへの書き込みが時間とともに移動することを意味します。

それでは、ファイルを読み取るのにかかる時間を測定しましょう。

mytime="$(time ( cat /mnt/disk8/Marc/2GB.bin ) 2>&1 1>/dev/null )"
echo $mytime
real 0m0.193s user 0m0.012s sys 0m0.181s

何が起こったのか:

  • ファイルはまだLinuxページキャッシュにあります。

これでキャッシュを消去します。

sync; echo 1 > /proc/sys/vm/drop_caches

次のベンチマークは遅いです。

real 0m8.330s user 0m0.017s sys 0m0.753s

キャッシュを消去し（ベンチマークが埋められている間）、ファイルを再度開き、コンテンツをゴミ箱に移動します（「トリック」と記載）。

cat /mnt/disk8/Marc/2GB.bin > /dev/null

次のベンチマークは高速で期待通りに機能します。

real 0m0.233s user 0m0.008s sys 0m0.225s

それがあなたに効果がない理由：

  • テスト時に利用可能なRAMがほとんどないため、ほとんどのファイルをキャッシュできません。
  • 他の読み取り操作がキャッシュファイルを上書きしました。

結論：十分なメモリが必要で、この「トリック」は長続きしません。ファイルを手動でキャッシュするのは全体的に便利ですか？時々違うよねPlex、Emby、Jellyfinなどのメディアサーバーソフトウェアを使用しているとします。彼らはすべて顧客に映画のカバーを提供する必要があります。 RAMに配置するとロード時間が速くなるため、キャッシュすることをお勧めします。 Linuxはこれを自動的に実行し、次の場所に保存します。イベント一覧頻繁にロードされる場合。しかし、今このトリックを使用することをお勧めします。使用可能なRAMと同じかそれ以上のファイルを要求すると、キャッシュは完全に上書きされます。 Linuxは大容量ファイルをスキップしません。クライアントがムービーカバーを再ロードし、アクティブリストと非アクティブリストでゲームを再起動するまで、キャッシュファイルはキャッシュされなくなりました。これが良い考えである理由は次のとおりです。O_DIRECTを使用した大容量ファイルの要求または、このトリックを使用する代わりに仮想タッチキャッシュにロックします。

関連情報