SATA 3.0 백플레인을 통해 8x10TB HDD가 장착 된 Ubuntu 16.04 백업 서버가 있습니다. 8 개의 하드 디스크가 RAID6에 조립되어 EXT4 파일 시스템이 사용 중입니다. 이 파일 시스템은 SEEK 작업이 많지만 IO 처리량이 적은 대량의 작은 파일을 저장합니다. 실제로 서로 다른 서버의 많은 작은 파일이 매일 rsnapshot을 통해 스냅 샷됩니다 (여러 개의 INODES가 동일한 파일을 지시합니다. 파일 시스템 (60TB 네트)의 사용량이 50 %를 초과하여 성능이 매우 떨어졌습니다. 사용량이 75 %이고

du -sch /backup-root/

며칠이 걸립니다 (!). 이 기계에는 8 개의 코어와 16G의 RAM이 있습니다. RAM은 OS 파일 시스템 캐시에서 완전히 활용되며 8 개 중 7 개 코어는 IOWAIT로 인해 항상 유휴 상태입니다.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

이런 종류의 파일 시스템 사용 경험이 부족합니다. 이것을 조정하려면 어떤 옵션이 필요합니까? 이 시나리오에서 어떤 파일 시스템이 더 잘 작동합니까? OS 내장 옵션 이외의 다른 캐싱 옵션에 RAM을 포함하는 옵션이 있습니까?

큰 RAID 어셈블리에서 대량의 작은 파일을 어떻게 처리합니까?

감사합니다, 세바스찬

RAID6 어레이에 12x 2TB 디스크를 사용하는 비슷한 (더 작은) 설정이 있으며 동일한 목적 ( rsnapshot백업 서버)에 사용됩니다.

첫째, du -hs그렇게 크고 사용되는 파일 시스템에서 많은 시간이 걸리는 것은 완전히 정상입니다 . 또한 du하드 링크를 고려하여 명백한 IO로드 외에도 상당한 양의 CPU로드가 발생합니다.

파일 시스템 메타 데이터가 LBA 용어로 매우 먼 블록에 위치하여 많은 탐색이 발생하기 때문에 속도가 느려집니다. 일반적인 7.2K RPM 디스크는 약 100 IOPS를 제공하므로 모든 메타 데이터를로드하는 데 며칠이 아닌 몇 시간이 필요한지 알 수 있습니다.

상황을 (비파괴 적으로) 개선하려고 시도 할 수있는 것 :

• 확실 할 수 없습니다 가진 mlocate/slocate당신의 색인 /backup-root/(당신은 사용할 수 있습니다 prunefs 시설을 하지 않는 것이에) 또는 메타 데이터 캐시 부수고하게 손상 백업 시간을 어떤 severly 것이다;
• 같은 이유로 피가 실행 du에 /backup-root/. 필요한 경우 du관심있는 특정 하위 폴더에서만 실행 하십시오.
• vfs_cache_pressure기본값 (100)에서 더 보수적 인 값 (10 또는 20)으로 낮 춥니 다 . 이것은 커널에게 데이터 캐싱보다는 메타 데이터 캐싱을 선호하도록 지시합니다. 결과적으로 rsnapshot/rsync발견 단계를 가속화해야합니다 .
• 당신은을 통해 예를 들어, 연속 기입 메타 데이터 캐싱 장치를 추가하는 시도 할 수 lvmcache 또는 Bcach 읽기 . 이 메타 데이터 장치는 분명히 SSD 여야합니다.
• 사용 가능한 RAM을 늘리십시오.
• ext4를 사용할 때 inode 할당 문제에주의하십시오 ( 예를 들어 여기 를 읽으 십시오 ). 이것은 성능과 직접 관련이 없지만 ext 기반 파일 시스템에 너무 많은 파일이있을 때 중요한 요소입니다.

시도 할 수있는 다른 것들-그러나 이들은 파괴적인 작업입니다.

• 모두 XFS를 사용 -ftype하고 -finobt옵션을 설정;
• 압축 ARC 및 primarycache=metadata설정 (및 읽기 전용 캐시의 경우 L2ARC )과 함께 Linux (ZoL)에서 ZFS를 사용하십시오 .

이 파일 시스템은 SEEK 작업이 많지만 IO 처리량이 적은 대량의 작은 파일을 저장합니다.

🎉

이것은 오늘날 많은 사람들을 사로 잡는 것입니다. 아아, 기존의 FS는 여기서 잘 확장되지 않습니다. 이미 가지고있는 설정과 관련하여 몇 가지 조언을 해줄 수 있습니다. HDD의 RAID-6에 대한 EXT4 :

1. 낮추고 vm.vfs_cache_pressure그것은 1이라고 말할 아래 바이어스 캐싱 등 변경 데이터 대신 이상의 메타 데이터 (아이 노드 dentry)를 향해 자체를 보존하며 구하고 수를 감소시키는 긍정적 인 효과를 가져야
2. RAM을 더 추가하십시오 . 피기 앱을 실행하지 않는 서버에서는 이상하게 보일 수 있지만 검색을 줄이는 유일한 방법은 16GB 만 있다면 더 많은 메타 데이터를 더 빠른 스토리지에 보관하는 것입니다. RAM 양을 늘리십시오
3. 내가 말했듯이 EXT4는 사용 사례에 적합하지 않지만 여전히 통증을 완화하기 위해 제공되는 기능 중 일부를 사용할 수 있습니다.
   • 외부 저널 이 지원되므로 SSD (더 나은 미러링)를 추가하고 저널을 그곳에 배치 할 수 있습니다. " ext4 : 외부 저널주의 사항 "을 확인하십시오 .
   • 다음을 사용 하여 저널 모드 를 "모든 데이터 저널링"마운트로 전환하십시오.data=journal
4. 단일 FS 범위 밖으로 파일을 이동해 보십시오 . 예를 들어, 여기에 LVM-2가있는 경우 더 작은 크기의 볼륨을 생성하고 한동안 사용할 수 있습니다.
   • LVM-2가 없다면 / dev / loop를 사용하여 시도해 볼 수는 있지만 그렇게 편리하지는 않을 것입니다.

UPD. : LSR ( Linux Software RAID ) RAID-6으로 밝혀 졌으므로 여기에 추가 항목이 있습니다.

5. LSR에는 많은 사람들이 간과하는 것처럼 보이는 자체 튜닝 옵션이 있습니다
   • 스트라이프 캐시 는 최대로 설정할 수 있습니다. echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size— 크기는 청크 크기의 배수이므로 선택한 청크 크기에 따라 다른 양의 RAM이 필요하므로주의해서 (필요한 경우 더 적은 값 사용)
   • 미러링 된 SSD에도있을 수있는 외부 저널 ( 현재 저널없이 생성 된 MD 디바이스는 하나를 사용하도록 변환 할 수 없음 )

— 그것은 처음부터 다시 디자인하지 않고도 개선 될 수있는 것의 대부분 일 것입니다.

파일 시스템 (60TB 네트)이 사용량이 50 %를 초과하여 성능이 매우 떨어집니다. 현재 사용량은 75 %입니다

디스크 공간 점유 수준이 높으면 조각화가 악화되기 때문에 이는 매우 심각한 문제입니다. 그리고 더 많은 조각화는 더 많은 탐색을 의미합니다. 더 이상 50 %에 도달하기 전에 허용 가능한 성능을 제공 한 이유가 더 이상 없습니다. 많은 매뉴얼에는 FS가 75-80 % 뒤에서 자라지 않도록하는 명확한 권장 사항이 있습니다.

이 경우 RAID6는 큰 도움이되지 않습니다. ZFS와 같은 것은 훨씬 빠른 메타 데이터 및 디렉토리 액세스를 가능하게하고 속도는 동일하게 유지합니다.

RAID-6은 드라이브를 스트라이핑하므로 모든 IO가 모든 드라이브로 이동합니다. 작은 파일이 많으면 비효율적입니다. 그러나 이것은 아마도 당신의 주요 문제가 아닙니다 ...

Ext4는 수백만 개의 파일이있는 큰 파일 시스템에는 적합하지 않습니다. XFS를 사용하십시오 . 1,2 PB만큼 큰 XFS 파일 시스템과 10 억 개의 파일로 문제없이 XFS 파일 시스템을 실행하고 있습니다. XFS를 사용하면됩니다 .

내 질문에 대답 한 모든 사람에게 감사합니다.

이것은 내가 어떻게 해결했는지입니다.

우선, 보드에 최대량의 RAM을 추가했습니다. 불행하게도, 보드는 최대 64GB의 RAM 만 지원합니다. 확장 후 동작을 관찰했으며 실망했습니다. 사용 가능한 모든 RAM이 IO 캐시에 사용되었지만 RSNAPSHOT-Backup의 성능은 크게 향상되지 않았습니다.

그래서 나는 큰 철퇴를 당겨야했습니다. 2 개의 1TB NVME 디스크를 추가하고 RAID 1에 조립했습니다. 8x 10TB HDD로 구성된 RAID 6은 하나의 RAID 1 (2x 10TB HDD, ext4로 구성) 및 하나의 RAID 5 (6x10TB HDD로 구성)로 분해되었습니다. RAID 1에는 운영 체제와 서버의 작업 복사본이 포함되어 있습니다 (이 드라이브와 하루에 4 번 재 동기화 됨).

RAID5는 이제 BCACHE 지원 장치이며 NVME-RAID 1에 의해 지원되며 ext4로 포맷됩니다. 이 드라이브에는 RSNAPSHOT 사본이 포함되어 있습니다. 매일 밤 파일이 RAID1에서 RAID5로 재 동기화되어 작업 사본과 백업 스냅 샷이 포함 된 이전 RAID6에 비해 RAID5의 IO 처리량이 절반으로 줄어 듭니다. BCache 덕분에 문자 그대로 모든 단일 파일이 디스크에 기록되는 것은 아니지만 하나의 블록에 대한 모든 변경 사항은 몇 번의 단일 파일 변경 사항이 포함되어 있어도 한 번 기록됩니다. 이는 HDD의 IOPS를 더욱 줄였습니다.

마지막으로 RSnapshot 구성을 변경했습니다. 이전에는 31 개의 일일 스냅 샷과 18 개의 월간 스냅 샷이 있었으므로 49 개의 백업 생성이 발생했습니다. 이제 고전적인 7d / 4w / 12m / 1y-Design을 사용하여 백업 생성량을 24로 줄입니다.

이러한 변경 후 (그리고 위에서 언급 한 64GB RAM으로) 한 스냅 샷의 지속 시간은 ~ 20 시간에서 1.5 시간으로 줄었습니다. BCache 장치의 캐시 적중률은 82 %입니다 (정기 작동 6 주 후).

임무 완수. 여러분의 생각과 의견에 감사드립니다.