시간이 지남에 따라 약 3 백만 개의 파일로 성장한 ext3 디렉토리에 쓰는 응용 프로그램이 있습니다. 말할 필요도없이이 디렉토리의 파일 목록을 읽는 것은 매우 느립니다.
나는 ext3를 비난하지 않습니다. 올바른 해결책은 응용 프로그램 코드가을 ./a/b/c/abc.ext사용하지 않고 하위 디렉토리에 쓰도록 하는 것 ./abc.ext입니다.
그런 하위 디렉토리 구조로 변경하고 있는데 내 질문은 간단합니다. 수용 가능한 성능을 유지하면서 하나의 ext3 디렉토리에 얼마나 많은 파일을 저장해야합니까? 당신의 경험은 무엇입니까?
다른 말로하면; 3 백만 개의 파일을 구조에 저장해야한다고 가정하면 구조의 깊이는 몇 레벨 ./a/b/c/abc.ext입니까?
분명히 이것은 정확히 대답 할 수없는 질문이지만 볼 파크 견적을 찾고 있습니다.
답변:
dir_index기능을 지원하는 배포판이 있으면 단일 디렉토리에 200,000 개의 파일을 쉽게 가질 수 있습니다. 그래도 안전을 위해 약 25,000으로 유지합니다. 이 없으면 dir_index5,000으로 유지하십시오.
디렉토리 분할을 선택하는 방법에 매우 주의 하십시오 . "a / b / c"는 나에게 재난을위한 레시피처럼 들린다 ...
맹목적으로 여러 디렉토리 심층 구조를 만들지 마십시오. 예를 들어 첫 번째 수준의 100 개 항목, 두 번째 수준의 100 개 항목, 세 번째 수준의 100 개 항목. 나는 거기에 있었고, 재킷을 가져 와서 몇 백만 개의 파일이있는 랩퍼에서 성능이 나올 때 재킷을 재구성해야했습니다. :-)
우리는 "다중 디렉토리"레이아웃을 수행 한 클라이언트를 가지고 있으며, 디렉토리 당 1 ~ 5 개의 파일 만 넣게되어 결국 죽이고있었습니다. 이 디렉토리 구조에서 "du"를 수행하는 데 3-6 시간이 소요됩니다. 여기서 구세주는 SSD 였고 애플리케이션의이 부분을 다시 쓰려고하지 않았으며 SSD는이 시간을 몇 시간에서 몇 분으로 줄였습니다.
문제는 각 수준의 디렉토리 조회가 탐색을 요구하고 탐색이 매우 비싸다는 것입니다. 디렉토리의 크기도 중요한 요소이므로 더 큰 것이 아니라 더 작은 것이 큰 승리입니다.
디렉토리 당 파일 수에 대한 귀하의 질문에 대답하기 위해 1,000은 "최적화"라고 들었지만 10,000의 성능은 괜찮은 것 같습니다.
그래서 내가 권장하는 것은 한 수준의 디렉토리이며, 각 수준은 2 자 길이의 디렉토리이며 최상위와 약 3800 개의 디렉토리에 대해 대소 문자와 숫자로 구성됩니다. 그런 다음 3800 개의 파일을 포함하는 서브 디렉토리 또는 3M 파일의 서브 디렉토리 당 약 1,000 개의 파일로 14M 파일을 보유 할 수 있습니다.
다른 고객을 위해 이와 같이 변경했으며 큰 차이가있었습니다.
http://en.wikipedia.org/wiki/Ext3#Functionality- 디렉토리는 약 32000 개의 하위 디렉토리 만 가질 수 있지만 파일은 언급하지 않습니다.
http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/
또한 Experts Exchange는 싫지만 디렉토리 당 10-15,000 미만인 것이 이상적이라는 이 질문 에 대한 의견을 읽었습니다 .
내 경험상 가장 좋은 방법은 파일 구조를 사전에 과도하게 엔지니어링하지 않는 것입니다. 적어도 하나의 다른 답변에서 언급했듯이 성능 문제를 처리하는 파일 시스템 확장이 있습니다.
내가 더 자주 맞닥뜨린 문제는 관리상의 유용성입니다. 디렉토리의 파일 수를 줄이기 위해 할 수있는 최소한의 작업은 아마도 현재 필요한 방법 일 것입니다.
sqrt (3_000_000) == 1732
하나의 디렉토리에있는 수천 개의 파일이 나에게 합리적인 것처럼 들립니다. 자신의 상황에 대한 자신의 판사가 되십시오. 이를 위해서는 파일을 단일 레벨의 해시 디렉토리로 분할하여 디렉토리 당 평균 파일 수가 디렉토리 수와 거의 같도록하십시오.
귀하의 예를 감안할 때이 될 것이다 ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext, ....
파일의 확산은 실제 파일 이름에 따라 크게 달라집니다. 이 기술을 각각 이름이 백만 개의 파일 디렉토리에 적용한다고 상상해보십시오 foobar???.txt. 각 파일 이름의 MD5 합계에서 특정 수의 비트 값을 기반으로하는 해싱과 같이 더 균등하게 확산하는 방법이 있지만 달성하려는 작업에 너무 과잉이 될 것이라고 감히 생각합니다.
흠, 나는 최근에이 기사를 읽었다 . 기본적으로 선호하는 해싱 알고리즘의 배포를 활용합니다. 숫자로 재생하기 시작했습니다. MySQL signed INT의 최대 값은 2147483647입니다. 디렉토리 당 원하는 파일 수와 하위 디렉토리 수를 변경하여 최종 하위 디렉토리 수 / 파일- 주어진 데이터 세트에 대한 디렉토리 별 분할이지만 최적의 디렉토리 / 파일 조직에 대한 경험적 증거를 찾기는 어렵습니다. 이 기사 에서는 파일 시스템 간의 성능 차이 (일부 흥미로운 메트릭)에 대한 통찰력을 제공하지만 최적의 조직에 대해서는 설명하지 않습니다.