İki bölüme cevap vereceğim: ilk önce "sıralı ve rasgele ayırma hakkındaki geleneksel cevap genellikle geçerli değildir."
Ardından, Windows fiziksel diskindeki dosyaları ayırmanın ve ek vHBA'lar eklemenin ve fiziksel diskleri aralarında dağıtmanın potansiyel faydalarını tartışacağım.
Windows fiziksel disk düzeyinde rasgele ve sıralı disk IO'yu ayırmanın avantajını beklemek, tipik olarak veri depolama için HDD aygıtlarını varsayar. Ayrıca, ayrı Windows fiziksel disklerinin ayrı HDD aygıtları anlamına geldiğini varsayar. Buradaki fikir, bazı HDD'lerin temel olarak sıralı disk IO'larını işlemesi ve ayrı bir HDD seti rasgele disk IO'yu işlerken çok sınırlı disk kafası hareketine (örneğin, tek bir meşgul txlog * barındıran HDD'lere) sahip olmasıdır.
Bu varsayımlar bugün nadiren geçerlidir - özellikle de bir sanal makinede. Her şeyden önce, VM'ler Windows fiziksel diskleri RDM olmadığı sürece, bunların birden fazlası tek bir veri deposunda olabilir - veya tek bir ESXi ana bilgisayar LUN'unda birden fazla veri deposu olabilir. Böylece konukta ayrılan şey ESXi ana bilgisayar düzeyinde karıştırılabilir.
Ancak, RDM'lerin kullanıldığını veya her konuk fiziksel diskinin kendi veri deposunda, kendi ESXi LUN'da olduğunu varsayalım. O zaman bile, ESXi ana bilgisayarına sunulan LUN'lar aynı tek disk aygıt havuzundan olabileceğinden, konuktaki rasgele io'dan ayrı sıralar sık sık dizide karıştırılır. Hemen hemen her depolama dizisi bunu yapıyor - ya sadece ya da yönetimi kolaylaştırmak ve dizi verimliliğini / kaynak kullanımını artırmak için bir seçenek olarak.
Son olarak, bugün çok fazla depolama alanı ya flash ya da hibrid flash + HDD'dir. Endişelenecek bir kafa hareketi olmadan, flaş rasgele için sıralamanın ayrılmasını umursamaz ... IO dokumasını bile umursamıyor.
Yani… bunlar sıralı olanı rastgele ayırmanın tüm nedenleri o kadar faydalı olmayabilir. Daha sonra, dosyaları neden fiziksel disklere yaymak ve fiziksel diskleri vHBA'lara yaymak yine de performansı artırabilir.
* Bu HDD örneğinde tek bir işlem günlüğünden kasten bahsetmiştim. Aynı HDD'lerde birkaç ayrı sıralı disk IO akışı (örn. 8 meşgul işlem günlüğü) gerçekleştiğinde - bir şekilde aktivitenin neredeyse tamamı SAN önbelleği içinde değilse - sıralı IO izleri arasındaki sabit kafa hareketi IO dokumasına yol açar. Bu, "rasgele daha kötü" disk gecikmesine yol açan belirli bir tür disk kafası daralmasıdır. RAID5 ve RAID10'da olur, ancak RAID10 bu konuda önemli bozulmadan önce RAID5'ten biraz daha fazla varyasyonu tolere edebilir.
Şimdi - sıralı olanı rastgele ayırmanın nasıl yardımcı olabileceği konusunda uzun soluklu bir konuşma yapıldığında - dosyaları fiziksel disklere yaymak hala nasıl yardımcı olabilir? VHBA'lar arasında fiziksel disklerin yayılması nasıl yardımcı olabilir?
Her şey disk IO kuyruklarıyla ilgilidir.
Herhangi bir Windows fiziksel disk veya LogicalDisk, perfmon tarafından "Geçerli Disk Sırası" olarak bildirilen bir seferde 255 adede kadar olağanüstü disk IO'suna sahip olabilir. Fiziksel disk kuyruğundaki olağanüstü disk IO'larından, storport mini sürücüye 254'e kadar geçebilir. Ancak mini sürücünün hem bir hizmet kuyruğu (bir sonraki alt seviyeye geçmiştir) hem de bir bekleme kuyruğu olabilir. Ve storport'a geçtiği sayıyı 254'ten düşürmesi söylenebilir.
Bir VMware Windows misafirinde, pvscsi sürücüsünün varsayılan "aygıt" kuyruk derinliği 64'tür, burada aygıt fiziksel disktir. Dolayısıyla perfmon, tek bir fiziksel disk için "geçerli disk kuyruğu uzunluğunda" 255 adede kadar disk IO'yu gösterebilse de, bir seferde yalnızca 64 adede kadar sonraki seviyeye geçilir (varsayılanlar değiştirilmedikçe).
Kaç diski IO'ları üstün olabilir biriaynı anda meşgul işlem günlüğü? İşlem günlüğü yazmalarının boyutu en fazla 60 KB olabilir. Yüksek ölçekli bir ETL sırasında, txlog'a her yazıyı 60kb'de sık sık göreceğim. Txlog yazarı, bir seferde bir txlog'a kadar 32 yazmada 60kb'ye kadar yazılabilir. Peki aynı VMD ayarlarıyla aynı fiziksel diskte meşgul bir evre txlog ve meşgul bir dw txlog varsa? Eğer her iki txlog da 32 olağanüstü 60kb yazıyorsa, fiziksel disk 64 kuyruk kuyruğundadır. Şimdi… fiziksel diskte ETL kaynağı olarak düz dosyalar varsa? Düz dosyalara yapılan okumalar ve txlog yazarları arasında, bekleme kuyruğunu kullanmak zorunda kalacaklardı, çünkü bir seferde sadece 64 tane çıkabilir. Bunun gibi meşgul txlog'ları olan veritabanları için, ister fiziksel sunucu ister sanal olsun, txlog'u kendi fiziksel diskinde öneririm, fiziksel diskte başka hiçbir şey olmadan. Bu, bu düzeyde kuyruğa girmeyi önler ve aynı zamanda birden çok dosyanın araya eklenmesi (bu günlerde çok daha az endişe kaynağıdır) içeriğiyle ilgili endişeleri ortadan kaldırır.
Kaç disk GÇ'si bir satır dosyasına tek seferde olağanüstü olabilir (SQL Server'ın perspektifinden, daha düşük seviyelere gönderilmesi gerekmez)? SQL Server'ın kendisinde bir sınır yoktur (zaten bulduğum). Ama dosya varsayarak tek bir Windows FizikselDisk (ben başka bir zaman bir konu var SQL Server için çizgili dinamik diskleri kullanarak önermiyoruz) üzerine, orada olan bir sınır. Daha önce bahsettiğim 255.
SQL Server readahead ve asenkron IO büyüsü ile, her biri seri sürücüde 1200'ün üzerinde toplam "geçerli disk kuyruk uzunluğu" çalışan 4 eşzamanlı sorgu gördüm! 255 sınırı nedeniyle, tek bir fiziksel diskteki tüm satır dosyası içeriğinde bile bu mümkün değildir. Her biri kendi fiziksel diskinde 8 dosya içeren birincil dosya grubuna karşıydı.
Dolayısıyla okuma kafası okumaları çok agresif olabilir ve IO sıralarını vurgulayabilir. Öyle agresif olabilirler ki, diğer satır dosyası okuma ve yazma işlemleri de sonunda bekler. İşlem günlükleri satır dosyaları ile aynı fiziksel diskte ise, eşzamanlı okuma başlığı okumaları ve txlog yazma işlemleri sırasında gerçekleşmesini beklemek çok kolaydır. Bu bekleme "geçerli disk kuyruğu uzunluğu" düzeyinde olmasa bile, aygıt kuyruğunda bekliyor olabilir (varsayılan olarak pvscsi ile 64).
Satır dosyalarına karşı yedekleme okumaları, özellikle de yedekleme verimini en üst düzeye çıkarmak için buffercount ayarlanmışsa, agresif olabilir.
Txlog'ları yalıtırken dikkat edilmesi gereken bir SQL Server io türü daha var: tempdb için sorgu döküntüsü. Sorgu sızıntısı gerçekleştiğinde, her dökülme çalışması tempdb'ye yazar. Aynı anda dökülen çok sayıda paralel işçiniz var mı? Bu bir yazma yükü olabilir. Yoğun bir txlog ve önemli satır dosyalarını bundan uzak tutmak gerçekten yararlı olabilir :-)
Şimdi, pvscsi sürücüsü için varsayılan aygıt kuyruğu derinliğini değiştirmek mümkündür. Varsayılan olarak 64'tür ve en çok portun geçeceği 254'e kadar ayarlanabilir. Ancak bunu değiştirirken dikkatli olun. Her zaman konuk cihaz kuyruğu derinliğini alttaki ESXi ana bilgisayar LUN kuyruk derinliği ile hizalamanızı öneririm. Ve dizi en iyi uygulamaları başına ESXi ana bilgisayar LUN kuyruk derinliğini ayarlamak. EMC VNX mi kullanıyorsunuz? Ana bilgisayar LUN kuyruk derinliği 32 olmalıdır. Konuk RDM kullanıyor mu? Harika. Konuk pvscsi cihazı kuyruk derinliğini 32 olarak ayarlayın, böylece ESXi ana bilgisayar LUN kuyruk derinliği ile hizalanır. EMC VMAX? ESXi ana bilgisayar düzeyinde 64, konukta 64. Pure / Xtremio / IBM FlashSystem? Bazen ana bilgisayar LUN kuyruğu derinliği 256'ya kadar yükselir! Devam edin ve pvscsi cihaz kuyruğu derinliğini 254 (Maks. Mümkün) olarak ayarlayın.
İşte talimatları içeren bir bağlantı.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Bağlantı ayrıca requestringpages hakkında konuşuyor - WhatAreThose ?? Pvscsi bağdaştırıcısının kendisi için kuyruk derinliğini belirler. Her sayfa, adaptör kuyruğu derinliğinde 32 yuva verir. Varsayılan olarak 256 adaptör kuyruğu derinliği için requestringpages 8'dir. 1024 adaptör kuyruğu derinliği yuvaları için 32'ye kadar ayarlanabilir.
Diyelim ki her şey varsayılan. Onlarda rowfiles ile 8 fiziksel diskler var ve SQL Server biraz meşgul. 8'de ortalama 32 "geçerli disk kuyruğu uzunluğu" vardır ve hiçbiri 64'ten yüksek değildir (her şey çeşitli cihaz hizmeti kuyruklarına sığar). Harika - 256 OIO verir. Aygıt hizmeti kuyruklarına sığar, bağdaştırıcı hizmeti kuyruğuna sığar, böylece 256'nın tümü konuktan ESX ana bilgisayar düzeyindeki kuyruklara geçer.
Ancak… işler biraz daha yoğunlaşırsa, bazı fiziksel disklerin kuyruğu 128'e kadar yükselen ortalama 64'tür. 8 fiziksel diskte aygıtların hizmet kuyruğunda 256'dan fazla varsa, bağdaştırıcı hizmet kuyruğundaki yuvalar açılana kadar bekleme süresi içinde bekleme süresi vardır.
Bu durumda, başka bir pvscsi vHBA eklemek ve fiziksel diskleri aralarına yaymak toplam adaptör kuyruğu derinliğini 512'ye iki katına çıkarır. Aynı anda konuktan sunucuya daha fazla io geçirilebilir.
Benzer bir şey, bir pvscsi adaptöründe kalarak ve talep eden sayfaları arttırarak elde edilebilir. 16'ya gitmek 512 yuva ve 32'ye 1024 yuva verir.
Mümkün olduğunda, derine gitmeden önce genişlemenizi (adaptörler eklemenizi) (adaptör kuyruğu derinliğini artırmanızı) öneririm. Ama ... en yoğun sistemlerin çoğunda, her ikisini de yapmak zorundasınız: konuğa 4 vHBA koyun ve talep sayfalarını 32'ye yükseltin.
Başka birçok husus da var. Vmdks kullanılıyorsa sioc ve adaptif kuyruk derinliği azaltma, çoklu yol yapılandırması, ESXi adaptörünün LUN kuyruk derinliğinin ötesinde yapılandırılması vb.
Ama hoşgeldin fazla kalmak istemiyorum :-)
Lonny Niederstadt (@sqL_handLe) Instagram Profilini Görüntüle