
(Ferris the Ferris the Detective, Esther Arzola, Karen Rustad Tölva의 오리지널 디자인)
Findlargedir는 단일 평평한 구조에 100k 이상의 항목이있는 모든 파일 시스템에서 "블랙홀"디렉토리를 신속하게 식별하는 데 도움이되는 도구입니다. 디렉토리에 많은 항목 (디렉토리 또는 파일)이있는 경우 디렉토리 목록을 얻는 데 속도가 느려져 디렉토리 목록을 가져 오려는 모든 프로세스의 성능에 영향을 미칩니다 (예 : 일부 파일을 삭제하거나 특정 파일을 찾기 위해). 큰 디렉토리 inodes를 읽는 과정은 그렇게하는 동안 얼어 붙어 더 길고 긴 기간 동안 무정 수면 ( "D"상태)에 빠지게됩니다. 파일 시스템에 따라 100k 항목으로 볼 수있게되기 시작하고 1m+ 항목에서 눈에 띄는 성능에 영향을 미치기 시작합니다.
대부분의 Linux 및 UN*X 파일 시스템이 디렉토리 inode 수축 (예 : 매우 일반적인 Ext3/Ext4)을 지원하지 않기 때문에 이러한 디렉토리는 컨텐츠가 정리 되더라도 주로 줄어들 수 없습니다 . 이는 종종 잊혀진 웹 세션 디렉토리 (GC 간격이 며칠로 구성된 PHP 세션 폴더), 다양한 캐시 폴더 (CMS 컴파일 템플릿 및 캐시), POSIX 파일 시스템 에뮬레이션 객체 저장소 등에서 발생합니다.
프로그램은 그러한 이벤트를 여러 가지 식별하고 교정 에 따라 이벤트에 대해보고하려고 시도합니다. 각 파일 시스템에 대한 각 디렉토리 inode에 몇 개의 가정 디렉토리 항목이 포장되어 있습니다. 그렇게하는 동안 디렉토리 inode Growth 비율에 대한 디렉토리 성장 비율을 결정하고 해당 비율을 사용하여 프라이스 시스템을 빠르게 스캔하여 비싸고 느린 디렉토리 조회를 피할 수 있습니다. 파일 시스템 ( find , du , ncdu 등)을 스캔하는 많은 도구가 있지만, 그중 어느 것도 완전히 정확 하도록 설계 되었기 때문에 값 비싼 조회를 피하기 위해 휴리스틱을 사용하지 않지만,이 도구는 문제가있는 폴더에 붙어 있지 않고 문제에 대한 경고를 사용하고 경고를 사용하는 것입니다.
프로그램은 Symlinks를 따르지 않으며 디렉토리를 교정하려면 R/W 권한이 필요합니다. 디렉토리 inode 크기를 항목 비율로 계산하고 실제로 계산하지 않고 디렉토리의 여러 항목을 추정 할 수 있습니다. 이 방법은 디렉토리의 실제 항목 수의 근사치 일 뿐이지 만 문제가되는 디렉토리를 신속하게 스캔 할 수 있습니다.

-a )는 과도한 I/O 및 과도한 메모리 사용을 유발할 수 있습니다. 적절한 경우에만 사용하십시오 Usage: findlargedir [OPTIONS] < PATH > ...
Arguments:
< PATH > ... Paths to check for large directories
Options:
-a, --accurate < ACCURATE >
Perform accurate directory entry counting [default: false] [possible values: true, false]
-o, --one-filesystem < ONE_FILESYSTEM >
Do not cross mount points [default: true] [possible values: true, false]
-c, --calibration-count < CALIBRATION_COUNT >
Calibration directory file count [default: 100000]
-A, --alert-threshold < ALERT_THRESHOLD >
Alert threshold count (print the estimate) [default: 10000]
-B, --blacklist-threshold < BLACKLIST_THRESHOLD >
Blacklist threshold count (print the estimate and stop deeper scan) [default: 100000]
-x, --threads < THREADS >
Number of threads to use when calibrating and scanning [default: 24]
-p, --updates < UPDATES >
Seconds between status updates, set to 0 to disable [default: 20]
-i, --size-inode-ratio < SIZE_INODE_RATIO >
Skip calibration and provide directory entry to inode size ratio (typically ~ 21-32) [default: 0]
-t, --calibration-path < CALIBRATION_PATH >
Custom calibration directory path
-s, --skip-path < SKIP_PATH >
Directories to exclude from scanning
-h, --help
Print help information
-V, --version
Print version information 정확한 모드 ( -a 매개 변수)를 사용하는 경우 큰 디렉토리 조회가 장기간 프로세스를 완전히 정체 할 것이라고 조심하십시오. 이 모드가하는 일은 기본적으로 정확한 항목 수를 계산하는 불쾌한 디렉토리의 보조적 인 완전히 정확한 패스입니다.
마운트 파일 시스템으로 내려 가면 (찾기 -xdev 옵션에서와 같이) 매개 변수 1 파일 시스템 모드 ( -o 매개 변수)가 기본적으로 토글링되지만 필요한 경우 비활성화 할 수 있습니다.
-i 매개 변수를 사용하여 디렉토리 inode 크기 대 엔트리 비율의 수동을 수동으로 제공하여 교정 단계를 완전히 건너 뛸 수 있습니다. 예를 들어 이전 실행에서 비율을 이미 알고있을 때만 의미가 있습니다.
-p 매개 변수를 0으로 설정하면 프로그램이 가끔 상태 업데이트를 제공하는 것이 중지됩니다.
하드웨어 : 4- 드라이브 SATA RAID-10이있는 8 코어 Xeon E5-1630
벤치 마크 설정 :
$ cat bench1.sh
#! /bin/dash
exec /usr/bin/find / -xdev -type d -size +200000c
$ cat bench2.sh
#! /bin/dash
exec /usr/local/sbin/findlargedir /하이퍼 핀으로 측정 된 실제 결과 :
$ hyperfine --prepare ' echo 3 | tee /proc/sys/vm/drop_caches '
./bench1.sh ./bench2.sh
Benchmark 1: ./bench1.sh
Time (mean ± σ): 357.040 s ± 7.176 s [User: 2.324 s, System: 13.881 s]
Range (min … max): 349.639 s … 367.636 s 10 runs
Benchmark 2: ./bench2.sh
Time (mean ± σ): 199.751 s ± 4.431 s [User: 75.163 s, System: 141.271 s]
Range (min … max): 190.136 s … 203.432 s 10 runs
Summary
' ./bench2.sh ' ran
1.79 ± 0.05 times faster than ' ./bench1.sh ' 하드웨어 : 48 코어 Xeon Silver 4214, 7-Drive SM883 SATA HW RAID-5 어레이, 2TB 컨텐츠 (작은 파일이있는 수십 개의 컨테이너)
동일한 벤치 마크 설정. 결과:
$ hyperfine --prepare ' echo 3 | tee /proc/sys/vm/drop_caches '
./bench1.sh ./bench2.sh
Benchmark 1: ./bench1.sh
Time (mean ± σ): 392.433 s ± 1.952 s [User: 16.056 s, System: 81.994 s]
Range (min … max): 390.284 s … 395.732 s 10 runs
Benchmark 2: ./bench2.sh
Time (mean ± σ): 34.650 s ± 0.469 s [User: 79.441 s, System: 528.939 s]
Range (min … max): 34.049 s … 35.388 s 10 runs
Summary
' ./bench2.sh ' ran
11.33 ± 0.16 times faster than ' ./bench1.sh '