SQL Server, 15 saniyeden uzun süren G / Ç isteklerinin oluşmasıyla karşılaştı

Üretim SQL Server'da aşağıdaki yapılandırmaya sahibiz:

Kullanılabilirlik Grubu olarak birleştirilmiş 3 Dell PowerEdge R630 sunucusu Tüm 3, RAID dizisi olan tek Dell SAN depolama birimine bağlanır

Zaman zaman PRIMARY'de aşağıdakine benzer mesajlar görüyoruz:

SQL Server, veritabanı tanıtıcısı 8'de [F: \ Data \ MyDatabase.mdf] dosyasında tamamlanması 15 saniyeden uzun süren G / Ç isteklerinin 11 yinelemesiyle karşılaştı
. OS dosya tanıtıcısı 0x0000000000001FBC'dir.
En son uzun G / Ç'nin ofseti: 0x000004295d0000.
Uzun I / O süresi: 37397 ms.

Performans sorunlarını giderme konusunda acemiyiz

Depolama ile ilgili bu sorunu gidermek için en yaygın yollar veya en iyi uygulamalar nelerdir? Bu tür mesajların temel nedenini daraltmak için hangi performans sayaçları, araçlar, monitörler, uygulamalar vb. Kullanılmalıdır? Yardımcı olabilecek Genişletilmiş Olaylar veya bir çeşit denetim / kayıt olabilir mi?

Benzer bir kurulumumuz var ve günlüklerde bu mesajlarla karşılaştık. DELL Compellent SAN kullanıyoruz. Çözüm bulmamıza yardımcı olan bu mesajları alırken kontrol etmeniz gereken bazı noktalar

• Uyarı mesajlarının işaret ettiği diskleriniz için Windows performans sayaçlarınızı inceleyin, özellikle:
  • Disk ort. okuma zamanı
  • Disk ort. yazma zamanı
  • Disk okuma bayt / sn
  • Disk yazma bayt / sn
  • Disk Aktarımı / sn
  • Ort. disk kuyruğu uzunluğu
• Yukarıdaki ortalamalar. Bir sürücüde çok sayıda veritabanı dosyanız varsa, bu ortalamalar sonucu çarptırabilir ve belirli veritabanı dosyalarında bir şişe boynunu maskeleyebilir. Her sorgu için dmv'den ortalama gecikme süresi döndüren Paul S. Randal'dan bu sorguyu inceleyin sys.dm_io_virtual_file_stats. Olgumuzda bildirilen ortalama gecikme süresi kabul edilebilirdi, ancak kapakların altında> 200 ms'lik ortalama gecikme süresine sahip birçok dosya vardı.
• Zamanlamaları kontrol edin. Herhangi bir desen var mı? Geceleri belirli bir zamanda daha sık oluyor mu? Öyleyse, o sırada herhangi bir bakım işinin çalışıp çalışmadığını veya disk etkinliğini artırabilecek ve IO alt sisteminizde bir şişe boynunu açığa çıkarabilecek herhangi bir planlanmış etkinlik olup olmadığını kontrol edin.
• Windows olay görüntüleyicisinde hata olup olmadığını kontrol edin. Anahtarınız veya SAN'ınız aşırı yükleniyorsa veya uygulamanız için düzgün ayarlanmamışsa, bu günlükte bazı iletiler bulabilirsiniz ve bu bilgileri SAN yöneticinize götürmek iyidir. Bizim durumumuzda, gün boyunca sık sık iSCSI bağlantı hataları alıyorduk.
• SQL Server kodunuzu gözden geçirin. Bu iletileri aldığınızda, bunun bir GÇ alt sistemi sorunu olduğunu hemen düşünmemeli ve SAN yöneticinize iletmemelisiniz. Kendi payına düşeni yapmanız ve veritabanını gözden geçirmeniz gerekiyor. Tonlarca veriyi çalkalayarak sık sık sorulan sorularınız mı var? Kötü endeksleme? Aşırı işlem günlüğü yazıyor mu? Veritabanınızda bir sağlık kontrolü almak için bazı açık kaynak sorguları kullanabilirsiniz; sorgu planınızın nasıl göründüğünü kontrol etmek için bir örnek sp_blitzCache
• Bunları görmezden gelme. Bugün onları günde birkaç kez alıyor olabilirsiniz ... o zaman birkaç ay sonra iş yükünüz arttığında ve bunları izlemeyi unuttuğunuzda artmaya başlarlar. Bu iletilerin çoğunun alınması SQL Server'ın belirli bir dosyaya erişmesini engelleyebilir ve tempdb ise bu iyi değildir. Bizim durumumuzda SQL Server'ın kendini kapatması o kadar kötüydü.

Çözümümüz anahtarımızı SAN anahtarına yükseltmekti. Evet, bunların tümü SQL Server içinde ele alınacak noktalardır. Bizi değiştirmeye götüren şey, her gün SQL Server'daki Windows uygulama olay görüntüleyicisinde yaklaşık 1500 iSCSI pdu bağlantı kesme hatası almamızdı. Bu, SAN yöneticilerimizin soruşturmaya geçmesini sağladı.

Yükseltmeden hemen sonra, iSCSI hataları giderildi ve tüm dosyalar için ortalama gecikme süresi yaklaşık 50 ms'ye düştü ve bu, uygulamada daha iyi performansla ilişkilendirildi. Bu noktaları akılda tutarak umarım çözümünüzü bulabilirsiniz.

Bu çok daha az sıklıkla bir disk sorunu ve daha sıklıkla bir ağ sorunudur. SAN'daki N?

SAN ekibinize gidip disklerin yavaş olduğundan bahsedmeye başlarsanız, üzerinde 0 milisaniye gecikme süresi olan süslü bir grafik gösterecek ve size bir zımba işaret edecektir.

Bunun yerine, onlara SAN'a giden ağ yolunu sorun. Çok yollu vb. Hızları alın. Görmeniz gereken hızlar hakkında onlardan sayı alın. Sunucuların kurulduğu andan itibaren karşılaştırmalı değerlendirme olup olmadıklarını sorun.

Sonra bu hızları doğrulamak için Crystal Disk Mark veya diskpd kullanabilirsiniz. Tekrar sıralanmazlarsa, büyük olasılıkla ağ bağlantısıdır.

Ayrıca hata günlüğünüzde "FlushCache" ve "doygunluk" içeren iletileri de aramalısınız, çünkü bunlar aynı zamanda ağ çekişmesi işaretleri de olabilir.

Bir DBA olarak bunlardan kaçınmak için yapabileceğiniz bir şey, bakımınızın ve diğer veri yoğun görevlerin (ETL gibi) aynı anda devam etmediğinden emin olmaktır. Bu kesinlikle depolama ağları üzerinde büyük baskı yaratabilir.

Daha fazla öneri için buradaki yanıtları da kontrol etmek isteyebilirsiniz: Yavaş kontrol noktası ve flash depolamada 15 saniye I / O uyarıları

Burada benzer bir konu hakkında blog yazdım: Sunucudan SAN'a

Veriler neden bir SAN'da depolanıyor? Amaç ne? Tüm veritabanı performansı Disk G / Ç'ye bağlıdır ve arkalarındaki G / Ç için yalnızca tek bir aygıtla 3 sunucu kullanıyorsunuz. Bu hiç mantıklı değil ... ve ne yazık ki çok yaygın.

Hayatımı, insanların büyük ölçekli bir bilgisayar tasarlamaya çalıştıkları kötü tasarlanmış donanım platformlarıyla karşılaşarak geçiriyorum. Buradaki tüm CPU gücü, oradaki tüm diskler ... umarım uzak RAM diye bir şey yoktur. Ve en üzücü olanı, bu tasarımın verimlilik eksikliğini, ondan daha fazla zamana mal olan büyük sunucularla telafi ediyorlar. 400 bin dolarlık bir laptoptan daha yavaş gördüm.

Bir SQL sunucu yazılımı çok gelişmiş bir yazılım parçasıdır, herhangi bir donanım, CPU çekirdeği, CPU önbelleği, TLB, RAM, disk denetleyicileri, sabit disk önbelleğinden yararlanmak için tasarlanmıştır ... Neredeyse tüm dosya sistemi mantığını içerirler. Normal bilgisayarlarda geliştirilir ve ileri teknoloji sistemlerde kıyaslanır. Bundan sonra bir SQL sunucusunun kendi diskleri olmalıdır. Bunları SAN'a kurmak, bir bilgisayarı "taklit etmek" gibidir, tüm performans optimizasyonlarını kaybedersiniz. SAN'lar yedekleri, değiştirilemez dosyaları ve sadece veri eklediğiniz dosyaları (günlükler) saklamak içindir.

Veri merkezi yöneticileri SAN'lara ellerinden gelen her şeyi koyma eğilimindedir çünkü bu şekilde yönetilecek tek bir depolama havuzuna sahiptirler, her sunucuda depolama alanına bakmaktan daha kolaydır. Bu bir "işimi yapmak istemiyorum" ve çok kötü bir seçim, çünkü o zaman performans sorunları ile uğraşmak zorundalar ve tüm şirket bundan muzdarip. Yazılımı, tasarlandığı donanıma kurmanız yeterlidir. Basit tutun. G / Ç bant genişliği, önbellek ve içerik geçişi ek yükü, kaynak kaynağı titreşimi (kaynak paylaşıldığında gerçekleşir) bakımı. Aynı ham çıkış gücü için cihazların 1 / 10'unu koruyacak, ops takımınızın baş ağrısını koruyacak, son kullanıcılarınızı mutlu ve daha üretken hale getiren performans kazanacak, şirketinizi çalışmak için daha iyi bir yer yapacak ve çok enerji tasarrufu yapın (gezegen size teşekkür edecektir).

Yorumlarda, SSD'yi sunucunuza koymayı düşünüyorsunuz. Özel SSD'lerle kurulumunuzu tanımayacaksınız, bir SAN ile karşılaştırıldığında aynı sürücüdeki veri ve işlem günlüğü dosyalarıyla bile 500x iyileştirme gibi bir şey elde edeceksiniz. Modern bir SQL Server, farklı donanım denetleyici kanallarındaki veri ve işlem günlüğü için hızlı ayrı SSD'ye sahip olacaktır (çoğu sunucu anakartında birkaç tane vardır). Ancak şu anki kurulumunuzla karşılaştırıldığında, burada bilimkurgudan bahsediyoruz. Sadece SSD'yi deneyin.

Tamam, ilgilenen herkes için,

Birkaç ay önce sorudaki sorunu, yalnızca 3 sunucunun her birine doğrudan bağlı SSD sürücülerini takarak ve DB verilerini ve günlük dosyalarını SAN'dan bu SSD sürücülerine taşıyarak çözdük

SSD diskleri kurmaya karar vermeden önce, bu konuda araştırma yapmak için ne yaptığımın özeti (bu sorudaki tüm gönderilerin önerilerini kullanarak):

1) 3 sunucunun tümünde aşağıdaki sürücüler için PerfMon sayaçları toplamaya başladı:

Disk F:SAN tabanlı mantıksal disktir, MDF veri dosyaları
Disk I:içerir SAN tabanlı mantıksal disktir, LDF günlük dosyaları içerir
Disk T:doğrudan SSD, sadece tempDB adanmıştır

Aşağıdaki resim 2 haftalık dönem için toplanan ortalama değerlerdir

Disk I: (LDF)yok sayılabilir: Böyle bir disk Öyle IO ve Gecikme, çok düşük olduğu küçük sahiptir
Bunu görebilirsiniz Disk T: (TempDB)IO kıyasla daha büyük sahiptir Disk F: (MDF)0 ms - ve aynı zamanda çok daha iyi Gecikme vardır

Açıkçası Disk F ile ilgili bir sorun var: veri dosyalarının bulunduğu yerde, düşük IO'ya rağmen yüksek Gecikme ve Ort. Disk Yazma Sırası var

2) Bu web sitesinden gelen sorgu kullanılarak ayrı veritabanları için Gecikme Kontrolü

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Birincil sunucudaki çok az etkin veritabanının 150-250 ms okuma gecikmesi ve 150-450 ms yazma gecikmesi
vardı İlginç olan, ana ve msdb veritabanı dosyalarının 90 ms'ye kadar okuma gecikmesi vardı, bu da verilerin küçük boyutu ve düşük IO'su nedeniyle şüphelidir. başka bir gösterge SAN ile ilgili bir sorun var

3) Belirli bir zamanlama yoktu

Hangi sırasında "SQL Server karşılaştı oluşumları ..." mesajları geldi
bu iletiler günlüğe zaman çalışan hiçbir bakım veya disk ağır ETL vardı

4) Windows Olay Görüntüleyicisi

"SQL Server olaylarla karşılaştı ..." dışında, sorunu ipucu verecek başka herhangi bir girdi gösterilmedi.

5) En iyi 10 sorguyu kontrol etmeye başladı

Sp_BlitzCache (cpu, okur, vb) ve olası omptimizing itibaren
rağmen hiçbir süper IO ağır sorgular, ağır veri ton ve etkileyen depolama yayık olur
veritabanlarında İndeksleme Tamam, bunu korumak

6) SAN ekibimiz yok

SAN'a karşı ağ yoluna yardımcı olan sadece 1 sistemadımız var - çok yollu, 3 sunucunun her birinin anahtarlara ve sonra SAN'a giden 2 ağ kablosu var ve 1 Gigabyte / sn olması gerekiyordu.

7) CrystalDiskMark sonucu yoktu

Ya da sunucuların kurulduğu andan itibaren başka bir kıyaslama testi sonuçları, bu yüzden hızların ne olması gerektiğini bilmiyorum ve şu anda Hızların ne olduğunu görmek için bu noktada kıyaslama yapmak mümkün değil, Üretimi etkiledi

8) Söz konusu veritabanı için kontrol noktası olayında Genişletilmiş Olaylar oturumu kurun

XE oturumu, "SQL Server olaylarla karşılaştı ..." iletileri sırasında denetim noktasının gerçekten yavaş olduğunu (90 saniyeye kadar) keşfetmeye yardımcı oldu

9) SQL Server Hata Günlüğü

İçerilen "FlushCache" "Doygunluk" girdileri
Belirli bir veritabanı için denetim noktası süresi kurtarma aralığı ayarlarını aştığında gösterilmesi gerekir

Ayrıntılar, kontrol noktasının temizlemeye çalıştığı veri miktarının küçük olduğunu ve tamamlanmasının uzun sürdüğünü ve toplam hızın yaklaşık 0,25 MB / sn olduğunu gösterdi ... garip

10) Son olarak, bu resim depolama sorun giderme tablosunu gösterir:

Görünüşe göre "Donanım Sorunu: - SAN, eski / hatalı sürücüler, kontrolörler, bellenim, vb. Gibi herhangi bir yanlış yapılandırmayı düzeltmek için sistem yöneticisi / donanım satıcısıyla birlikte çalışın

Başka bir soruda "Yavaş kontrol noktası ..." Yavaş kontrol noktası ve flash depolamada 15 saniyelik G / Ç uyarıları Sean, sorun gidermek için hangi öğelerin donanım ve yazılım düzeyinde kontrol edilmesi gerektiğine dair çok güzel bir listeye sahipti

Sistem yöneticimiz listeden her şeyi kontrol edemedi, bu yüzden bu konuda bazı donanımları atmayı seçiyoruz - hiç de pahalı değildi

Çözüm:

1 TB SSD sürücü sipariş ettik ve doğrudan sunuculara kurduk

Kullanılabilirlik Gruplarımız olduğu için, ikincil kopyalarda DB veri dosyalarını SAN'dan SSD'ye geçirdiğimizden, başarısız oldum ve eski birincil dosyada taşındı Bu, minimum toplam kesinti süresine izin verdi - 1 dakikadan az

Artık her sunucunun DB verilerinin yerel kopyası var ve belirtilen SAN'a tam / diff / log yedeklemeleri yapılıyor
Windows Olay Görüntüleyicisi günlüklerinde artık "SQL Server olaylarla karşılaştı ..." iletileri ve yedeklemelerin performansı, bütünlük denetimleri, endeks yeniden oluşturma, sorgu vb. önemli ölçüde arttı

DB dosyalarını SSD'ye taşıdığımız için GÇ gecikmesi açısından ne kadar performans gelişti?

Etkiyi değerlendirmek için kullanılan performans Windows Performans İzleyicisi geçişten 2 hafta önce ve geçişten 4 hafta sonra günlüğe kaydeder:

Ayrıca aşağıda DB düzeyinde gecikme istatistikleri karşılaştırması (taşıma işleminden önce ve sonra SQL Server'ın yakalanan sanal dosya istatistikleri kullanılır)

özet

SAN'dan doğrudan bağlı yerel SSD'lere geçiş buna değdi
Bu, depolama gecikmesini büyük ölçüde etkiledi ve ortalama olarak% 90'ın üzerinde (özellikle WRITE operasyonları) iyileşti ve artık IO'da 20-50 sn ani artışlarımız yok

Yerel SSD'ye geçmek yalnızca depolama performansı sorunlarını değil, aynı zamanda endişe duyduğum veri güvenliğini de çözdü (SAN başarısız olursa, 3 sunucunun tümü aynı anda verilerini kaybeder)