Apakah LVM memengaruhi kinerja?

Saya harus memigrasi beberapa server ke Linux, dan satu aspek penting yang perlu saya evaluasi adalah bahwa sistem host baru saya harus memiliki kapasitas penyimpanan elastis. Secara alami, melakukan beberapa penelitian dasar, saya menemukan LVM.

Apakah ada penalti kinerja untuk menggunakan lvm? Jika demikian, bagaimana saya bisa mengukurnya?

Apa yang saya pertimbangkan sekarang adalah untuk memiliki Linux sebagai OS host dengan LVM dan kotak Linux tervirtualisasi berjalan di atasnya (haruskah saya menambahkan LVM pada OS tamu juga?).

LVM dirancang sedemikian rupa agar tidak terlalu mengganggu. Dari sudut pandang userspace, sepertinya lapisan "barang virtual" di atas disk, dan tampaknya wajar untuk membayangkan bahwa semua I / O sekarang harus melewati ini sebelum sampai ke atau dari yang sebenarnya perangkat keras.

Tapi tidak seperti itu. Kernel sudah perlu memiliki pemetaan (atau beberapa lapisan pemetaan sebenarnya) yang menghubungkan operasi tingkat tinggi seperti "tulis ini ke file" ke driver perangkat yang pada gilirannya terhubung ke blok aktual pada disk.

Ketika LVM sedang digunakan, pencarian itu diubah, tapi itu saja. (Karena itu harus tetap terjadi, melakukannya sedikit berbeda adalah kinerja hit diabaikan.) Ketika datang untuk benar-benar menulis file, bit mengambil jalur langsung ke media fisik seperti yang seharusnya.

Ada kasus di mana LVM dapat menyebabkan masalah kinerja. Anda ingin memastikan blok LVM disejajarkan dengan benar dengan sistem yang mendasarinya, yang harus terjadi secara otomatis dengan distribusi modern. Dan pastikan Anda tidak menggunakan kernel lama yang mengalami bug seperti ini . Oh, dan menggunakan snapshot LVM menurunkan kinerja (dan semakin meningkat dengan setiap snapshot aktif). Tetapi sebagian besar, dampaknya harus sangat kecil.

Adapun yang terakhir: bagaimana Anda bisa menguji? Alat benchmarking disk standar adalah Bonnie ++ . Buat partisi dengan LVM, ujilah, hapus itu dan (di tempat yang sama, untuk menjaga faktor-faktor lain tetap identik) buat sistem file biasa dan patok lagi. Mereka harus mendekati identik.

LVM, seperti yang lainnya, adalah anugerah campuran.

Sehubungan dengan kinerja, LVM akan menghalangi Anda sedikit karena itu adalah lapisan abstraksi lain yang harus dikerjakan sebelum bit mengenai (atau dapat dibaca dari) disk. Dalam sebagian besar situasi, hit kinerja ini praktis tidak dapat diukur.

Kelebihan LVM termasuk fakta bahwa Anda dapat menambahkan lebih banyak penyimpanan ke sistem file yang ada tanpa harus memindahkan data. Kebanyakan orang menyukainya untuk keuntungan ini.

Salah satu kelemahan LVM yang digunakan dengan cara ini adalah bahwa jika penyimpanan tambahan Anda mencakup disk (yaitu melibatkan lebih dari satu disk) Anda meningkatkan kemungkinan bahwa kegagalan disk akan dikenakan biaya data. Jika sistem file Anda membentang dua disk, dan salah satunya gagal, Anda mungkin hilang. Bagi kebanyakan orang, ini adalah risiko yang dapat diterima karena alasan ruang-vs-biaya (yaitu jika ini benar-benar penting akan ada anggaran untuk melakukannya dengan benar) - dan karena, seperti yang mereka katakan, cadangan itu baik, bukan?

Bagi saya, satu-satunya alasan untuk tidak menggunakan LVM adalah bahwa pemulihan bencana tidak (atau setidaknya, tidak) didefinisikan dengan baik. Disk dengan volume LVM yang memiliki OS orak-arik di atasnya tidak bisa dengan mudah dilampirkan ke komputer lain dan data pulih dari itu; banyak instruksi untuk memulihkan volume LVM tampaknya termasuk langkah-langkah seperti kembali ke masa lalu dan menjalankan vgcfgbackup, kemudian menyalin file / etc / lvmconf yang dihasilkan ke sistem hosting volume tertutup Anda . Semoga semuanya telah berubah dalam tiga atau empat tahun sejak saya terakhir kali harus melihat ini, tetapi secara pribadi saya tidak pernah menggunakan LVM untuk alasan ini.

Itu kata.

Dalam kasus Anda, saya akan berasumsi bahwa VM akan relatif kecil dibandingkan dengan sistem host. Ini berarti bagi saya Anda lebih mungkin ingin memperluas penyimpanan di VM nanti; ini paling baik dilakukan dengan menambahkan disk virtual lain ke VM dan kemudian menumbuhkan filesystem VM yang terpengaruh. Anda tidak memiliki kerentanan spanning-multiple-disks karena disk virtual kemungkinan besar akan berada pada perangkat fisik yang sama pada sistem host.

Jika VMs akan memiliki kepentingan bagi Anda sama sekali, Anda akan RAID'ing sistem host entah bagaimana, yang akan mengurangi fleksibilitas untuk menumbuhkan penyimpanan nanti. Jadi fleksibilitas LVM mungkin tidak diperlukan.

Jadi saya kira Anda tidak akan menggunakan LVM pada sistem host, tetapi akan menginstal VM untuk menggunakan LVM.

Secara umum: Jika Anda menambahkan lapisan kompleksitas baru ("alias lebih banyak yang harus dilakukan") tidak ada yang lebih cepat. Catatan: Anda hanya menambahkan pekerjaan dan tidak 'mengubah' cara kerjanya.

Bagaimana Anda bisa mengukur sesuatu? Nah, Anda membuat satu partisi dengan LVM dan yang tanpa, lalu gunakan patokan normal dan jalankan saja. Seperti orang-orang di

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Seperti yang terlihat, hanya sedikit berdampak pada kecepatan. Itu tampaknya sejalan dengan temuan orang lain yang menggunakan tolok ukur:

"ext4 lebih cepat dengan LVM daripada tanpa, dan tolok ukur filesystem lainnya" Linux Kernel Mailing List

Tetapi hanya melakukan benchmark sendiri dan melihat apakah perangkat keras dan OS yang ingin Anda gunakan berperilaku sama dan jika Anda dapat mengabaikan dampak (mungkin sedikit) dampak dari lapisan kompleksitas tambahan yang memberi Anda penyimpanan elastis.

Haruskah Anda menambahkan LVM ke OS tamu: Itu tergantung pada apakah Anda memerlukan OS tamu untuk memiliki penyimpanan elastis juga, bukan? Kebutuhan Anda menentukan apa yang harus Anda gunakan.

Haruskah saya menambahkan LVM pada OS tamu juga?

Anda tidak boleh, karena memiliki sistem file ext3 atau ext 4 di dalam host Volume Logika sudah cukup. Tidak perlu menambahkan Volume Group lain dan Volume Fisik dan Volume Logis di dalamnya.

Tidak akan ada banyak hit kinerja hanya dari LVM, tetapi jika Anda bersedia untuk mengambilnya, gunakan zfs sebagai gantinya. Anda mendapatkan manajemen volume dan pemulihan dan segala macam fitur hebat lainnya.

Tidak ada yang menyebutkan lvm2 dapat membuat kecepatan baca dan tulis dikalikan (mirip dengan raid0). Saya pribadi menggunakan 3 disk identik dan lebih dari itu lvm2 dalam mode stripped, operasi baca dan tulis membutuhkan 1/3 waktu, ini adalah dampak besar, sistem file tiga kali lebih cepat daripada itu. Saya tahu: semua disk gagal dan semua data di dalamnya tidak dapat diakses; tetapi itu tidak berarti ada yang hilang, karena BackUP adalah suatu KEHARUSAN, tidak seperti Raid, LVM2, ZFS akan menghindari untuk memiliki BackUP; jadi saya tidak pernah menggunakan mirroring, raid5 dan semacamnya, saya selalu menggunakan stripping (untuk mendapatkan kinerja terbaik) dan telah menyinkronkan BackUPs. ZFS sangat bagus untuk kompresi on-the-fly, dan dengan parameter salinan lebih besar dari satu adalah seperti mirroring, tetapi satu hal yang ZFS miliki dan tidak ada orang lain miliki adalah auto-recover on-the-fly bit busuk (bit yang secara spontan berubah sementara disk dimatikan),

Untuk melanjutkan: saya menggunakan ZFS hanya untuk BackUPs saya di disk eksternal, beberapa (dua atau tiga) ssd dengan lvm2 bergaris untuk OS (aftwr upgrade saya mengulangi klon OS), saya cenderung menggunakan OS yang tidak dapat diputuskan; dan saya menggunakan beberapa (enam) disk spinnin dengan lvm2 dilucuti untuk data, seperti mesin virtual, lagi-lagi setelah ada perubahan saya ulang Backups; jadi setelah setiap disk gagal saya hanya perlu menggantinya dan mengembalikan cadangan terakhir; sekarang hari saya sudah dekat kecepatan menulis 1.8GiB / s, jadi mengembalikan satu mesin virtual dari BackUP hanya membutuhkan waktu kurang dari 30 detik (32GiB per disk mesin virtual).

Jadi jawaban saya adalah: jangan hanya menggunakan satu hal, jadilah cerdas dan gunakan yang terbaik dari setiap bagian, lvm2 dilucuti lebih cepat daripada mdraid level 0, lebih ketika menggunakan enam disk berputar; satu peringatan dengan stripping ssd, dua dan tiga baik, empat ssd dapat menurunkan kinerja (tes saya memberikan kecepatan tulis yang lebih rendah ketika saya menggunakan empat ssd identik dalam mode stripped, tidak masalah jika lvm, mdraid0, dll), sepertinya SSD TRIM dan semacamnya amplifikasi tulis dapat menjadi penyebab utama menambahkan lebih banyak SSD ke volume yang dilucuti membuat kecepatan menulis lebih rendah.

Waring dengan ssd, dan semua raid0 (volume yang dilucuti), menyelaraskan semuanya dengan sempurna, menetapkan ukuran cluster pada filesystem dengan benar, ukuran stip, dll sehingga tidak ada yang menyebabkan degradasi; sebagai sampel: sektor disk adalah 2048, jadi 2K pada setiap baca / tulis sebagai minimun, tidak pernah menggunakan sistem file yang menggunakan clusyer 512 byte, lebih dari itu, lebih baik menggunakan ukuran cluster 2K atau 4K; sekarang bayangkan Anda menggunakan 3xHDD, masing-masing sektor 2K, jadi pada setiap cluster sistem file baca / tulis akan menjadi 3x2K = 6K, tetapi itu tidak mungkin pada banyak filesystem, lalu pikirkan bagaimana jika menggunakan ukuran cluster 64K, 64K / 6K = 32 / 3, yang menyebabkan tidak seimbang, jadi tidak optimal, dan sebagainya. Buat matematika untuk mendapatkan ukuran kluster yang optimal.

Hasil terbaik saya adalah: Cluster size = stripsize * jumlah disk pada garis; dengan cara itu setiap baca / tulis adalah ukuran yang tepat yang menyebabkan semua disk bekerja, sehingga kecepatan meningkat sangat bagus. Sebuah contoh ukuran cluster 192K untuk 3 disk dengan ukuran strip 64K; contoh lain ukuran cluster 192K untuk 6 disk dengan ukuran strip 32K.

Dan ingatlah untuk selalu menguji disk tunggal dalam 4K, 8K, 16K, 32K, 64K blok; banyak disk memberikan kecepatan yang sangat buruk dengan angka lebih rendah seperti 4K, tetapi memberikan waktu lebih dari sepuluh kali lebih cepat ketika pada 64K, 128K atau lebih tinggi.

Ya, menggunakan ukuran cluster besar dapat membuat ruang limbah hilang pada las cluster masing-masing file (jika Anda menggunakan jutaan file hanya masing-masing 1 byte) lebih baik menggunakan sistem compact / pack on-the-fly melalui sistem file, sebagai sampel disk 4TiB dengan ukuran cluster 4K hanya dapat memiliki kurang dari 4TiB / 4K = 1073741824 file masing-masing 1Byte, itu hanya 1GiB jika semua file berukuran 1Byte (ukuran cluster 4K), semakin besar ukuran cluster terburuk, tetapi jika file berukuran besar, seperti mesin virtual (dekat 32GiB sebagai sampel, atau hanya beberapa megabita) yang hilang hanya ada pada cluster terakhir; file begitu besar, ukuran cluster besar jauh lebih baik untuk kinerja, tetapi berhati-hatilah bagaimana mesin virtual menggunakannya.

Tidak ada yang akan memberi tahu Anda rahasia ini: di dalam tamu tidak menggunakan ukuran cluster 4K, gunakan ukuran cluster yang sama dengan ukuran cluster di mana disk virtual berada, atau beberapa.

Ya, saya adalah manic mendapatkan kecepatan tertinggi di dalam disk tamu, seperti yang saya katakan dengan 6 disk berputar saya mendapatkan dekat 1.7GiB / s, kecepatan bus SATA III adalah hambatan, bukan disk itu sendiri. Saya menggunakan disk high-end (tidak murah), cache 128MiB dengan kecepatan tulis masing-masing 283MiB / s.

Untuk Anda dan untuk semua orang: Yang terbaik adalah mempelajari bagaimana ukuran cluster, ukuran stripe dan ukuran blok harus dikaitkan sebelum melakukan tes kecepatan apa pun, jika tidak pengujian LVM2 atau RAID lain (juga ZFS) dapat memberikan kesimpulan yang SALAH.

Hanya contoh untuk itu: Saya menguji waktu boot linux saya dengan 2 x 60MiB / s 2,5 inci 5400rpm disk Sata pada mainboard port Sata II, dan kemudian menguji dengan 2xSSD Sata III (mereka dapat menulis lebih dari 250MiB / s masing-masing jika terhubung ke Sata III port), waktu booting hanya membutuhkan waktu kurang dua detik, hanya dua detik pada booting lima menit, mengapa? karena sebagian besar disk waktu boot tidak digunakan, ia melakukan hal-hal pada ram dan cpu, tetapi tidak i / o.

Allways menguji hal nyata yang akan Anda lakukan, bukan hanya kecepatan kasar (dengan kata lain, kecepatan maks).

Kecepatan maks baik untuk diketahui sedikit tidak dapat diwakili, Anda mungkin tidak menggunakan disk pada kecepatan maks 100% dari waktu, OS dan APP harus melakukan hal-hal pada ram dan cpu tanpa I / O, sehingga pada saat itu kecepatan disk tidak penting sama sekali.

Semua orang mengatakan SSD meningkatkan banyak kecepatan Boot Windows, pada pengujian saya yang juga PALSU, itu hanya saya membuktikan 28 detik pada waktu booting hampir menit kesembilan.

Jadi jika Anda menyukai saya: Linux copy-to-ram saat boot, SSD tidak akan lebih baik daripada memutar HDD, saya juga telah menguji USB 3.1 Gen2 stick (baca 139MiB / s), waktu boot hanya diberikan beberapa detik pada sebuah boot lima menit, mengapa? mudah, pembacaan dilakukan ketika menyalin ke ram, lebih dari disk / ssd / usb-stick tidak digunakan lagi pada sisa baut, data pada ram, seperti ram-drive.

Sekarang saya menjual semua SSD yang saya miliki, mereka tidak meningkatkan Linux copy-on-ram saat boot, tetapi pembandingan mereka mengatakan mereka 5x kali lebih cepat ... lihat, benchmark memberikan kesimpulan SALAH ... yest, test dan test real hari kerja.

Semoga ini bisa hal-hal laki-laki jelas ... LVM dengan ukuran cluster dan stripe buruk jauh lebih mempengaruhi daripada overhead lapisan.