☰

`sync + drop_caches`가 캐시를 삭제하지 않는 이유는 무엇입니까?

tag-icon • tag-icon linux-kernel performance cache benchmark
`sync + drop_caches`가 캐시를 삭제하지 않는 이유는 무엇입니까?

테스트 케이스가 있어요journalctl디스크에서 읽는 데 몇 초가 걸립니다.. 하지만 테스트 케이스를 여러 번 실행해 벤치마킹해 보면 첫 번째 실행 이후 엄청나게 빠른 것을 알 수 있습니다. 캐시를 삭제하려고 해도. 왜?

$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount
1
0.01user 0.03system 0:04.50elapsed 1%CPU (0avgtext+0avgdata 30956maxresident)k
95424inputs+0outputs (424major+665minor)pagefaults 0swaps
$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount >/dev/null
1
0.00user 0.01system 0:00.08elapsed 26%CPU (0avgtext+0avgdata 31832maxresident)k
94992inputs+0outputs (422major+445minor)pagefaults 0swaps

흥미롭게 time도 여전히 페이지 폴트( )를 통해 많은 IO를 수행하는 것으로 나타났습니다 inputs. drop_caches실행 사이의 시간을 건너뛰면 0이 표시되는 것으로 나타났습니다 .

답변1

drop_caches커널 파일 시스템 캐시에만 영향을 미칩니다. 기본 하드웨어의 캐시에는 영향을 미치지 않습니다. 분명히 귀하의 하드웨어에는 수백 메가바이트의 캐시(94992 * 4096 ~= 400MB)가 있습니다. 놀라운!

내 경우에는 커널이 가상 머신에서 실행되고 있었기 때문이었습니다. 따라서 "기본 하드웨어"는 단순한 하드 드라이브가 아닙니다. 사용된 디스크 설정에 대해 설명합니다 virt-manager.

"캐시 모드" 옵션은 쓰기 플러시(사용됨 fsync())를 존중하지만, 그렇지 않으면 호스트 코어의 페이지 캐시에 쓰기 및 읽기가 캐시되도록 허용합니다. "기본 하드웨어"는 실제로 호스트 RAM 내의 디스크 캐시로 구성되며, 이는 수 기가바이트까지 증가할 수 있습니다.

libvirt/KVM은 이를 "writeback" 캐싱이라고 합니다.

또한 이로 인해 VM을 다시 시작하는 속도가 빨라지는 것으로 나타났습니다.

관련 정보