仮想メモリ、特に物理メモリよりもはるかに大きなファイルへのメモリ マッピング ファイルを多用するプログラムがあります。
プログラムのパフォーマンスは必ずしも素晴らしいものではありません。セットアップを考えると、主要なページ フォールトが原因である可能性があります。
だから私はこれがどれほど悪いかを知りたいと思い、メジャーページフォールトの影響を見積もるプログラムを書きました。基本的に、数GBのサイズのファイルをmmapし、バイトの読み取りにかかる時間を測定しながら、ランダムなバイト数を読み取ります。
ファイルがキャッシュにない可能性が高いかどうか (echo 3 > /proc/sys/vm/drop_caches) と、キャッシュにある場合に応じて、全体の実行時間だけでなく、累積またはヒストグラム分析されたアクセス時間にも大きな違いがあることがわかります。テスト プログラムの 2 回目の実行で既にキャッシュに入っています。
さらに、出力を見てみますが/usr/bin/time -v、これらの数字は紛らわしいです (簡潔にするために一部の行が切り取られています)。
User time (seconds): 0.66
System time (seconds): 3.66
Percent of CPU this job got: 3%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:17.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1593920
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 7672
Minor (reclaiming a frame) page faults: 93641
File system inputs: 5094600
File system outputs: 200
Page size (bytes): 4096
Exit status: 0
次の質問に誰でも答えられますか？
- ページには 4k があり、7672 のメジャー ページ フォールトがあります。これらはわずか 30MB です。(そうでなければ非常に高速な) smb ファイル システム上であっても、それらをページインするのに 2 分以上かかることはありません。
- 「ファイル システム入力」とは何を意味しますか? プログラムは、ファイル システムへの入力を行いません。この 2.8 GB ファイルをマップしましたが、read() は実行しません。これは読み取り数ですか、それとも kB ですか? 主要なページ フォールトと何らかの関係がありますか?
- 100k に近いマイナー ページ フォールトは、プログラムが実行する 100k のプローブ (1 バイト読み取り) とうまく一致しています。このマシンでは、実際には drop_caches を実行できません。別のファイルでプログラムを実行して、データをプッシュする必要があります。私は働いていないかもしれません。これは、ほとんどの場合、マイナーなページ フォールトがあることを説明している可能性があります。しかし、なぜこれに時間がかかるのでしょうか。100k プローブによる 2:17 分という率直な見積もりでは、1.37 ミリ秒になります。これは、マイナー ページ フォールトの「通常の」大きさですか?
編集：もう1つ試してみました。テスト プログラムを再度実行し、すべてのシステム コールを strace で記録しました。プローブ中に表示されるのは、clock_gettime、gettimeofday、futex だけです。read(2) がまったくないので、/usr/bin/time によって提供される「ファイル システム入力」、メジャーおよびマイナー フォールト番号が互いにどのように関連しているかについてさらに疑問に思います。