수백만 개의 작은 파일을위한 파일 시스템


44

어떤 리눅스 파일 시스템 당신을 위해 선택하는 것이 가장 속도 다음과 같은 시나리오에서 :

  • 1 억 개의 파일
  • 평균 ~ 2k 파일 크기
  • > 95 % 읽기 권한
  • 꽤 임의 접근
  • 높은 동시성 (> 100 프로세스)

참고 : 파일은 큰 디렉토리를 피하기 위해 깊은 계층 구조 트리에 저장됩니다. 각 리프 디렉토리에는 약 1,000 개의 파일이 있습니다.

어떻게 벤치마킹하겠습니까?


3
추가 정보가 필요합니다. 예를 들어, 모든 파일을 플랫 디렉토리 또는 중첩 (정렬) 디렉토리에 저장합니까? 이는 파일 액세스 시간에 큰 영향을 줄 수 있습니다. "평면"배열에서 100,000,000 개의 항목을 선별하면 FS 유형에 관계없이 상당한 오버 헤드가 발생합니다. 가장 좋은 경우, 어떤 종류의 트리 검색을보고 있는데 여전히 파일에 여러 개의 조회가 필요합니다. 파일을 하위 디렉토리로 분류하면 각 레벨에서 검색 할 항목 수가 적어 액세스 시간이 크게 단축됩니다.
에이버리 페인

파일이 직렬 또는 동시에 액세스됩니까?
Steve Schnepp

답변:


19

다음은 모든 주요 Linux FS 를 시작점으로 사용할 수있는 보니 ++와 비교 한 결과 입니다.

무작위 탐색 측면에서 Reiser가 이기고 EXT4가 이어 JFS가 이깁니다. 이것이 디렉토리 조회와 정확히 연관되는지 확실하지 않지만 지표가 될 것 같습니다. 구체적으로 자신의 테스트를 수행해야합니다. EXT2는 저널이 없기 때문에 파일 작성 시간 동안 모든 것을 뛰어 넘지 만, EXT4는 hans reiser의 현재 상태로 인해 사용하고 싶지 않은 Reiser를 제외한 모든 것을 이깁니다.

NCQ를 지원하는 드라이브를 살펴보고이를 사용하도록 설치가 설정되어 있는지 확인하십시오. 많은 노력을 기울이면 속도가 향상됩니다.

마지막으로, 머신에 엄청난 양의 램이 있어야합니다. 파일이 자주 업데이트되지 않기 때문에, 리눅스는 여유 공간이 있다면 대부분의 파일을 캐싱하게됩니다. 사용 패턴이 올바른 경우 속도가 크게 향상됩니다.


1
++ 보니의 문제는도 거의 내 사용 시나리오를 테스트하지 않는다는 것입니다
베네

2
디렉토리 조회를 테스트하지는 않지만 솔직히 말해서 데이터를 실제 데이터베이스에 덤프하는 것이 좋습니다. 파일 시스템은 대부분의 데이터베이스가 사용하도록 설계된 작은 개체에서 거의 잘 작동하지 않습니다.
Andrew Cholakian

7
@AndrewCholakian Link는 이제 죽었습니다.
돈 스콧

8

본인은 Andrew가 말한 대부분의 내용에 동의 하지만 Reiser4 또는 이전 (하지만 더 나은 지원) ReiserFS를 권장 합니다. 이러한 테스트 (및 ReiserFS 설명서)에서 알 수 있듯이이 테스트는 요청한 상황 (작은 수의 작은 파일 또는 디렉토리)을 위해 설계되었습니다. 나는 과거에 Gentoo와 Ubuntu에서 아무런 문제없이 ReiserFS를 사용했습니다.

Hans Reiser의 상태에 관해서는 파일 시스템 자체의 코드 또는 안정성에 문제가 있다고 생각하지 않습니다. Reiser4는 DARPA와 Linspire가 후원하기 때문에 Reiser File System의 추가 개발이 결정되지 않는다는 데 동의하지만 다른 사람이 사용해야하는지 여부를 결정하는 요소는 아닙니다.


3
나는 오랫동안 ReiserFS를 사용해왔다. 사실, 나는 아직도 다시 설치하지 않은 오래된 젠투 서버에서 여전히 사용하고 있습니다. 이 설치는 5 월에 4 살입니다. 내가 할 수 말할 것은 크게 둔화 점이다. 이러한 현상은 파일 시스템이있는 모든 시스템에서 활성 읽기 / 쓰기 사용 상태 인 ReiserFS를 사용하는 모든 파일 시스템에서 시간이 지남에 따라 발생합니다. 예외가 없습니다. 따라서 장기간 사용하고 싶다면 마음에. 나는 큰 파일 시스템을 위해 XFS를 사용하여 그로부터 멀어졌습니다.
Mihai Limbăşan

3

나는 이것이 귀하의 질문에 대한 직접적인 대답이 아니라는 것을 알고 있지만,이 경우 데이터베이스가 이것을 호스팅하는 데 더 적합 할 것이라고 생각합니다. 작은 파일은 데이터베이스 테이블에 이진 형식으로 저장되고 wil에서 검색 될 수 있습니다. 이 파일을 사용하는 소프트웨어는 이것을 지원할 수 있어야합니다 ...


1
계층 적 데이터베이스가 아니라면 파일 시스템이란 무엇입니까? 귀하의 제안은 아마도 보증되지 않은 추상화, 복잡성 및 소프트웨어 계층을 추가합니다. 또한 질문의 소유자는 'UNIX 철학'으로 자신의 작업을 수행하고 있습니다.
Stu Thompson

3
우선, 나는 유닉스 나 그 지역의 다른 어떤 것에도 반대하지 않습니다. 파일 시스템과 데이터베이스 간에는 큰 차이가 있으므로 두 기술이 모두 개발 된 것입니다. 데이터베이스는 대부분의 파일 시스템보다 더 나은 작업을 수행하는 방대한 양의 작은 엔티티와 작동하도록 설계되었습니다. 나는 당신이 이것으로 취할 수있는 또 다른 길이있을 것이라고 지적했습니다.
Jeroen Landheer

1
그리고 리눅스에서 파일 시스템을 조각 모음하는 것보다 db 파일을 "청소 / 진공"하는 것이 훨씬 쉽습니다. 대부분의 / 모든 fs는 필요하지 않다고 말하면서 해당 기능을 제공하지 않습니다. 그러나 위의 Mihai 의견에 주목하면 엄격하게 사실이 아님을 알 수 있습니다.
Gringo Suave 2016 년

3

Unix StackExchange의 누군가가이 시나리오 만 테스트하기 위해 벤치 마크 (소스 포함)를 만들었습니다.

Q : 많은 작은 파일 (SSD가 아닌 HDD)을 저장하기위한 가장 고성능 Linux 파일 시스템은 무엇입니까?

최고의 읽기 성능은 ReiserFS에서 비롯된 것 같습니다.


Btrfs는 삭제 이외의 모든 결과에서 더 좋거나 비슷한 결과를 얻는 것으로 보입니다. 그러나 얼마나 자주 300k 파일을 삭제합니까? 나는 과거에 rfs를 좋아했지만 btrfs는 미래에 더 나은 내기 일 수 있습니다.
Gringo Suave

3

내 경험상 ext2는 작은 파일을 위해 ext4를 물 밖으로 날려 버립니다. 쓰기 무결성에 신경 쓰지 않으면 좋습니다. 예를 들어, subversion은 ext4 및 기타 파일 시스템 (XFS)이 질식하는 수많은 작은 파일을 생성합니다 (30 분마다 ext2에서 데이터를 ext4로 재 동기화하는 크론 작업을 실행하여 사실상 문제를 해결합니다).

이러한 명령을 실행하면 ext2가 더 빨라집니다 (이 옵션의 대부분은 충돌 전에 동기화를 실행하지 않는 한 충돌 후 파일 시스템을 불안정하게 만듭니다). 이 명령은 작은 파일의 ext4에는 거의 영향을 미치지 않습니다.

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

1

ext3 (또는 ext4), 아마도 JFS가 좋은 해결책 일 것입니다. 나는 ext4와 btrfs에주의를 기울였습니다 (파일 시스템은 까다 롭습니다-최신의 최신 것을 사용하려면 백업으로 준비하십시오).

mkfs 시간 동안 원하는대로 파일 시스템을 조정하기 위해 조정할 수있는 다양한 매개 변수가 있습니다.

나는 확실히 권하고 싶습니다 에 대해 XFS. 파일 시스템이 좋지 않기 때문에 생성 / 삭제는 비용이 많이 드는 작업입니다.


디렉토리 검색과 관련된 문제를 피하려면 다음과 같은 지능형 이름 지정 체계를 사용하십시오.

<first letter of id>_<last letter of id>/<id>

또는 유사하고 더 복잡한 체계. 이렇게하면 디렉토리 검색 속도가 빨라져 전체 액세스 속도가 빨라집니다. (V7에서 돌아온 오래된 유닉스 트릭입니다.)


1
첫 번째 n 문자뿐만 아니라 첫 번째와 마지막 문자를 사용하면 어떤 이점이 있습니까?
bene

가능한 구성표 중 하나 일뿐입니다. 장점이 될지 여부는 색인 작성에 사용되는 "키"에 따라 다릅니다. 이 특정 체계는 조직의 사람들에게 데이터를 저장하는 응용 프로그램과 관련하여 참조 되었으며이 방법으로 색인이 향상되었습니다. 항상 그렇듯이 데이터에 맞게 조정 한 다음 정답을 찾을 때까지 프로파일을 작성해야합니다. :

1

대부분의 FS는 dir에서 65K 이상의 파일로 질식 할 것입니다 .ext4에서도 여전히 그렇습니다. Reiser 파일 시스템에는 그 한계가 없습니다 (mp3.com의 사람들은이를 확인하기 위해 지불했습니다). 다른 것에 대해서는 확실하지 않지만 ReiserFS의 사용 시나리오 중 하나입니다.


1
RieserFS가 아닌 ReiserFS입니다.
Daniel Rikowski

이번 주말에는 ext4에 1000000 개의 파일이 있습니다. 당신이하지 않으면 ls탭 완성이 빨리 작동합니다. 아마도 색인 때문일 것입니다.
Ole Tange

ext4는 dir_index 확장자를 가지고있어 한 디렉토리에서 많은 파일의 속도를 높입니다.
alfonx
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.