web-dev-qa-db-ja.com

ファイルバックアップ、ロックされた共有メモリとディスクの相互作用

HTTPアクセラレータであるVarnishは、メモリにmlock（）される最大80MBのファイルでバックアップされたSHMログを使用します。 Varnish docs 不要なディスクアクセスを避けるために、ファイルをtmpfsに保存することをお勧めします。ただし、ファイル全体がメモリにロックされている場合でも、Linuxカーネルはバッキングファイルに書き込みますか？

Inotifyとfatraceを使用してこれを監視しようとしましたが、この相互作用はおそらくすべてカーネル内で発生するため、これらのツールにはファイルアクティビティは表示されませんでした。 lsでバッキングファイルを監視するとファイルの時間が変化し、sha1sumは内容が変化していることを示したため、ファイルまたはファイルシステムのいずれかに何らかの更新が行われていることは明らかですが、これには実際にディスクアクセスが含まれるのでしょうか、それともすべてが発生するのでしょうか。メモリ？

SHMを使用してSHMをバックアップすることは、存在すらしない可能性のある問題に対する醜い回避策のように思われるため、基本的にはtmpfsの回避策を実行する必要がないようにしています。

linux-kernelshared-memorymmap
7
user195311

Varnishは、共有メモリにプレーンメモリマップファイルを使用しているようです（たとえば、POSIX shm_openの代わりに）。から ソース ：

loghead = mmap(NULL, heritage.vsl_size,
    PROT_READ|PROT_WRITE,
    MAP_HASSEMAPHORE | MAP_NOSYNC | MAP_SHARED,
    heritage.vsl_fd, 0);

BSDでは、MAP_NOSYNCは、強制されない限り（たとえば、メモリを解放するために）、カーネルが共有データをディスクに書き込まないように要求します。それが同様にロックされているとき、それはほとんど起こらないはずです。残念ながら、LinuxはMAP_NOSYNCをサポートしていません。

そのため、Linuxは、汚れた（変更された）ページをキャッシュからディスクに定期的に書き込むことになります。キャッシュをtmpfsに置くと、それを回避できます。 POSIXまたはSysV共有メモリを使用するVarnishも同様です（実際、POSIX共有メモリはLinuxに実装されており、tmpfsは/dev/shmにマウントされているため、tmpfsを使用しても問題ありません）。

4
derobert