실제 로컬 하드 디스크(네트워크 마운트가 아님)인 동일한 드라이브에 있는 실제 파일을 가리키는 약 200만 개의 심볼릭 링크가 있는 디렉터리가 있습니다. 파일 이름은 모두 고유하며 해당 파일이 가리키는 파일은 여러 디렉터리에 분산되어 있지만 모두 동일한 상위 경로를 공유합니다. 심볼릭 링크를 사용하여 여러 디렉터리의 파일을 통합하고 있습니다.
/some/full/path/consolidated/my_file -> /some/full/path/mydir2/my_file
/some/full/path/consolidated/my_file2 -> /some/full/path/mydir3/my_file2
/some/full/path/consolidated/my_file3 -> /some/full/path/mydir4/my_file3
/some/full/path/consolidated/my_file4 -> /some/full/path/mydir4/my_file4
/some/full/path/consolidated/my_file5 -> /some/full/path/mydir2/my_file5
/some/full/path/consolidated/my_file6 -> /some/full/path/mydir3/my_file6
심볼릭 링크는 깨지지 않는 것이 보장됩니다.
문제는
time find "/some/full/path/consolidated/" -maxdepth 1 -type l -print > /tmp/foo
빨리 끝나요:
1.24 user 0.83 system 0:02.08elapsed
하지만,
time find -L "/some/full/path/consolidated/" -maxdepth 1 -type f -print > /tmp/foo
이어서
watch wc -l /tmp/foo
매우 빠르게 ~660,000줄에 도달한 다음 지연되어 때때로 수천 개의 결과가 추가된다는 것을 보여줍니다.
왜 멈출 수 있습니까? 그리고 두 번째 명령을 첫 번째 명령만큼 빠르게 만드는 것이 가능합니까?
편집: 전혀 /tmp
표시되지 않습니다 mount
(그래서 tmpfs가 아니라고 가정합니다). htop에 따르면 나는 메모리가 부족하지 않습니다. 50GB 정도의 여유 공간이 있습니다. CPU 사용량도 낮습니다. find -L path
정지되는 의 경우 /tmp/foo
속도 저하가 발생하면 약 90MB입니다. find path
멈추지 않는 의 경우 /tmp/foo
111MB입니다.
출력을 ~/foo로 리디렉션할 때에도 동일한 속도 저하가 발생합니다.
편집: 눈을 굴릴 때 iotop
I find -L
/O가 99.99%로 표시되지만 약 10초 후에만 표시됩니다. 이는 일반 작업이 끝난 후 훨씬 후입니다 find
.
답변1
inode 캐시를 늘려보십시오.
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure
값 100은 평균, 낮은 값 = 더 큰 inode+dentry 캐시
단점: 더 큰 캐시속도가 느려질 수 있습니다, 따라서 다음을 사용하여 캐시를 줄일 수도 있습니다.
echo 200 | sudo tee /proc/sys/vm/vfs_cache_pressure
또는 다음과 같이 캐시된 파일 목록을 사용할 수 있습니다.
sudo updatedb
locate /some/full/path/consolidated
또한 inode 사용량을 주시하세요. 심볼릭 링크는 inode를 차지합니다(하드링크도 마찬가지).
df -i
관련된:https://serverfault.com/questions/338097/tuning-linux-cache-settings-for-inode-caching
디스크 튜닝에 대한 추가 정보:https://unix.stackexchange.com/questions/30286/can-i-configure-my-linux-system-for-more-aggressive-file-system-caching/41831