Soru 4 disk RAID 10'dan 6 disk RAID 10'a gittiğimde performansım neden artmadı?


Bir RAID10 ve 4 yedek diskte 4 sürücü vardı. Transfer (okuma ve yazma) sayacı başına perfmon Ortalama Disk saniyesini izliyoruz. 2 tane daha disk aldık, RAID10 setini 6 disk (2 span) kullanarak yeniden oluşturduk ve performans aynı kaldı. RAID10'un sadece 4 disk katına (4, 8, 12, vs) dayanarak geliştirdiği bazı sınırlamalar var mı?

Dell R510 kullanıyorum. Bu bir SQL sunucusudur. Aynı dosyaları ses seviyesinde sakladık.


Dell Perc H700 1GB uçucu olmayan önbellek kullanıyorum.

AD'ler / T yaklaşık 200ms'dir.

Bunlar 15K sas 600GB sürücüler

Dell PERC denetleyicinin kapsamı nasıl değiştirdiğini bilmiyorum. Sadece yayılma alanında kaç disk istediğimi soruyor (bu durumda 2 veya 3).

Milleri eklememizin nedeni, işlem başına toplam süreyi arttırmaktı. RAID1'den RAID10'a (4 disk) gittik ve performans ikiye katlandı. % 33'lük bir artış umuyorduk. AD / T maksimum 20ms önerilir. 100 yaşındayız. 2 disk ekleyerek 20'ye çıkamayacağımızın farkındayız, ama burada olduğumdan beri 400msdeydiler, 50'lerde 60'lar için iyi olacaklardı.

saniyede transferler yaklaşık 850


Belli bir diske karşı tek bir aktarımı hızlandırmak için disk ekleme mantığını anlıyorum. Ancak tüm amaçlar ve amaçlar için, ADs / T (veya okuma veya yazma), pencerelere göre belirli bir diske / cisme karşı bir şeyler yapmak için gereken sürenin bir ölçüsüdür. Yani, bir bütün işlem 40 milisaniye sürüyorsa, ancak gerçekte 4 diske yazıyorsa, paralel yapıldığında disk başına teorik olarak 10 ms harcıyor. Her zaman bir diskte olabildiğince hızlı yazabilme şansı var ve bir sonraki aşamaya geçiyor, ama birileri bunun ne yaptığını nasıl anlatabilir?

Bu nedenle, 4 disk için gereken süre 6 disk ile orantılı olmalıdır. Bir disk maksimum potansiyele ulaşmış olsa bile, pencereler daha hızlı görünmelidir, her disk daha hızlı olmayacaktır.

ssd, dizinlerimizin büyüklüğü, tüm sql dosyalarımız için ihtiyaç duyduğumuz toplam alan ve maliyet nedeniyle bizim için bir seçenek değildir. Daha küçük boyutlu dosyalar için SSD boyutları henüz mevcut değil, ancak mantıklı olabilir.

disk ekleme, hızın artmasına yardımcı olmazsa, 2'den 4'e kadar olan disklerde% 50'lik performans artışını nasıl açıklar, sonra da 4'ten 6'ya giderken hiçbir şey olmaz mı?


5
2018-04-18 19:08


Menşei


Lütfen aşağıdakileri cevaplayarak size yardım etmemize yardımcı olun: 1. Hangi denetleyiciyi kullanıyorsunuz? 2. "2 span" derken, RAID 0 + 1 (iki çizginin aynası) yerine RAID 1 + 0 (üç ayna boyunca bir şerit) kullandığınızı mı söylüyorsunuz? 3. Saniyede kaç okuma / yazma işlemi yapıyorsunuz? 4. "Transfer başına ortalama disk saniyesi" sayacının sabit kaldığını belirttiniz; değer neydi? 5. Spindle ekleme yolunda sizi yönlendiren belirli bir performans sorunu veya belirti var mıydı? Eğer öyleyse, semptom neydi? - Skyhawk
@MrVault: disk kuyruğu uzunlukları şimdi nasıl görünüyor ve değişimden önceki neydi? - Bob Jarvis
Artık maalesef disk kuyruğu istatistiklerine de sahip değilim. Önbelleğe alma işleminin ne kadar uygulanabilir olduklarından emin değildim. ADQL'in insanların düşündüğü kadar güvenilir olmadığını söyleyen makaleleri okudum. Sunucudaki diskleri maksimize ettik, böylece mümkün olduğunca hızlı işlem yapıyorlar ve disk sıra uzunluğu yüksekse, verilen donanımla yapabileceğimiz fazla bir şey yok. İstatistiklerin nispeten aynı kalmasının nasıl mümkün olabileceğini anlamaya çalışıyordum.
Kısa cevap: Diskleriniz hala çok fazla istek nedeniyle sıraya giriyor. Daha fazla RAM ekle. SQLServer, gerekli tüm okuma / yazma sayısını azaltmak için RAM'deki disk erişimini akıllıca önbelleğe alma konusunda oldukça iyidir. - Hyppy


Cevaplar:


SQL performans istatistiklerini ve ayrıca sürücü istatistiklerini daha ayrıntılı bir şekilde incelemelisiniz. Çok fazla bağlantınız varsa, daha küçük TempDB dosyalarının yapılmasına yardımcı olabilir. (bunu okuyunca, bizim için büyük bir kazanç oldu. http://msdn.microsoft.com/en-us/library/ms175527.aspx) 93’in altında bir tampon önbellek oranına sahipseniz, daha fazla bellek isteyebilirsiniz. Bir istatistik sorunu teşhis etmek için yeterli değildir. Çöp depolamanın birden fazla yolu var.

Kutu 2008 ise, hangi DB dosyalarının en yoğun olduğunu belirlemek için Kaynak İzleyicisi'ni kullanın. Farklı iğler üzerinde onları almak en iyi performans düzeltmesidir. Özellikle, okur ve okumak yerine çoğunlukla okur ve yazıyorsanız, ikinci bir sürücü denetleyicisi, birkaç adet daha küçük 15k'lık harici sürücü ve LOG ve TempDB dosyalarınızdaki veriler ile ayarlanan sürücüden uzaklaşmanız gerekir.


1
2018-06-24 18:31





Veri yolunuzla sınırlı kalabilirsiniz, aynı zamanda verimi artırmak için çok şeritli bir kabloya da bakın.


0
2018-04-18 19:49





Verileri işleyebilmek için veri yolu ile hatta duvara veya hatta işlemciye çarpıyor olabilirsiniz. Bu gerçekten bir darboğazsa, başka bir makineye bakmayı, eklediğiniz 2 diski çekip diğer makinede bir raid10'a eklemeyi isteyeceksiniz.

Bu noktada daha sonra performansı artırmak için makinelerde iki RAID arasında paralel bir dosya sistemi kuracaksınız (veri okuma ve yazma oranlarında büyük bir artış görmelisiniz).


0
2018-06-16 04:09





Yukarıdaki tüm yorumlar, "kirli küçük sır" yolda.

SQL Performans ipuçları için RE disk sistemi, bkz: https://serverfault.com/a/359689/13716


0
2018-02-13 18:46





RAID'nin kirli küçük sırrı:

Daha fazla disk eklemek, dar boğazınız çok fazla görev ve yeterli disk olmadığı için sıraya giriyorsa, yalnızca performansınızı artırır. Bireysel diskleri daha hızlı yapmaz ve aslında belirli bir miktarda yük ekler. Sonuçta, diskten veri okumak, daha önce olduğu gibi aynı şekilde çalışır ve hala yapılması gereken kadar uzun sürer. Aradaki fark, aynı anda birden fazla disk üzerinde yapabilmenizdir - bu yalnızca tüm diskleri meşgul tutarsanız yardımcı olur.

Daha yüksek hızlı bir diske geçmek (SSD'ler gibi) büyük olasılıkla biraz yardımcı olacaktır. Bir tek SSD, gecikme süresi ve zaman isteme sorunsa, winchester sürücülerle dolu bir kutuyu geride bırakabilir.

Gelişme aşamasında olan ancak zaten çok fazla söz verdiği ilginç bir çözüm Facebook'un flashcache modülü. Sadece Linux, ama yine de eğer bir sorun varsa, yine de pencereleri kullanmamalısınız. Percona'da Vadim Tkachenko'nun yaptığı bazı kriterler, flashcache'nin size ulaşabileceğini gösteriyor. performansın% 99'u SSD'de maliyetin sadece bir kısmı ile çalışmanın - isabet dağılımınızın tüm veri kümesinde eşit olarak yayılmayacağı varsayımı.


-1
2018-04-18 20:17



Bu "kirli küçük sır" olup olmadığını bilmiyorum, yulaflarına değer bir sysadmin için sağduyulu olmalıdır. - Chris S
-1: "ama yine de eğer bir sorun varsa, o zaman yine de pencereleri kullanmamalısınız." Ne saçma bir şey. - samsmith
Windows, bir yandan da açıkça işaretlenmiş bir Windows sorusuna linux tabanlı bir "çözüm" önererek, bir yandan da yararsızdır. İkinci paragrafından sonra durmalıydı. - rmalayter
Linux-vs-Windows sunucu performansı ölümüne dövüldü, bu yüzden tüm argümanları yeniden ele almayacağım. Ancak, buradaki en önemli nokta, kıyaslama Microsoft'ım tarafından finanse edilmediği sürece, en iyi şekilde yapılandırılmış Linux (ve diğer Unix türevleri), eşdeğer bir donanıma göre en iyi şekilde yapılandırılmış Windows Server'dan TPC ve SPEC kriterlerine göre yaklaşık 2 kat daha hızlı olma eğilimindedir. Buraya girmeyeceğim teknik nedenler var. Ancak Google’ın, Facebook’un, NASDA’nın ve diğer pek çok veri-ağır şirketin Linux’ta çalışmasının bir nedeni var. (Ve pazarlama nedeniyle değil) - tylerl
@rmalayter: Bu cevap gönderildiğinde, soru pencereler olarak işaretlenmedi. - tylerl