최신 파일 시스템에서 수백만 파일에 대한 성능 영향은 무엇입니까?

약 3M 파일 (평균 750KB 크기)을 호스팅하기 위해 ext4 (dir_index가 활성화 된 상태)를 사용하고 있으며 사용할 폴더 구성표를 결정해야한다고 가정 해 봅시다.

에서 최초의 솔루션 , 우리는 파일에 해시 함수를 적용하고 (첫 번째 레벨 1 개 캐릭터와 두 번째 수준에 2 개 문자 인) 폴더 두 가지 수준을 사용하므로되는 filex.for해시가 동일 abcde1234 , 우리는에 / 경로를 저장할 수 있습니다 / a / bc /abcde1234-filex.for.

에서 두 번째 솔루션 , 우리는 파일에 해시 함수를 적용하고 (첫 번째 레벨 2 개 캐릭터와 두 번째 수준에 2 개 문자 인) 폴더 두 가지 수준의 사용 : 그러므로되는 filex.for해시가 동일 abcde1234을 , 우리는 그것을에 저장할 수 있습니다 / 경로를 / ab / de /abcde1234-filex.for.

첫 번째 솔루션의 경우 폴더 당 평균 732 개의 파일 (파일이있는 마지막 폴더)로 다음과 같은 구성표 /path/[16 folders]/[256 folders]를 갖게됩니다.

두 번째 솔루션에 동안 우리는해야합니다 /path/[256 folders]/[256 folders]과 폴더 당 45 개 파일의 평균 .

우리 가이 구성표에서 파일을 작성 / 연결 해제 / 읽기 ( 그러나 대부분 읽기 ) 할 것을 고려할 때 (기본적으로 nginx 캐싱 시스템) 성능 측면에서 하나 또는 다른 솔루션을 선택하면 성능이 중요합니까?

또한이 설정을 확인 / 테스트하는 데 사용할 수있는 도구는 무엇입니까?

이런 종류의 디렉토리 구조를 만드는 이유는 파일 시스템이 디렉토리 내에서 파일을 찾아야하고 디렉토리가 클수록 작업 속도가 느리기 때문입니다.

파일 시스템 디자인에 따라 속도가 얼마나 느려집니다.

ext4 파일 시스템은 B- 트리 를 사용 하여 디렉토리 항목을 저장합니다. 이 테이블을 조회하는 데 O (log n) 시간 이 소요될 것으로 예상되는데 , 대부분의 시간은 ext3 및 이전 파일 시스템이 사용한 순진 선형 테이블보다 적습니다 (그렇지 않은 경우 디렉토리가 너무 작음). 정말 중요합니다).

XFS 파일 시스템은 B + 트리를 대신 사용합니다. 해시 테이블 또는 B- 트리에 비해이 방법의 장점은 모든 노드에 여러 개의 자식 b 가있을 수 있다는 것입니다 . 여기서 XFS b 는 다양하고 254 (또는 루트 노드의 경우 19)이며이 숫자는 최신이 아닐 수 있습니다 ). 이를 통해 O (log _b n) 의 시간 복잡성이 크게 개선되었습니다.

이러한 파일 시스템 중 하나는 단일 디렉토리에서 수만 개의 파일을 처리 할 수 ​​있으며 XFS는 동일한 수의 inode가있는 디렉토리에서 ext4보다 훨씬 빠릅니다. 그러나 B + 트리를 사용하더라도 조회에 시간이 걸릴 수 있으므로 3M inode가있는 단일 디렉토리를 원하지 않을 것입니다. 이것이 처음에 이런 식으로 디렉토리를 생성하게 된 것입니다.

제안 된 구조에 관해서는, 첫 번째 옵션은 nginx 예제에 표시된 것입니다. XFS는 여전히 약간의 이점이 있지만 두 파일 시스템 모두에서 잘 수행됩니다. 두 번째 옵션은 약간 나아지거나 약간 나빠질 수 있지만 벤치 마크에서도 매우 유사합니다.

필자의 경험에 따르면 스케일링 요소 중 하나는 해시 이름 파티셔닝 전략이 주어진 inode 크기입니다.

제안 된 옵션 모두 생성 된 각 파일에 대해 최대 3 개의 inode 항목을 만듭니다. 또한 732 파일은 여전히 ​​일반적인 16KB보다 작은 inode를 만듭니다. 나에게 이것은 두 옵션 중 하나가 동일하게 수행됨을 의미합니다.

나는 당신의 짧은 해시에 박수를 보냅니다. 내가 작업했던 이전 시스템은 주어진 파일의 sha1sum과 해당 문자열을 기반으로 한 디렉토리를 연결하여 훨씬 어려운 문제를 일으켰습니다.

확실히 하나의 옵션은 디렉토리의 파일 수를 xfs 나 ext4 또는 기타 파일 시스템에 대해 합리적으로 보이는 것으로 줄이는 데 도움이됩니다. 어느 것이 더 낫다는 것은 분명하지 않으며, 테스트하기 위해 테스트해야 할 것입니다.

실제 워크로드와 같은 것을 시뮬레이션하는 애플리케이션 벤치 마크가 이상적입니다. 그렇지 않으면 많은 작은 파일을 구체적으로 시뮬레이트하는 것을 생각해보십시오. 말하자면, smallfile이라는 오픈 소스가 있습니다. 이 문서는 다른 도구를 참조합니다.

hdparm지속적인 I / O를 수행하는 것은 유용하지 않습니다. 매우 많은 파일과 관련된 많은 작은 I / O 또는 거대한 디렉토리 항목이 표시되지 않습니다.

문제 중 하나는 폴더를 스캔하는 방법입니다.

폴더에서 스캔을 실행하는 Java 메소드를 상상해보십시오.

많은 양의 메모리를 할당하고 짧은 시간 내에 할당을 해제해야하므로 JVM에 매우 무겁습니다.

가장 좋은 방법은 각 파일이 전용 폴더에있는 방식 (예 : 연 / 월 / 일)으로 폴더 구조를 정렬하는 것입니다.

전체 스캔이 수행되는 방식은 각 폴더마다 하나의 기능 실행이 있으므로 JVM이 기능을 종료하고 RAM을 할당 해제 한 후 다른 폴더에서 다시 실행하는 것입니다.

이것은 단지 예이지만 어쨌든 그러한 거대한 폴더를 갖는 것은 의미가 없습니다.

나는 같은 문제를 겪고있다. ext4의 Ubuntu 서버에 수백만 개의 파일을 저장하려고합니다. 내 벤치 마크를 종료했습니다. 플랫 디렉토리는 사용이 더 단순하면서도 성능이 더 우수하다는 것을 알았습니다.

기사를 썼습니다 .