Saya memiliki Server Cadangan Ubuntu 16.04 dengan HDD 8x10TB melalui SATA 3.0 Backplane. 8 Hardisk dirakit menjadi RAID6, sebuah EXT4 Filesystem sedang digunakan. Filesystem ini menyimpan sejumlah besar file kecil dengan sangat banyak operasi SEEK tetapi IO throughput rendah. Bahkan ada banyak file kecil dari server yang berbeda yang dapat diambil melalui rsnapshot setiap hari (beberapa INODES langsung ke file yang sama. Saya memiliki kinerja yang sangat buruk karena sistem file (60TB net) melebihi penggunaan 50%. Saat ini, penggunaan pada 75% dan a

du -sch /backup-root/

membutuhkan beberapa hari (!). Mesin ini memiliki 8 Cores dan 16G RAM. RAM digunakan sepenuhnya oleh OS Filesystem Cache, 7 dari 8 core selalu idle karena 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

Saya kurang pengalaman dengan penggunaan sistem file semacam ini. Opsi apa yang harus saya sesuaikan ini. Sistem file apa yang akan bekerja lebih baik dengan skenario ini? Apakah ada opsi untuk melibatkan RAM untuk opsi caching lain selain OS-build-in?

Bagaimana Anda menangani jumlah file kecil yang sangat besar pada perangkat RAID besar?

Terima kasih, Sebastian

Saya memiliki pengaturan yang serupa (walaupun lebih kecil), dengan disk 12x 2TB dalam array RAID6, digunakan untuk tujuan yang sama ( rsnapshotserver cadangan).

Pertama, sangat normal untuk du -hsmengambil begitu banyak waktu pada sistem file yang besar dan bekas. Selain itu dumenyumbang hardlink, yang menyebabkan beban CPU yang besar dan meledak di samping beban IO yang jelas.

Kelambatan Anda disebabkan oleh metadata filesystem yang terletak di blok yang sangat jauh (dalam istilah LBA), menyebabkan banyak pencarian. Seperti disk 7.2K RPM normal menyediakan sekitar ~ 100 IOPS, Anda dapat melihat berapa jam, jika bukan hari, diperlukan untuk memuat semua metadata.

Sesuatu yang dapat Anda coba (tidak merusak) memperbaiki situasi:

• pastikan untuk tidak memiliki mlocate/slocatemengindeks Anda /backup-root/(Anda dapat menggunakan fasilitas prunefs untuk menghindari itu), atau metadata cache yang mencemari akan severly Merusak waktu backup Anda;
• untuk alasan yang sama, menghindari berjalan dudi /backup-root/. Jika perlu, jalankan duhanya pada subfolder tertentu yang tertarik;
• lebih rendah vfs_cache_pressuredari nilai default (100) ke yang lebih konservatif (10 atau 20). Ini akan memerintahkan kernel untuk lebih memilih caching metadata, daripada caching data; ini seharusnya, pada gilirannya, mempercepat rsnapshot/rsyncfase penemuan;
• Anda dapat mencoba menambahkan perangkat cache metadata writeth, misalnya melalui lvmcache atau bcache . Perangkat metadata ini jelas harus berupa SSD;
• tingkatkan RAM yang tersedia.
• saat Anda menggunakan ext4, perhatikan masalah alokasi inode (baca di sini untuk contoh). Ini tidak secara langsung berkorelasi dengan kinerja, tetapi merupakan faktor penting ketika memiliki begitu banyak file pada sistem file berbasis ekst.

Hal-hal lain yang dapat Anda coba - tetapi ini adalah operasi yang merusak:

• gunakan XFS dengan keduanya -ftypedan -finobtset pilihan;
• gunakan ZFS di Linux (ZoL) dengan kompresi ARC dan primarycache=metadatapengaturan (dan, mungkin, L2ARC untuk cache read-only).

Filesystem ini menyimpan sejumlah besar file kecil dengan sangat banyak operasi SEEK tetapi IO throughput rendah.

🎉

Ini adalah hal yang menarik banyak orang saat ini. Sayangnya, FSs konvensional tidak memiliki skala yang baik di sini. Saya bisa memberi Anda mungkin hanya beberapa saran ketika datang ke pengaturan yang sudah Anda miliki: EXT4 over RAID-6 pada HDD :

1. Turunkan lebih vm.vfs_cache_pressurerendah, katakanlah ke 1. Ini akan mengubah bias cache ke arah mempertahankan lebih banyak metadata (inode, dentry) daripada data itu sendiri dan itu harus memiliki efek positif dalam mengurangi jumlah pencarian
2. Tambahkan lebih banyak RAM . Walaupun mungkin terlihat aneh untuk server yang tidak menjalankan aplikasi piggy, ingat: satu-satunya cara untuk mengurangi pencarian adalah dengan menjaga lebih banyak metadata dalam penyimpanan yang lebih cepat, mengingat Anda memiliki 16 GB hanya tampaknya itu seharusnya relatif mudah untuk menambah jumlah RAM
3. Seperti yang telah saya katakan EXT4 bukan pilihan yang baik untuk use case yang Anda miliki, tetapi Anda masih dapat menggunakan beberapa fitur yang ada untuk meredakan rasa sakit:
   • jurnal eksternal didukung sehingga Anda dapat mencoba menambahkan SSD (cermin lebih baik) dan letakkan jurnal di sana. Lihat " ext4: jurnal eksternal peringatan "
   • Coba alihkan mode jurnal ke "semua data sedang dijurnal" dengan pemasangandata=journal
4. Coba pindahkan file di luar cakupan FS tunggal . Misalnya, jika Anda memiliki LVM-2 di sini Anda dapat membuat volume dengan ukuran lebih kecil dan menggunakannya untuk sementara waktu, maka ketika sudah penuh, buat yang lain dan seterusnya.
   • Jika Anda tidak memiliki LVM-2, Anda dapat mencoba melakukannya dengan / dev / loop tetapi tidak nyaman dan mungkin kurang performan

UPD. : karena ternyata itu adalah Linux Software RAID (LSR) RAID-6, inilah item tambahan:

5. LSR memiliki opsi penyetelan yang tampaknya diabaikan oleh banyak orang
   • Cache stripe , yang dapat diatur sebagai maksimum: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Tetapi lakukan ini dengan hati-hati (gunakan nilai yang lebih rendah jika diperlukan) karena ukurannya adalah chunk-size multiple dan tergantung pada ukuran chunk yang Anda pilih akan membutuhkan jumlah RAM yang berbeda
   • Jurnal eksternal yang bisa juga di SSD yang dicerminkan ( tetapi saat ini perangkat MD yang dibuat tanpa jurnal tidak dapat dikonversi untuk menggunakannya ).

- Itu mungkin sebagian besar dari apa yang dapat ditingkatkan tanpa desain ulang dari awal.

Saya memiliki kinerja yang sangat buruk karena sistem file (60TB net) melebihi penggunaan 50%. Saat ini, penggunaannya mencapai 75%

Itu masalah yang sangat serius karena tingkat hunian ruang disk yang tinggi hanya memperburuk fragmentasi. Dan lebih banyak fragmentasi berarti lebih banyak mencari. Tidak heran lagi mengapa ia memberikan kinerja yang lebih atau kurang dapat diterima sebelum mencapai 50%. Banyak manual memiliki rekomendasi yang jelas untuk tidak memungkinkan FS tumbuh di belakang 75-80%.

RAID6 tidak banyak membantu Anda dalam hal ini, sesuatu seperti ZFS mungkin memungkinkan metadata dan akses direktori lebih cepat sambil menjaga kecepatan tetap sama.

RAID-6 stripes drive, oleh karena itu semua IO masuk ke semua drive. Itu cukup tidak efisien dengan banyak file kecil. Namun ini mungkin bukan masalah utama Anda yang ...

Ext4 tidak cocok untuk sistem file besar dengan jutaan file. Gunakan XFS . Saya memiliki sistem file XFS yang berjalan hingga 1,2 PB dan dengan sebanyak 1 miliar file, tidak ada masalah. Cukup gunakan XFS .

Terima kasih kepada semua orang yang memberikan jawaban untuk pertanyaan saya.

Inilah, bagaimana saya menyelesaikannya:

Pertama-tama, saya menambahkan jumlah maksimum RAM ke papan tulis. Sayangnya, Dewan hanya mendukung hingga 64GB RAM. Saya mengamati perilaku setelah ekspansi, dan itu mengecewakan. Meskipun semua RAM yang tersedia digunakan untuk IO Cache, kinerja RSNAPSHOT-Backup tidak membaik secara terukur.

Jadi saya harus menarik gada besar. Saya menambahkan dua disk NVT 1TB dan memasangnya ke RAID 1. RAID 6 yang terdiri dari HDD 8x10TB dibongkar menjadi satu RAID 1 (terdiri dari HDD 10TB 10TB, ext4) dan satu RAID 5 (terdiri dari HDD 6x10TB). RAID 1 sekarang berisi Sistem Operasi dan salinan Server yang berfungsi (yang direstynced 4 kali sehari untuk drive ini).

RAID5 sekarang menjadi perangkat yang didukung BCACHE, didukung oleh NVME-RAID 1 dan diformat dengan ext4. Drive ini berisi RSNAPSHOT-Copies. Setiap malam, file-file akan disinkronisasi ulang dari RAID1 ke RAID5, yang membagi dua throughput IO dari RAID5 dibandingkan dengan RAID6 sebelumnya, yang berisi salinan yang berfungsi DAN snapshot cadangan. Berkat BCache, tidak secara harfiah setiap file ditulis ke Disk, tetapi semua perubahan di satu Blok ditulis satu kali, bahkan jika itu berisi beberapa perubahan file tunggal hunderth. Ini semakin mengurangi IOps pada HDD.

Akhirnya, saya mengubah konfigurasi RSnapshot saya. Sebelumnya, ada 31 foto harian dan 18 foto bulanan, yang menghasilkan 49 generasi cadangan. Sekarang, saya memiliki 7d / 4w / 12m / 1y-Design klasik, yang mengurangi jumlah generasi cadangan hingga 24.

Setelah perubahan ini (dan dengan 64GB RAM yang disebutkan di atas), durasi untuk satu foto turun dari ~ 20 jam menjadi 1,5 jam. Perangkat BCache memiliki tingkat Cache-Hit-82% (setelah 6 minggu beroperasi secara teratur).

Misi selesai. Terima kasih kepada Anda semua atas pemikiran dan masukan Anda.