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


30

약 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 캐싱 시스템) 성능 측면에서 하나 또는 다른 솔루션을 선택하면 성능이 중요합니까?

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


7
분명히 벤치마킹이 도움이 될 것입니다. 그러나 ext4는 이것에 대한 잘못된 파일 시스템 일 수 있습니다. XFS를보고있을 것입니다.
ewwhite

4
나는 XFS를 보지 않고 더 이상 고민하지 않고 즉시 사용할 것입니다. B + 트리는 매번 해시 테이블을 능가합니다.
Michael Hampton

팁 덕분에 벤치마킹은 약간 어렵지만 시도 hdparm -Tt /dev/hdX했지만 가장 적합한 도구는 아닙니다.
leandro moreira

2
아니오 hdparm그것은 블록 장치의 기본 성능의 확인이 아닌 파일 시스템의 테스트입니다, 올바른 도구가 아닙니다.
HBruijn

답변:


28

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

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

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는 여전히 약간의 이점이 있지만 두 파일 시스템 모두에서 잘 수행됩니다. 두 번째 옵션은 약간 나아지거나 약간 나빠질 수 있지만 벤치 마크에서도 매우 유사합니다.


그리고 XFS 또는 ext4의 경우 파일 시스템을 장착 한 하드웨어가 성능에 큰 영향을 미칩니다. 느린 5400rpm SATA 드라이브는 초당 약 50 개의 임의 IO 작업을 수행 할 수 있고, 15,000rpm의 우수한 SAS 드라이브는 수백을 수행 할 수 있으며 SSD는 대역폭이 제한 될 수 있으며 초당 수백만 개의 임의 IO 작업을 수행 할 수 있습니다. 더 이상 아니라면.
Andrew Henle

1
엄밀히 말하면 고정 $ b $에 대한 $ O (\ log_b n) $는 $ O (\ log n) $와 같은 복잡성입니다. 그러나 OP에는 실제 상수가 중요합니다.
Hagen von Eitzen

내 파일 시스템에 문제가 없으면 ext4는 단일 디렉토리에서 10,000 개의 파일을 처리 할 수 ​​없습니다. ls -l디렉토리가 inode 캐시를 삭제 한 경우 간단한 작업을 수행하는 데 1 분 정도 걸립니다. 캐시 될 때에도 여전히 1 초가 걸립니다. 트래픽이 적은 웹 서버에서 수많은 RAM이 장착 된 SSD와 Xeon이 있습니다.
Abhi Beckert

@AbhiBeckert ext3에서 업그레이드 되었습니까? 그렇다면 새 디렉토리를 작성하고 파일을 해당 디렉토리로 이동하십시오.
Michael Hampton

@Hampton 아니요. 최근 하드웨어에 (공정하게) 설치 된 서버입니다. 몇 달 동안 시스템 관리자 / 데이터 센터에서 문제를 해결해 왔습니다. 우리는 서버를 임대하기 위해 한 달에 수천 달러를 지불하고 있으며 서버에서 적절한 성능을 얻지 못하고 있습니다. 유일한 옵션은 새 디렉토리 구조로 이동하는 것 같습니다. 파일 이름이 날짜 대신 해시를 사용하여 파일을보다 균등하게 분산시키는 것일 수 있습니다.
Abhi Beckert

5

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

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

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


1
SHA1 합계 (및 기타 더 긴 해시 합계)를 "어려운 문제"로 만드는 이유는 무엇입니까? 인간 사용자에게는 다루기가 쉽지 않지만 OS, 파일 시스템 및 기타 프로그램과 동일합니다.
kbolino

4

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

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

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


1

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

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

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

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

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

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


2
Java를 가정하고 폴더를 스캔하고 있습니다. 질문에는 언급되지 않았으며 폴더를 스캔하는 것 외에도 Java로 폴더를 처리하는 다른 방법이 있습니다.
user207421

1

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

기준

기사를 썼습니다 .


그것은 분명히 예상 된 결과가 아닙니다. 이 작업을 수행하거나 권장하기 전에이 예기치 않은 결과가 발생한 이유를 자세히 살펴 봐야합니다.
Michael Hampton
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.