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


43

많은 작은 파일과 적은 수의 큰 파일을 포함하는 디렉토리 트리가 있습니다. 파일의 평균 크기는 약 1 킬로바이트입니다. 트리에는 210158 개의 파일과 디렉토리가 있습니다 (이 번호는을 (를 find | wc -l) 실행하여 얻은 것입니다 ).

적은 비율의 파일이 일주일에 여러 번 추가 / 삭제 / 재 작성됩니다. 이는 작은 파일뿐만 아니라 (작은 수의) 큰 파일에도 적용됩니다.

내가 시도한 파일 시스템 (ext4, btrfs)에는 파일을 디스크에 배치하는 데 문제가 있습니다. 더 긴 시간 동안 디스크에서 파일의 물리적 위치 (솔리드 스테이트 디스크가 아닌 회전 미디어)가 더욱 무작위로 분배됩니다. 이 무작위 배포의 부정적인 결과는 파일 시스템이 느려지는 것입니다 (예 : 새로운 파일 시스템보다 4 배 느림).

이 성능 저하를 겪지 않고 회전하는 미디어에서 안정적인 성능 프로파일을 유지할 수있는 Linux 파일 시스템 (또는 파일 시스템 유지 관리 방법)이 있습니까? 파일 시스템은 퓨즈에서 실행될 수 있지만 신뢰할 수 있어야합니다.


어떤 파일이 크거나 자주 변경되지 않으며 어떤 파일이 작거나 자주 변경되는지 알면 각 시나리오에 더 적합한 서로 다른 옵션으로 두 개의 파일 시스템을 만들 수 있습니다. 동일한 구조의 일부이므로 액세스 할 수 있어야하는 경우에는 심볼릭 링크를 사용하여 몇 가지 트릭을 수행 할 수 있습니다.
Marcin

btrfs (기록 중 복사 기능 사용)가 일정 기간 동안 느려 졌다는 사실에 놀랐습니다. 결과를 공유하여 새로운 성능 조정 방향으로 서로 도움을 줄 수 있기를 바랍니다.
Nikhil Mulley

Linux에 새로운 동물 온라인 zfs가 있으며 기본 모드 및 퓨즈 구현에서 사용할 수 있습니다.
Nikhil Mulley

Linux에서 zfs를 한 번 시도했지만 매우 불안정했습니다. 파일 시스템을 완전히 자주 잠그도록 관리했습니다. Box는 작동하지만 FS에 대한 액세스는 중단됩니다.
Patrick

답변:


47

공연

나는 작은 벤치 마크 ( source )를 작성하여 수십만 개의 작은 파일로 어떤 파일 시스템이 가장 잘 작동하는지 알아 냈습니다.

  • / dev / urandom의 데이터로 300000 개의 파일 (512B ~ 1536B)을 만듭니다.
  • 30000 개의 임의의 파일을 다시 작성하고 크기를 변경하십시오
  • 30000 순차 파일 읽기
  • 30000 개의 임의 파일 읽기
  • 모든 파일을 삭제

  • 모든 단계 후에 캐시 동기화 및 삭제

결과 (평균 시간 (초), 낮을수록 좋음) :

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

결과 :
Ext4의 전반적인 성능은 우수했지만 ReiserFS는 순차 파일을 읽는 데 매우 빠릅니다. 많은 작은 파일로 인해 XFS가 느리다는 것이 밝혀졌습니다 .이 사용 사례에는 사용하지 않아야합니다.

조각화 문제

파일 시스템이 드라이브를 통해 파일을 배포하지 못하게하는 유일한 방법은 파티션을 실제로 필요한만큼만 유지하는 것이지만 파티션을 너무 작게 만들지 않도록주의하여 파일 내부 조각화를 방지하십시오. LVM 을 사용하면 매우 도움이 될 수 있습니다.

추가 자료

아치 위키에는 파일 시스템 성능에 관한 훌륭한 기사가 있습니다.

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices


4
비교할 커널 버전을 지정해야합니다. XFS는 최근 커널 중 하나에서 매우 중요한 속도 향상을 얻었습니다 (2.6.31이라고 생각하지만 저를 인용하지 마십시오).
Patrick

1
btrfs는 내부적으로 lvm 트릭을 수행합니다. 디스크의 작은 청크를 할당하고 해당 청크에 파일을 넣은 다음 기존 청크가 채워질 때만 디스크의 다른 청크를 할당합니다.
psusi

1
그것은 모든 파일 시스템에 해당됩니다. 그렇기 때문에 응용 프로그램에서 fsync ()와 같은 것을 사용합니다.
psusi

2
@taffer입니다. 트랜잭션은 저널이 다른 파일 시스템에서와 동일한 효과를 가지며 fs 메타 데이터를 보호합니다. 이론적으로 응용 프로그램은 설명 된 방식으로 사용할 수 있지만 현재 응용 프로그램이 트랜잭션을 열고 닫을 수있는 API는 없습니다.
psusi

1
@taffer "최근 벤치 마크"는 2015 년 4 월부터 3 년 이상이며 기본 옵션만으로 XFS를 사용합니다. 이는 xfsprogs 3.2.3 이전의 버전으로 XFS v5를 기본값으로 만들고 모든 이점을 제공합니다. 또한 작은 파일과 많은 메타 데이터 업데이트로 XFS 성능을위한 게임 체인저 인 -m finobt = 1로 포맷되지 않았습니다. 아니요, 실버 글 머리 기호는 없지만 특히 주요 성능 변경 기능을 무시하거나 사용할 수 없거나 비활성화 한 경우 이전 벤치 마크에 대한 의견을 제시하는 것이 현명하지 않습니다.
조디 리 Bruchon

7

이 작업에 ReiserFS를 사용하고 있습니다. 특히 많은 작은 파일을 처리하기 위해 만들어졌습니다. funtoo wiki 에는 쉽게 읽을 수있는 텍스트가 있습니다 .

ReiserFS에는 또한 작은 파일 성능을 향상시키기위한 다양한 기능이 있습니다. ext2와 달리 ReiserFS는 고정 1k 또는 4k 블록으로 저장 공간을 할당하지 않습니다. 대신 필요한 정확한 크기를 할당 할 수 있습니다.


1
ReiserFS에는 안정성 문제도 있으므로 RH와 SuSE는 FS를 떨어 뜨 렸습니다. 원칙 (BTree-based-FS)에서 BTRFS는 비슷해야합니다.
Nils


0

XFS는 이와 같은 상황에서 성능이 우수합니다. 이것이 메일 저장소 (하나의 디렉토리에 수십만 개의 파일을 포함 할 수 있음)를 위해 직장에서 사용하는 이유의 일부입니다. ReiserFS보다 내결함성이 우수하고 훨씬 더 광범위하게 사용되며 일반적으로 매우 성숙한 파일 시스템입니다.

또한 XFS는 온라인 조각 모음을 지원합니다. 비록 지연된 할당 기술을 사용하지만, 다른 파일 시스템과 비교할 때 조각화가 덜 발생합니다.


20
XFS는 이와 같은 상황에서 성능이 우수합니다. [인용 필요]
taffer

8
Ehm, xfs는 특히 반대쪽으로 유명합니다. 큰 파일에서는 잘 작동하지만 작은 파일에서는 잘 작동하지 않습니다! 예를 들어이
Levite

1
@Levit 나는 당신이 그 보고서를 잘못 읽고 있다고 생각합니다. 이 보고서는 XFS가 임의 IO에 대해 매우 잘 수행됨을 매우 명확하게 보여줍니다. 그러나 그 외에도, 보고서는이 질문의 시나리오 유형, 많은 파일을 다루지 않습니다. 임의 IO는 한 가지이며, 많은 파일이 ext *가 직면하는 곳입니다.
Patrick

2
XFS가 유일하게 좋은 곳은 임의의 읽기 / 쓰기 작업이 있다는 것입니다 (여전히 기계 디스크의 실제 임의의 읽기 패턴이 10MB / s를 얻을 수 있다는 것이 이상해 보입니다) (imho)), 7 페이지에 앞서 언급 한 내용을 보여 주지만 XFS는 큰 파일을 처리하는 데 정말 좋습니다! 3 페이지와 3 페이지를 보라. 3 페이지에서는 작은 파일을 명확하게 처리 할 수있다. 나는 실제로 XFS에 대해 아무것도 가지고 있지 않지만, 당신이 거의 모든 곳에서 찾은 것에서, 그것은 많은 작은 파일에 대한 최선의 선택이 아닙니다.
Levite

5
XFS는 또한 큰 파일에 관해서는 오랜 시간에 걸쳐 작은 청크로 무작위 / 느리게 확장되는 경우 매우 느릴 수 있습니다 . (일반적인 syslogd패턴입니다.) 예를 들어 MD 설정을 통한 XFS에서 필자의 경우 1.5GB 파일을 제거하는 데 4.75 분 (!)이 걸리고 디스크 드라이브가 쓰기 속도로 100 개의 트랜잭션 / s 한계로 제한되는 것으로 나타났습니다. 2MB / s 이상 또한 드라이브가 이미 최대로 제한되어 있기 때문에 동일한 드라이브에서 다른 병렬 진행 IO 작업의 성능에 나쁜 영향을 미칩니다. 다른 FS (또는 벤치 마크에서 테스트)에서 이와 같은 것을 본 적이 없습니다.
티노
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.