ディスク書き込みキャッシュ機能と制限付きRAM Windows 10 Proでの使用-256GB DDR4
印象のマテリアルフローをシミュレートするために使用するWindows 10 Professionalワークステーションがあります。私が使用するFEAソフトウェアは、実行するシミュレーションごとに50〜100 GBの大きなデータベースファイルを作成します。これらのファイルをストレージ用のスピニングメディアにコピーすると、転送中にこのシステムが持つRAMの量を活用できず、1秒または2秒で開始して、2つのRAID0 7200RPMディスクのネイティブ転送速度に低下します。 300 MB /秒（171〜342秒）。ファイルは、2つの1.2TB Intel 750 PCIe NVMe SSD上の2つの600GBパーティションのソフトウェアRAID0から取得されるため、読み取りパフォーマンスは問題ではありません。システムはEBMを備えた2200VA UPSにあり、毎晩ストレージサーバーにバックアップされるため、データ損失の心配はありません。
私が疑問に思っているのは：
Windows 10のキャッシュ設定を微調整して、50〜100 GBのファイル全体をRAMに4 GB /秒（12〜25秒）で読み取ることができる場合、2つのIntel 750が可能で、それらを透過的にディスクに書き込みます。 。組み込みのWindows機能「ディスクキャッシング」でこれが可能であるように見えますが、Windowsの一部のデフォルトのキャッシュサイズ設定により、キャッシュが約5 GBに制限されています（そのため、最初は速度がわずかにバーストしています） ）。 「変更された」物理メモリの使用量は、転送の最初の1秒程度で最大5GB増加するため、このメッセージは宛先ドライブの惨めな128MBキャッシュから発生するとは思わない。転送ダイアログボックスが消えた後、その5GBがディスクに書き込まれているのがわかります。 RAM使用率は、RAID0の2つの7200RPMドライブの速度に応じて減少します。完了すると、ディスクアクティビティがゼロになり、RAM使用率が通常に戻ることがわかります。これは、ディスクキャッシングが少なくとも5GBに制限されて機能していることを示しています。
シミュレーションは通常最大80GBのRAMしか使用せず、シミュレーションはその量までRAMを使用しないので、システムはこの転送に使用可能な50-100GB RAMを使用して問題ありません。シミュレーションの最終段階。
次の仕様のDell Precision T7910ワークステーションを使用しています
2P Xeon E5-2687W v4
256GB LRDIMM ECC DDR4 2400MHz
Quadro M4000
x2 Intel 750 1.2TB PCIe NVMe, one boot, 600GB RAID0 Two Partitons
x2 WD Gold 8TB in software RAID0 on SAS 12 GB Ports (128MB Cache)
Eaton 5PX 2200 IRT 240V UPS
Windows 10 Pro 1703 - System is old enough to not have Windows 10 Pro for Workstations
私が試したこと：
Checked/Enabled: "Enable write caching on the device." - On each Disk
Checked/Enabled: "Turn off Windows write-cache buffer flushing on the device." - On each Disk
Made sure Superfetch service is running (for whatever good that does).
Moved away from built-in hardware RAID, as there is NO cache anyway.
私は同様の問題を持つ他のトピックを調査し、「CacheSet」ツールについて言及している別の古いスレッドに遭遇しました：
これは私のユースケースに当てはまるのでしょうか、それとも調査し続ける必要がありますか？
Windowsプラットフォームでのディスクキャッシングが正しく機能することについての理解はありますか、それとも予期したとおりに動作しませんか？メインメモリへの書き込みキャッシュを探しています。100GBまでのRAMを使用しているだけです。
ご協力ありがとうございました！どんな提案も大歓迎です。
EDIT：ADMINが "ピークサイズ"の "663732 KB"を報告するため、そのcacheset.exeソフトウェアを実行すると小さすぎる（648MB？）と報告されます。この設定の変更をコミットし、この運用中のシステムを混乱させる可能性があることを確信できません。私が実行し続ける制限は、約5GBです。
DOUBLE EDIT：実際にキャッシュされているように見えるGBを修正しました。重要なのは、「Modified Physical Memory」に注目し、転送の開始時に約5 GBの「上限」を確認することでした。まだこれを100GB程度に増やすことを検討しています。
ありがとうございました！
キャッシュを大きくしても、標準のファイルコピーアプリでは効果がありません。
Windowsファイルキャッシュの大きさに関係なく、すべてのデータが宛先に書き込まれる前に、適切なファイルコピーツールはコピータスクの入力ファイルを閉じません（それらを削除できます）。これは、入力データ全体がキャッシュに読み込まれた場合でも当てはまります。
その理由は、キャッシュ内のデータは安全ではないためです-いつでも消える可能性があります。 RAMディスクから読み取られてから変更されていないキャッシュによって使用されたものは、メモリマネージャーによって破棄可能と見なされます。つまり、何か他にRAMが必要な場合、RAMは、キャッシュから取得して「再利用」することができます。つまり、いつでも別の何かに与えることができます。もちろん、それは可能です-結局のところ、どこにもデータがあるはずはありませんonlyキャッシュ内（ディスクから読み取られてから変更されている場合を除きます。その場合、4秒以内に自動的にライトバックのキューに入れられます。ライトバックが完了するまで再利用できません）。
したがって、標準のコピープログラムでは、キャッシュ内のバッファ量に関係なく、ソースファイルを削除する前に、回転ディスクがデータを書き込むのを待つ必要があります。
コピープログラム（またはその他のアプリ）は、キャッシュに何かが存在するかどうかを見つけることさえできないことに注意してください。そのためのインターフェースはありません。たとえあったとしても、アプリがそれを見る前であっても、その情報は取得された瞬間に「古くなった」と見なされます。ファイルキャッシュは自動的に機能し、アプリに対して透過的であることが想定されています。透過性の一部は、コントロールがほとんどないことです。
このように考えてください：結果のsafe中間コピーが必要です-別のディレクトリにあるソースファイルの別のコピーと機能的に同等のものオリジナルを安全に削除する前に、個別のドライブ文字を使用することもできます。 Windowsファイルキャッシュは決してそれを与えません。 Windowsが元のファイル全体をファイルキャッシュに丸呑みすることを決定したとしても（非常にありそうもありません）、ファイルキャッシュはそれを提供しません。
（とにかく、「とにかく何がいいの？」と思っているかもしれません。ファイルキャッシュの主な目的は、繰り返しアクセスを多数のsmallファイル（およびファイルシステムメタデータ）を高速化します。
SuperFetch
TL、DRバージョン：SuperFetchはそれも提供しません。
SuperFetchについてのあなたの表明された疑念は正しいです。 SuperFetchはそれが何をしようとしているかには効果的ですが、この場合は役に立ちません。 SuperFetchが行うことは、頻繁にアクセスされるファイルを追跡することです。たとえば、起動ごとに、必要に応じて、それらをRAM）に読み取ってみます。
この違いは、Windowsキャッシング全般を理解したい場合に重要です。 Windowsファイルキャッシュ（前のセクションで説明したもの）はreactiveであり、プログラムが実際に試行するまで何もキャッシュしませんそれを読む。最初のリリース（NT 3.1）以降、Windows NTファミリに含まれています。
SuperFetchは別個のメカニズムで、元々はVistaで追加されました。これはproactiveであり、過去に頻繁にアクセスされていることが確認されているものをプリフェッチしようとしています。
SuperFetchは、そのRAMをWindowsファイルキャッシュとは別に管理します。SuperFetchは、Windowsスタンバイページリストの「優先順位の低い」ページを使用します-おかしいことに、リストに残っているだけなので、そのまま残ります。 「利用可能な」RAMの一部です（他のすべての条件が同じであっても、SuperFetchを有効にしていない場合、「利用可能な」RAMの違いに気付くことはありませんが、報告された「キャッシュ」の量。）ファイルキャッシュに割り当てられたRAMはワーキングセットに含まれるため、必要に応じて、再利用に少し時間がかかります。この設計のため、SuperFetchキャッシュは、Windowsファイルキャッシュよりも「破棄可能」であり、ファイルキャッシュよりも安全な一時的なコピーを提供しません。
だからできること何ができる？
あなたの問題を解決するために、専用のハードウェアを探しています。たぶん、120 GBというそれほど高価でも高速でもないSSDを1つ取得して、SSDアレイからそのデータをデータにコピーし、そこからハードドライブにコピーします。これは悲しいかな、すべてのデータが一時ファイルにコピーされるまでハードドライブへの書き込みを開始できないことを意味します。そのため、これは現在実行しているものよりも時間がかかります。ただし、ソースデータはより早く解放されます。
より簡単なアイデアは、より多くのハードドライブを取得し、それらをより大きなストライプセットに配置して、書き込みスループットを向上させることです。
データの構造を知っている専用のコピープログラムが役立つ場合があります。
ところで、FEAソフトウェアがデータセットの作成時にマップされたファイルアクセスを使用していることを願っています。これは、従来の読み取り/書き込み呼び出しよりもはるかに高速です。
これは少し遅れますが、PrimoCache（以前のFancyCache）と呼ばれるプログラムを使用して、必要なことを実行できます。ボリュームを予備のSSD（または600 GBの高速NVMe RAID0アレイに配置しますが、冗長性がない限り少し危険です...）をレベル2キャッシュとして設定し、それを介して特定の遅いボリュームへのキャッシュの読み取りと書き込みを行います。そのボリュームへの書き込みは、最初に高速ボリュームを介して透過的にキャッシュされます。もちろん、書き込み中にキャッシュボリュームが失敗した場合は、データが破損していますが、それは避けられない犠牲です。正確にそれが何であるかについてあなたが選択しているなら、それは関連する最小限のリスクで非常に効果的であることができます。適切なサイズのキャッシュボリューム（256GBでおそらく十分以上）を使用すると、頻繁にアクセスされるブロックの低速および大容量のメカニカルアレイで、SSDに近いパフォーマンスを実現できます。 SSDの書き込み回数には制限があることにも注意してください。その場合は、最悪の場合、それを交換してキャッシュを再設定します。HDDボリュームへの書き込み中にエラーが発生すると、データが失われる可能性があります。 SSDを使用する代わりに、同じプログラムを使用してレベル1キャッシュをRAMに作成することもできます。これはさらに高速ですが、RAMを使い果たします。
もちろん、より優れたソリューションは、ワークステーションにVMWare ESXをインストールし、VMをプロビジョニングして、最大のパフォーマンスとスケーラビリティを得るために、ストレージアレイを希望どおりに構成することです。 VMにWindowsをインストールし、vSphere Clientを介してリモートでアクセスします。これにより、オペレーティングシステムの下で、ハードウェアのできるだけ近くでキャッシュが実行されます。