Opsi untuk peningkatan kinerja pada Filesystem yang sangat besar dan IOWAIT yang tinggi


10

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


2
Disk lebih cepat, lebih disukai SSD. RAM sebanyak mungkin untuk membaca caching. 16GiB bahkan tidak di planet yang sama dengan RAM yang cukup. Dapatkan BANYAK, bahkan 512GiB atau lebih. Dan tentu saja jangan gunakan RAID 6.
Michael Hampton

Terima kasih untuk balasan Anda. Saya mengetahui opsi SSD, tetapi ini membuat perbedaan antara $ 7000 Server atau $ 70000 Server untuk membuat cadangan data. Petunjuk RAM adalah yang baik, tapi saya khawatir saya hanya akan mendapatkan kinerja sistem file seperti perawan jika saya benar-benar menghindari DISK IO untuk operasi SEEK yang berarti pada 60TB net. kapasitas cache RAM 60TB, bukan? Saya menghindari Filesystem lain selain EXT2 / 3/4 di masa lalu, tapi sekarang saya benar-benar terbuka untuk opsi dalam arah ini, jika mereka mau membantu. :)
t2m

Apa rekomendasi Anda untuk penggantian RAID6 di konfigurasi disk ini?
t2m

1
"Sebenarnya ada banyak file kecil dari server yang berbeda yang diambil langsung melalui rsnapshot setiap hari (beberapa INODES langsung ke file yang sama." - Saya pikir maksud Anda banyak tautan / nama ke inode yang sama. hanya satu inode, tetapi dua (atau lebih) tautan / nama
marcelm

1
Bung, jika itu adalah server 7000 USD maka STOP MENDAPATKAN RIPPED OFF. Dan menambahkan 1.000 USD dalam PCIe SSD ke server tidak akan secara ajaib menjadikannya server 70k SSD.
TomTom

Jawaban:


11

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).

Terima kasih banyak atas balasan ini. Seperti yang mungkin Anda duga, saya punya sesuatu untuk dibaca sekarang. Opsi vfs_cache_pressure sangat menarik. Saya telah bermain-main dengan cache selama beberapa menit sekarang dan saya pikir, Sistem menjadi sedikit lebih responsif (daftar direktori, autocomplete, dll.). Saya akan memeriksa poin lainnya juga dan memberikan umpan balik. Terima kasih lagi.
t2m

"primarycache = pengaturan metadata (dan, mungkin, L2ARC untuk cache read-only)." ZFS tidak dapat melakukan keduanya, saya menulis di sisi bawahnya yang paling menonjol: medium.com/p/zfs-is-raid5-of-2010s-eefaeeea2396
poige

@poige karena jumlah RAM yang rendah, saya berbicara tentang caching metadata di L2ARC (selain apa yang sudah di-cache di ARC). Bagaimanapun, caching data seharusnya tidak membuat perbedaan besar untuk rsnapshotserver cadangan.
shodanshok

1
Saya mengklarifikasi bahwa satu-satunya di L2ARC akan menjadi metadata apa pun yang terjadi. :) Mengenai jumlah RAM, 16 GB sama sekali bukan RAM untuk volume keseluruhan HDD itu. Minimum yang masuk akal adalah sekitar 128 GB, karenanya jika ditingkatkan, Anda tidak lagi terbatas pada 16 GB
poige

@marcelm Anda benar: Saya bingung -huntuk hal-hal yang sama sekali berbeda ( -Huntuk rsync...). Saya memperbarui jawaban saya.
shodanshok

6

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:

  1. 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%.


Anda jelas mengisyaratkan bahwa ext4 pada raid-6 bukanlah cara yang Anda inginkan. Maukah Anda menguraikan pengaturan yang akan Anda rekomendasikan?
marcelm

2
Sebenarnya itu tugas yang terlalu rumit untuk diuraikan. Untuk beberapa kasus akan lebih baik untuk memilih FS konvensional bahkan jika seseorang memiliki banyak file, untuk yang lain (kasus) tidak ada cara di awal. Anda dapat melihat intro yang bagus tentang mengapa CEPH meninggalkan POSIX FS sama sekali dan beralih ke DB. BTW, ketika mereka menggunakan FS mereka lebih suka XFS. Saya mungkin akan melakukan hal yang sama. Mengenai RAID-6, ini merupakan pengali IOPS utama - untuk setiap penulisan, ia harus memperbarui paritas pada 2 perangkat lain. Jadi, mungkin semacam pendekatan RAID-x0. Dengan dukungan kompresi on-fly, mungkin masuk akal untuk menggunakan bahkan RAID-10. Tentu saja ada cara ...
poige

1
… Untuk mempercepatnya lebih jauh dengan cache SSD (bcache, dm-cache, ZIL + L2ARC internal ZFS) tetapi praktik mungkin memiliki beberapa kendala sendiri yang secara efektif menonaktifkan cara-cara. Jadi ini sebabnya saya mengatakan "terlalu rumit". Seseorang perlu mengetahui persyaratan dan sumber daya yang akan tersedia untuk mencapai tujuan.
poige

1
Saya mengerti itu meminta terlalu banyak untuk menghasilkan solusi lengkap, tetapi bahkan braindump yang Anda masukkan dalam komentar di atas bisa menjadi titik awal yang baik untuk penelitian lebih lanjut kepada siapa pun yang menghadapi masalah serupa; terima kasih :)
marcelm

0

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


0

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 .


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.