☰

메모리가 충분함에도 불구하고 디렉토리 순회 캐시가 제거됩니까?

tag-icon • tag-icon linux directory cache
메모리가 충분함에도 불구하고 디렉토리 순회 캐시가 제거됩니까?

나는 거대한 Mercurial 저장소를 가지고 있습니다. (디렉토리가 얼마나 많은지 추측해보세요. 생각보다 많습니다.) 기본 리포지토리 작업을 수행하는 데 필요한 시간은 다음 예에 표시된 것처럼 시스템 버퍼 캐시가 핫인지 콜드인지에 따라 크게 달라집니다(하나의 명령이 다른 명령으로 실행됨).

bash> time hg status

real    0m41.809s
user    0m0.815s
sys     0m0.217s

bash> time hg status

real    0m0.858s
user    0m0.679s
sys     0m0.175s

며칠 동안(재부팅하지 않고) 머신을 사용하지 않으면 캐시가 차가워지고 다시 실행하는 데 오랜 시간이 걸립니다 hg status. 디렉터리가 전혀 또는 거의 변경되지 않았지만(mtimes를 확인하여 확인) RAM이 많이 있습니다(페이지 캐시를 세는 것조차 모두 사용되지는 않습니다. 로 확인 free).

그러면 메모리 부족이 없는데 왜 dentry 또는 inode 캐시에서 항목이 제거됩니까? 어딘가에 최대 크기가 있나요? 흥미롭게도 저는 free4GB보다 큰 "버퍼" 열을 본 적이 없습니다 . 시스템이 버퍼 캐시가 이 값보다 커지는 것을 거부하는지 확실하지 않습니다.

답변1

디렉터리 탐색에 가장 중요한 캐시는 inode 캐시입니다. 이는 free표시된 "캐시" 그래프 에 포함되지 않습니다 . 이는 커널 데이터("평평한"). 각 슬래브 풀이 차지하는 메모리 양을 확인할 수 있습니다 /proc/slabinfo(이에는 루트 액세스가 필요함). 를 slabtop사용하여 실시간으로 변경되는 것을 확인하거나 다음 코드 조각을 사용하여 각 풀 크기에 대한 보고서를 바이트 단위로 얻을 수 있습니다.

</proc/slabinfo awk '{print $1, $3*$4}' |sort -k2n

일반적인 시스템에서는 inode 캐시에 대한 압력이 밤마다 발생합니다.데이터베이스 갱신일하다. 이를 피할 수 있는 방법을 찾으신다면,알려줘요.

inode 캐시 풀의 크기는 고정되어 있지 않으며 메타데이터 캐시와 데이터 캐시의 비율에 따라 결정됩니다.vm.vfs_cache_pressure범위. 이것을 시도해 볼 수도 있습니다. 더 낮은 값(기본값은 100)을 사용하여 캐시에 더 많은 항목을 유지하여 야간 크론 작업의 항목이 hg대체되지 않도록 하거나 더 높은 값을 사용하여 야간 크론 작업의 항목이 대체되지 않도록 합니다. 항목은 대체되지 않습니다. RAM을 오염시키기 위해 남겨졌습니다.

hg status마지막으로 아침에 크론 작업으로 실행하는 방법이 항상 있습니다.

관련 정보