`find / nfs / server / mount / data [12] -name data _ *. gz> / dev / null` 두 번째로 실행될 때 4 배 느려짐-왜?

NFS 서버 (어떤 종류의 NAS 기기이므로 어떤 브랜드 또는 구성 방법에 대해 알지 못함)는 단일 파일 시스템을 Linux 클라이언트에 내보내고 마운트했습니다. 서버와 클라이언트는 모두 동일한 로컬 네트워크에 있습니다. 원격 파일 시스템은 다음과 같이 구성됩니다 :

/nfs/server/mount/data1/
                        client_uuid_1/
                                      data_20170101.gz
                                      data_20170102.gz
                                      ...
                        client_uuid_2/
                                      data_20170101.gz
                                      data_20170102.gz
                                      ...
                        ...
                  data2/
                        client_uuid_3/
                                      data_20170101.gz
                                      data_20170102.gz
                                      ...
                        ...

총 40,000 개의 client_uuid_N 디렉토리와 300,000 개의 데이터 파일이 있습니다. 새 데이터 파일에 대해 모든 디렉토리를 스캔해야하는 스크립트가 glob 작업을 수행하는 것만으로 매우 느리다는 것을 알았으므로 더 조사하여이 기괴한 현상을 발견했습니다.

find /nfs/server/mount/data[12] -name data_*.gz > /dev/null파일 시스템을 다시 마운트 한 후 처음으로 실행 하면 약 5 분 안에 완료됩니다. 그것은 이미 고통스럽게 느리고 일종의 문제를 제안하지만 더 이상해집니다.

초 내가 그 명령을 실행할 때, 그것은 소요 네 번 이상 거의 20 분 -. 이것은 내가 기대했던 것과 정확히 반대입니다.

왜 이런 일이 일어날 수 있습니까?

이 find명령은 디렉토리에서 항목을 검색하고 파일 속성을 가져와 하위 디렉토리를 검색하고 다시 검색합니다. find처음 실행하면 nfs 클라이언트는 디렉토리 목록을 얻는 것 외에 파일 속성도 묻는 READDIR 작업을 실행 합니다. 네트워크를 통해 전송되는 nfs 요청이 거의 없으므로 매우 효율적입니다. 두 번째 실행에서는 디렉토리가 변경되지 않으므로 캐시 된 목록이 사용됩니다. 그러나 클라이언트는 각 파일의 파일 속성 변경 사항을 확인하여 총 실행 시간을 늘립니다. 기술적으로 파일 시스템 객체 유형은 변경할 수 없지만 (파일은 절대 디렉토리가되지 않음) nfs 클라이언트는 응용 프로그램이 실제로 stat호출 로 필요한 find속성을 모든 파일 속성에 대한 명령 쿼리 에서 사용 하는 것으로 인식하지 못합니다 .

직관적으로 들리지만 파일 시스템 캐시를 삭제하면 ( echo 3 > /proc/sys/vm/drop_cacheLinux에서) 두 번째 실행에서도 더 나은 성능을 얻을 수 있습니다.

리눅스 구현에 대한 기술적 세부 사항에 대해 더 자세히 알고 싶다면 리눅스 nfs 메일 링리스트에 대한 토론 이있었습니다 .