Tôi có Máy chủ dự phòng Ubuntu 16.04 với ổ cứng 8x10TB thông qua bảng nối đa năng SATA 3.0. 8 Harddisks được lắp ráp thành RAID6, Hệ thống tập tin EXT4 đang được sử dụng. Hệ thống tập tin này lưu trữ một lượng lớn các tệp nhỏ với rất nhiều thao tác TÌM KIẾM nhưng thông lượng IO thấp. Trên thực tế, có rất nhiều tệp nhỏ từ các máy chủ khác nhau được chụp lén qua rsnapshot mỗi ngày (nhiều INODES trực tiếp đến cùng một tệp. Tôi có hiệu suất rất kém do hệ thống tệp (mạng 60TB) vượt quá mức sử dụng 50%. Hiện tại, mức sử dụng là 75% và

du -sch /backup-root/

mất vài ngày (!). Máy có 8 lõi và 16G RAM. RAM được sử dụng hoàn toàn bởi Bộ đệm hệ thống tập tin hệ điều hành, 7 trong số 8 lõi luôn không hoạt động vì 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

Tôi đang thiếu kinh nghiệm với loại sử dụng hệ thống tập tin này. Tôi có những lựa chọn nào để điều chỉnh điều này. Hệ thống tập tin nào sẽ hoạt động tốt hơn với kịch bản này? Có tùy chọn nào liên quan đến RAM cho các tùy chọn bộ nhớ đệm khác ngoài tùy chọn tích hợp hệ điều hành không?

Làm thế nào để bạn xử lý một lượng rất lớn các tệp nhỏ trên các cụm RAID lớn?

Cảm ơn, Sebastian

Tôi có một thiết lập tương tự (mặc dù nhỏ hơn), với các đĩa 12x 2TB trong một mảng RAID6, được sử dụng cho cùng một mục đích ( rsnapshotmáy chủ dự phòng).

Đầu tiên, du -hsviệc mất quá nhiều thời gian cho một hệ thống tập tin lớn và được sử dụng như vậy là hoàn toàn bình thường . Hơn nữa, ducác tài khoản cho các liên kết cứng, gây ra tải CPU đáng kể và bùng nổ bên cạnh tải IO rõ ràng.

Sự chậm chạp của bạn là do siêu dữ liệu của hệ thống tập tin được đặt ở các khối rất xa (theo thuật ngữ LBA), gây ra nhiều tìm kiếm. Vì một đĩa RPM 7.2K bình thường cung cấp khoảng ~ 100 IOPS, bạn có thể thấy cần bao nhiêu giờ, nếu không phải ngày, để tải tất cả siêu dữ liệu.

Một cái gì đó bạn có thể cố gắng (không phá hủy) cải thiện tình hình:

• được chắc chắn không có mlocate/slocatelập chỉ mục của bạn /backup-root/(bạn có thể sử dụng các cơ sở prunefs Để tránh điều đó), hoặc siêu dữ liệu bộ nhớ cache trashing.Số sẽ severly GIẢM KHẢ thời gian sao lưu của bạn;
• vì lý do tương tự, tránh chạy dutrên /backup-root/. Nếu cần, duchỉ chạy trên thư mục con cụ thể quan tâm;
• thấp hơn vfs_cache_pressuretừ giá trị mặc định (100) đến giá trị bảo thủ hơn (10 hoặc 20). Điều này sẽ hướng dẫn kernel thích bộ nhớ đệm siêu dữ liệu hơn là bộ đệm dữ liệu; lần lượt, điều này sẽ đẩy nhanh rsnapshot/rsyncgiai đoạn khám phá;
• bạn có thể thử thêm một thiết bị lưu trữ siêu dữ liệu writeth thông qua, ví dụ thông qua lvmcache hoặc bcache . Thiết bị siêu dữ liệu này rõ ràng phải là một ổ SSD;
• tăng RAM có sẵn của bạn.
• như bạn đang sử dụng ext4, hãy lưu ý các vấn đề phân bổ inode (đọc ví dụ ở đây ). Điều này không tương quan trực tiếp đến hiệu suất, nhưng nó là một yếu tố quan trọng khi có quá nhiều tệp trên một hệ thống tệp dựa trên ext.

Những thứ khác bạn có thể thử - nhưng đây là những hoạt động phá hoại:

• sử dụng XFS với cả hai -ftypevà -finobttùy chọn thiết lập;
• sử dụng ZFS trên Linux (ZoL) với ARC được nén và primarycache=metadatacài đặt (và, có thể, L2ARC cho bộ đệm chỉ đọc).

Hệ thống tập tin này lưu trữ một lượng lớn các tệp nhỏ với rất nhiều thao tác TÌM KIẾM nhưng thông lượng IO thấp.

🎉

Đây là điều mà bắt rất nhiều người ngày nay. Than ôi, các FS thông thường không mở rộng quy mô nào ở đây. Tôi có thể cung cấp cho bạn một vài lời khuyên khi cài đặt mà bạn đã có: EXT4 qua RAID-6 trên ổ cứng :

1. Hạ vm.vfs_cache_pressurexuống, nói với 1. Nó sẽ thay đổi xu hướng bộ đệm theo hướng bảo toàn nhiều siêu dữ liệu hơn (inode, nha) thay vì chính dữ liệu và nó sẽ có tác dụng tích cực trong việc giảm số lượng tìm kiếm
2. Thêm RAM . Mặc dù máy chủ không chạy bất kỳ ứng dụng heo nào có vẻ lạ, nhưng hãy nhớ: cách duy nhất để giảm tìm kiếm là giữ nhiều siêu dữ liệu hơn trong bộ nhớ nhanh hơn, với điều kiện là bạn chỉ có 16 GB, có vẻ như nó tương đối dễ tăng dung lượng RAM
3. Như tôi đã nói EXT4 không phải là lựa chọn tốt cho trường hợp sử dụng mà bạn có, nhưng bạn vẫn có thể sử dụng một số tính năng mà nó tạo ra để làm dịu cơn đau:
   • tạp chí bên ngoài được hỗ trợ để bạn có thể thử thêm SSD (được nhân đôi tốt hơn) và đặt tạp chí ở đó. Kiểm tra " ext4: cảnh báo tạp chí bên ngoài "
   • Hãy thử chuyển chế độ nhật ký sang gắn kết "tất cả dữ liệu"data=journal
4. Hãy thử di chuyển các tệp bên ngoài phạm vi FS duy nhất . Ví dụ: nếu bạn có LVM-2 ở đây, bạn có thể tạo các khối có kích thước nhỏ hơn và sử dụng chúng trong một thời gian, sau đó khi nó đầy, hãy tạo một khối khác, v.v.
   • Nếu bạn không có LVM-2, bạn có thể thử làm điều đó với / dev / loop nhưng nó không tiện lợi và có thể ít hiệu suất hơn

CẬP NHẬT. : vì hóa ra là RAID Phần mềm Linux (LSR) RAID-6, ở đây có thêm mục:

5. LSR có các tùy chọn điều chỉnh riêng mà nhiều người dường như bỏ qua
   • Do đó, bộ đệm sọc có thể được đặt thành tối đa: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Nhưng hãy cẩn thận thực hiện việc này (sử dụng giá trị nhỏ hơn nếu cần) vì kích thước là bội số kích thước lớn và tùy thuộc vào kích thước khối bạn đã chọn, nó sẽ chiếm dung lượng RAM khác nhau
   • Nhật ký bên ngoài cũng có thể có trên các ổ SSD được nhân đôi ( nhưng hiện tại thiết bị MD được tạo ra không có thể chuyển đổi tạp chí sang sử dụng một ổ đĩa ).

- Đó có lẽ là hầu hết những gì có thể được cải thiện với thiết kế lại từ đầu.

Tôi có hiệu suất rất kém vì hệ thống tệp (mạng 60TB) vượt quá 50% mức sử dụng. Hiện tại, mức sử dụng là 75%

Đó là vấn đề rất nghiêm trọng bởi vì mức độ chiếm dụng không gian đĩa cao chỉ làm suy yếu sự phân mảnh. Và phân mảnh nhiều hơn có nghĩa là tìm kiếm nhiều hơn. Tự hỏi không còn lý do tại sao nó mang lại hiệu suất ít nhiều chấp nhận được trước khi đạt 50%. Rất nhiều sách hướng dẫn có các khuyến nghị rõ ràng để không cho phép các FS tăng trưởng sau 75% 80%.

RAID6 không giúp bạn nhiều trong trường hợp này, một cái gì đó như ZFS có thể cho phép truy cập thư mục và siêu dữ liệu nhanh hơn nhiều trong khi vẫn giữ tốc độ như cũ.

Ổ đĩa sọc RAID-6, do đó tất cả IO đi đến tất cả các ổ đĩa. Điều đó khá kém hiệu quả với nhiều tệp nhỏ. Tuy nhiên, đây có lẽ không phải là vấn đề chính của bạn ...

Ext4 không phù hợp cho các hệ thống tệp lớn với hàng triệu tệp. Sử dụng XFS . Tôi có các hệ thống tệp XFS chạy tới 1,2 PB và có tới 1 tỷ tệp, không có vấn đề gì. Đơn giản chỉ cần sử dụng XFS .

Cảm ơn tất cả những người đã trả lời cho câu hỏi của tôi.

Đây là cách tôi giải quyết nó:

Trước hết, tôi đã thêm dung lượng RAM tối đa vào bo mạch. Thật không may, Board chỉ hỗ trợ tối đa 64GB RAM. Tôi quan sát hành vi sau khi mở rộng, và thật đáng thất vọng. Mặc dù tất cả RAM có sẵn đã được sử dụng cho IO Cache, hiệu suất của RSNAPSHOT-Backup không cải thiện đáng kể.

Vì vậy, tôi đã phải kéo cây chùy lớn. Tôi đã thêm hai đĩa NVME 1TB và lắp ráp chúng vào RAID 1. RAID 6 gồm 8 ổ cứng 10TB đã được tháo rời thành một RAID 1 (bao gồm 2x 10TB HDD, ext4) và một RAID 5 (bao gồm 6x10TB HDD). RAID 1 hiện chứa Hệ điều hành và bản sao hoạt động của Máy chủ (được nhận 4 lần một ngày vào ổ đĩa này).

RAID5 hiện là thiết bị được hỗ trợ BCACHE, được hỗ trợ bởi NVME-RAID 1 và được định dạng bằng ext4. Ổ đĩa này chứa các bản sao RSNAPSHOT. Mỗi đêm, các tệp được kết nối từ RAID1 đến RAID5, giúp giảm một nửa thông lượng IO của RAID5 so với RAID6 trước đây, chứa các bản sao hoạt động VÀ các bản sao lưu dự phòng. Nhờ BCache, không phải mọi tệp đơn lẻ đều được ghi vào Đĩa, nhưng tất cả các thay đổi trên một Khối được ghi một lần, ngay cả khi nó chứa một số thay đổi tệp đơn lẻ. Điều này tiếp tục giảm IOps trên ổ cứng.

Cuối cùng, tôi đã thay đổi cấu hình RSnapshot của mình. Trước đây, có 31 ảnh chụp nhanh hàng ngày và 18 ảnh chụp nhanh hàng tháng, dẫn đến 49 thế hệ sao lưu. Bây giờ, tôi có 7d / 4w / 12m / 1y-Design cổ điển, giúp giảm số lượng thế hệ dự phòng xuống còn 24.

Sau những thay đổi này (và với RAM 64 GB được đề cập ở trên), thời lượng cho một ảnh chụp nhanh đã giảm từ ~ 20 giờ xuống còn 1,5 giờ. Các thiết bị BCache có tỷ lệ Cache-Hit là 82% (sau 6 tuần hoạt động thường xuyên).

Nhiệm vụ đã hoàn thành. Cảm ơn tất cả các bạn cho những suy nghĩ và đầu vào của bạn.