私はAPUEの例に取り組んでいます。 NetBSD 9.0システムでは、負荷がかからない状態で呼び出し時間を測定しましたが、それほどgrep
印象的ではありませんでした。
apue$ cd /usr/include
apue$ time -p grep __POSIX_SOURCE */*.h > /dev/null
real 0.73
user 0.01
sys 0.63
ただし、実験を数回繰り返すと、システム時間が劇的に増加します(最大15倍)。
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 0.57
user 0.02
sys 0.54
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 10.06
user 0.01
sys 10.04
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 3.57
user 0.01
sys 3.56
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 4.58
user 0.00
sys 4.58
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 5.56
user 0.02
sys 5.53
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 6.57
user 0.00
sys 6.56
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real 2.56
user 0.01
sys 2.54
これが予想される動作ですか?このような大きな違いが発生するのはなぜですか?
修正する @Timが提供した答えに基づいて私のBuffercacheを見てみると、grepが検索に苦労している間に100%に完全に割り当てられたことがわかりました。仮想マシンを再起動した後、バッファ使用量は約95%に低下しました。
$ sysstat bufcache
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
603 metadata buffers using 5565 kBytes of memory ( 0%).
15512 pages for cached file data using 62048 kBytes of memory ( 3%).
3034 pages for executables using 12136 kBytes of memory ( 1%).
6460 pages for anon (non-file) data 25840 kBytes of memory ( 1%).
468172 free pages 1872688 kBytes of memory (93%).
File System Bufs used % kB in use % Bufsize kB % Util %
/ 577 95 5378 97 5418 97 99
Total: 577 95 5378 97 5418 97 99
答え1
読み取りキャッシュ(ファイルシステムバッファキャッシュ、buffercache(9)を参照)を使い果たすことは可能ですか?
最初のステップでは、キャッシュはほとんど空であるため、ページのみが追加されます。キャッシュがいっぱいになると、キャッシュから削除する必要があるページを決定するために、一種の最近使用(LRU)アルゴリズムを実行する必要があります。コードが操作を完了するには(追加)時間が必要です。
これらのテストを実行しながら、メモリ状態を監視して、速度の低下が空きメモリがゼロに達するのと一致することを確認してください。