LVM performansı etkiler mi?

Birkaç sunucuyu Linux'a taşımalıyım ve değerlendirmem gereken önemli bir nokta da yeni ana bilgisayar sistemimin esnek depolama kapasitesine sahip olması gerektiği. Doğal olarak, bazı temel araştırmalar yaparak LVM ile karşılaştım.

Lvm kullanmanın herhangi bir performans cezası var mı? Eğer öyleyse, nasıl ölçebilirim?

Şu an üzerinde düşündüğüm şey, Linux'u LVM barındıran bir ana bilgisayar işletim sistemi ve üstünde çalışan sanallaştırılmış Linux kutularına sahip olmak. (Misafir işletim sistemine de LVM eklemem gerekir mi?).

LVM, gerçekten çok fazla uğraşmasını engelleyecek şekilde tasarlanmıştır. Kullanıcı açısından bakıldığında, diskin üstündeki başka bir "sanal malzeme" katmanına benziyor ve tüm G / Ç'lerin gerçek durumdan gelmeden veya bundan önce bunu geçmesi gerektiğini düşünmek doğal görünüyor. donanım.

Ama öyle değil. Çekirdeğin halihazırda diskteki gerçek bloklara bağlanan aygıt sürücülerine "bunu bir dosyaya yaz" gibi yüksek seviyeli işlemleri bağlayan bir eşlemeye (veya aslında birkaç haritalama katmanına) sahip olması gerekir.

LVM kullanımdayken, bu arama değiştirilir, ama hepsi bu. (Yine de gerçekleşmesi gerektiğinden, biraz farklı bir şekilde yapmak ihmal edilebilir bir performans isabetine neden olur.) Dosyayı gerçekten yazmaya gelince, bitler fiziksel medyaya doğrudan yaptıkları gibi doğrudan bir yol izlerler.

LVM'nin performans sorunlarına neden olabileceği durumlar vardır. LVM bloklarının, modern dağıtımlarla otomatik olarak gerçekleşmesi gereken temel sisteme uygun şekilde hizalandığından emin olmak istiyorsunuz. Ve benzeri hatalar tabi eski tanelerini kullanılmadığından emin olun bu bir . Oh, ve LVM anlık görüntülerini kullanmak performansı düşürür (ve her aktif anlık görüntü için giderek daha fazla). Ancak çoğunlukla, etki çok küçük olmalıdır.

Son olarak: nasıl test edebilirsiniz? Standart disk kıyaslama aracı bonnie ++ . LVM ile bir bölüm yapın, test edin, silin ve (aynı yerde, diğer faktörleri aynı tutmak için) düz bir dosya sistemi oluşturun ve tekrar kıyaslama yapın. Aynı kalmalılar.

LVM, her şey gibi, karışık bir nimettir.

Performans açısından, LVM sizi biraz zorlaştıracaktır, çünkü diske bitmeden (veya okunabiliyorsa) önce işlenmesi gereken başka bir soyutlama katmanıdır. Çoğu durumda, bu performans hedefi pratik olarak ölçülemez olacaktır.

LVM'nin avantajları, verileri taşımak zorunda kalmadan mevcut dosya sistemlerine daha fazla depolama ekleyebilmenizi içerir. Çoğu kişi bu avantaj için hoşuna gider.

Bu şekilde kullanılan LVM'nin bir dezavantajı, ek depolama alanınız diskleri (yani birden fazla diski içeriyorsa) diskin yayılması durumunda, bir disk arızasının size maliyet getirme olasılığını artırmanızdır. Dosya sisteminiz iki diske yayılıyorsa ve ikisi de başarısız olursa, muhtemelen kaybolursunuz. Çoğu insan için, bu durum uzay-vs-maliyet nedenlerle kabul edilebilir bir risktir (bu orada doğru bir şekilde yapmak için bir bütçe olacak çok önemli yani ise) - ve dedikleri gibi, çünkü yedekleri vardır , değil iyi?

Benim için LVM kullanmamanın tek nedeni felaket kurtarma işleminin iyi tanımlanmamış (veya en azından) olmamasıdır. Üzerinde şifreli bir işletim sistemi olan LVM birimlerine sahip bir disk, başka bir bilgisayara trivally eklenemedi ve veriler kurtarıldı; LVM birimlerinin kurtarılmasıyla ilgili talimatların birçoğu zaman içinde geri gitmek ve vgcfgbackup komutunu çalıştırmak gibi adımlar içeriyor gibi görünüyordu , ardından elde edilen / etc / lvmconf dosyasını hortumunuzu barındıran sisteme kopyalayın . Umarım, buna bakmak zorunda kaldığımdan beri üç ya da dört yıl içinde işler değişti, ama şahsen bu nedenle LVM'yi asla kullanmam.

Bahsedilen.

Sizin durumunuzda, VM'lerin ana sisteme kıyasla nispeten daha küçük olacağını farz ediyorum. Bu, benim için bir VM'de depolamayı daha sonra genişletmek istemenizin daha muhtemel olduğu anlamına gelir; bu en iyi şekilde VM'ye başka bir sanal disk ekleyerek ve ardından etkilenen VM dosya sistemlerini büyüterek yapılır. Sanal diskler büyük olasılıkla ana bilgisayar sistemindeki aynı fiziksel aygıtta olacağından, yayılma çoklu diskleri güvenlik açığı yoktur.

Sanal Makineler sizin için hiç bir öneme sahip olacaksa, ana bilgisayar sistemine RAID' olacaksınız, bu da daha sonra artan depolama esnekliğini azaltacaktır. Bu yüzden LVM'nin esnekliği muhtemelen gerekli olmayacak.

Dolayısıyla, ana sistemde LVM kullanmayacağınızı, LVM kullanmak için VM'leri kuracağınızı düşünürdüm.

Genel olarak: Yeni bir karmaşıklık katmanı eklerseniz ("aka daha fazla yapmak") hiçbir şey daha hızlı olmaz. Not: Yalnızca iş eklersiniz ve işin çalışma şeklini 'değiştirmezsiniz'.

Bir şeyi nasıl ölçebilirsin? LVM ile bir bölüm yaratın, diğeri olmadan, sonra normal bir kıyaslama kullanın ve çalıştırın. Millet gibi

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

Görüldüğü gibi, hıza sadece hafif bir etki. Bu, kıyaslama yapan bir başkasının bulgularıyla senkronize edilmiş gibi görünüyor:

"ext4, LVM ile, olduğundan ve diğer dosya sistemi karşılaştırma ölçütlerinden daha hızlıdır" Linux Çekirdek Posta Listesi iş parçacığı

Ancak sadece kendi başınıza kıyaslayın ve kullanmak istediğiniz donanım ve işletim sisteminin aynı şekilde davranıp davranmadığını ve size esnek bir saklama sağlayan ek bir karmaşıklık katmanının (belki biraz) etkisini görmezden gelip gelemeyeceğini görün.

Konuk işletim sistemine LVM eklemelisiniz: Konuk işletim sistemine de esnek bir saklama alanı gerekip gerekmediğine bağlı, öyle değil mi? İhtiyaçlarınız konuşlandırmanız gerekeni belirler.

Konuk işletim sistemine LVM eklemem gerekir mi?

Yapmamalısınız, çünkü ana bilgisayar içinde bir ext3 veya ext 4 dosya sistemi olması Mantıksal Birim yeterli olmalıdır. İçine başka bir Birim Grubu ve Fiziksel Birim ve Mantıksal Birim eklemenize gerek yok.

Sadece lvm'den etkilenecek çok fazla performans olmazdı, ancak almak istemeniz yerine, zfs kullanın. Birim yönetimi ve kurtarılabilirlik ve her türlü diğer harika özelliklere sahip olursunuz.

Hiç kimse lvm2'nin okuma ve yazma hızının çoğalmasını sağlayamaz (raid0'a benzer). Şahsen 3 özdeş disk kullanıyorum ve üzerlerinde lvm2 sıyrılmış modda okuma ve yazma işlemleri zamanın 1 / 3'ünü alıyor, bu büyük bir etki, dosya sistemi üç kat daha hızlı. Biliyorum: herhangi bir disk arızalı ve üzerlerindeki tüm veriler güvenilir olmayacak; ancak bu, herhangi bir kayıp anlamına gelmez, çünkü Backups bir zorunluluktur, Raid, LVM2, ZFS gibi bir şey Backup'lara sahip olmaktan kaçınır; bu yüzden asla, mirroring, raid5 ve benzeri kullanmıyorum, ben hep soyunma kullanıyorum (en yüksek performansı elde etmek için) ve BackUP'ları senkronize ettim. ZFS anında sıkıştırma için mükemmeldir ve kopya parametresi birden fazla büyük aynaya yansıtma gibidir, ancak ZFS'nin sahip olduğu ve kimsenin sahip olmadığı bir şey, bit-rot (kendiliğinden değişen bitlerde disk kapalı),

Devam etmek için: ZFS'yi yalnızca yedek disklerim için harici disklerde kullanıyorum, çoklu işletim sistemi (lvm2 işletim sistemi için lvm2 ile ssd) (sonradan yükseltilen işletim sistemleri klonunu yeniden yapıyorum), işletim sistemi kullanma eğilimindeyim; ve sanal makineler gibi veriler için elimden alınmış lvm2 ile birden fazla (altı) sabit disk kullanıyorum; bu yüzden herhangi bir disk arızasından sonra sadece onu değiştirmem ve son yedeği geri yüklemem gerekir; Şimdi bir gün 1.8Gib / sn yazma hızına yakınım, bu nedenle bir sanal makineyi BackUP'tan geri yüklemek yalnızca 30 saniyeden az sürer (sanal makine diski başına 32GiB).

Yani cevabım: tek bir şey kullanmayın, akıllı olun ve her bir parçanın en iyisini kullanın, lvm2 sıyrılırsa, altı eğirme diski kullanıldığında, mdraid seviye 0'dan daha hızlıdır; ssd, iki ve üç sıyırma ile bir uyarı iyidir, dört ssd performansı düşürebilir (lvm, mdraid0, vb. olursa olsun, sınama modunda dört aynı ssd kullandığımda testlerim düşük yazma hızı verdi), SSD TRIM ve benzeri görünüyor yazma amplifikasyonu, sıyrılan hacme daha fazla ssd eklenmesinin ana nedeni olabilir, daha düşük yazma hızı sağlar.

Ssd ve herhangi bir raid0 (soyulmuş hacimler) ile savaşmak, işleri mükemmel şekilde hizalar, dosya sistemine küme boyutlarını doğru şekilde atar, boyut büyüklüğünü vb. Belirler, böylece hiç kimse bozulmaya neden olmaz; örnek olarak: disk sektörü 2048'dir, bu yüzden minimum olarak herhangi bir okuma / yazmada 2K, asla 512 baytlık küme kullanan bir dosya sistemi kullanmayın, bunun üzerine 2K veya 4K küme boyutunu kullanmak daha iyidir; Şimdi 2K sektörün her biri olan 3xHDD kullandığınızı hayal edin, bu nedenle herhangi bir okuma / yazma optimun dosya sistemi kümesinde 3x2K = 6K olacaktır, ancak bunun çoğu dosya sisteminde mümkün olmadığını düşünün, sonra 64K boyutunda bir 64K / 6K = 32 kullandığınızda ne olacağını düşünün / 3, bu dengesizliğe neden olur, bu yüzden optimal değil vb. Optimum küme büyüklüğü elde etmek için matematik yapın.

En iyi sonuçlarım şöyle: Küme boyutu = şerit boyutu * şerit üzerindeki disk sayısı; Bu şekilde, her okuma / yazma işlemi, tüm disklerin çalışmasına neden olan tam boyuttadır, bu nedenle hız iyileştirme, kesinlikle harikadır. 64K şerit boyutuna sahip 3 disk için örnek bir 192K küme boyutu; 32K şerit boyutu ile 6 disk için başka bir örnek 192K küme boyutu.

Ve her zaman tekli diski 4K, 8K, 16K, 32K, 64K blokta test etmeyi unutmayın; birçok disk, 4K gibi düşük sayılarla gerçekten kötü hızlar verir, ancak 64K, 128K veya daha yüksek sürümlerde on kattan daha hızlı zaman verir.

Evet, büyük küme boyutlarını kullanmak, her dosyanın lastiği kümesinde (her biri yalnızca 1 bayt milyonlarca dosya kullanıyorsanız) yer israfını kaybedebilir, dosya sistemi üzerinde bir kompakt / paket anında sistemi daha iyi kullanmak, bir örnek olarak 4K'lık bir küme boyutuna sahip bir 4TiB diskinin her biri yalnızca 4TiB / 4K'dan az olabilir = 1073741824 her biri 1Byte dosyaya sahip olabilir, yani tüm dosyalar 1Byte boyutundaysa (küme boyutu 4K), daha büyük küme boyutunun en kötü oranıysa, yalnızca 1GiB'dir. dosyalar çok büyük, sanal makineler gibi (örnek olarak 32GiB civarında veya sadece birkaç megabayt) kayıp yalnızca son kümede; çok büyük dosyalar, büyük küme boyutu performans için çok daha iyidir, ancak sanal makinenin onu nasıl kullandığına dikkat edin.

Kimse size bu sırrı söyleyemez: misafirin içinde 4K küme boyutu kullanmayın, sanal diskin bulunduğu yerde küme boyutuyla aynı küme boyutunu kullanın, ya da bir çoğunu.

Evet, konuk diskler içinde en yüksek hızı elde etmenin bir maniciyim, 6 döner diskle dediğim gibi 1.7GiB / s'ye yaklaşıyorum, SATA III veri yolu hızı darboğuş, diskler değil. Yüksek uçlu (ucuz değil) diskler, her biri 283MiB / s yazma hızında 128MiB önbellek kullanıyorum.

Siz ve tüm insanlar için: Herhangi bir hız testi yapmadan önce küme boyutunun, şerit boyutunun ve blok boyutunun nasıl ilişkili olması gerektiğini öğrenmek en iyisidir, aksi takdirde LVM2 veya başka bir RAID (ayrıca ZFS) testi FALSE sonuçları verebilir.

Bunun için sadece bir örnek: Linux önyükleme sürelerimi 2x60MiB / s 2.5 inç 5400rpm Sata diskleri bir Sata II port anakartında test ediyorum ve sonra 2xSSD Sata III ile test ediyorum (Sata III'e bağlıysa her biri 250MiB / s'den fazla yazabilirler) bağlantı noktaları), önyükleme süreleri yalnızca iki saniye daha az sürer, beş dakikalık bir önyüklemede yalnızca iki saniye, neden? önyükleme süresi disklerinin çoğu kullanılmadığından, ram ve cpu üzerinde işler yapıyor ancak giriş / çıkış yapmıyor.

Allways, yapacağınız gerçek gün testini yapar, sadece ham hızları (diğer bir deyişle maksimum hızı) değil.

Maksimum hızın, temsili olmadığını bilmek iyi bir şeydir, diskleri zamanın% 100'ünde maksimum hızda kullanmıyor olabilirsiniz, işletim sistemi ve APP'ler I / O olmadan ram ve cpu üzerinde bir şeyler yapmalıdır, bu nedenle disk hızı hiç önemli değil.

Bütün insanlar SSD'nin çok fazla Windows Önyükleme hızını artırdığını söylüyor, YANLIŞ testlerimde sadece sekiz saniyelik önyükleme süresinde 28 saniyeyi kanıtladım.

Yani benden hoşlanırsanız: Linux açılışta ram'e kopyala, SSD sabit HDD'lerden daha iyi olmayacak, ayrıca USB 3.1 Gen2 stick'i (139MiB / s okunur) test ettim, açılış süresi sadece birkaç saniye etkilendi. beş dakikalık önyükleme, neden? kolay, okuma, RAM'a kopyalanırken yapılır, disk / ssd / usb-stick'ten daha afyer, cıvatanın geri kalanında tekrar kullanılmaz, veriler bir ram sürücüsü gibi ram üzerindedir.

Şimdi sahip olduğum tüm SSD'leri satıyorum, Linux'ta açılışta kopyalamayı geliştirmiyorlar, ancak kıyaslama yapmak onların 5 kat daha hızlı olduklarını söylüyor ... bak, kıyaslama YANLIŞ sonuçlar veriyor… evet, test et ve test et günlük iş.

Umarım bu erkekleri açıklığa kavuşturabilir ... Kötü küme ve şerit boyutlarına sahip LVM, katman üstünden çok daha fazla etki eder.