Bir VMware sanal makinede çalışan tek bir SQL Server 2016 SP1 örneğimiz var. Her biri farklı bir uygulama için 4 veritabanı içerir. Bu uygulamaların hepsi ayrı sanal sunucularda. Bunların hiçbiri henüz üretimde değil. Ancak uygulamaları test eden kişiler performans sorunlarını bildiriyor.
Bunlar sunucunun istatistikleri:
- 128 GB RAM (SQL Server için 110GB Maks bellek)
- 4 Çekirdek @ 4.6 GHz
- 10 GBit ağ bağlantısı
- Tüm depolama alanı SSD tabanlıdır
- Program dosyaları, Günlük dosyaları, veritabanı dosyaları ve tempdb, sunucunun ayrı bölümlerinde bulunur
- asd
Kullanıcılar C ++ tabanlı bir ERP uygulaması üzerinden tek ekran erişimi gerçekleştiriyor.
SQL Server'ı Microsoft'un ostressbirçok küçük sorguyu veya büyük bir sorguyu kullanarak test ettiğimde, maksimum performans elde ederim. Kısıtlayan tek şey müşteri, çünkü yeterince hızlı cevap veremiyor.
Ancak neredeyse hiç kullanıcı olmadığında, SQL Server neredeyse hiçbir şey yapmaz. Ancak insanlar sadece uygulamada bir şey kaydetmek için sonsuza kadar beklemek zorunda.
Paul Randal'ın " Bana nerede acı verdiğini söyle " sorgusuna göre, tüm bekleme olaylarının% 50'si ASYNC_NETWORK_IO.
Bu, bir ağ sorunu veya uygulama sunucusu veya istemcisinde performans sorunu anlamına gelebilir. Bunların hiçbiri kaynaklarını maksimum kapasitede kullanmıyor. Çoğu zaman CPU tüm makinelerde% 26 civarındadır (İstemci, uygulama sunucusu, db sunucusu).
Ağ bağlantısının gecikmesi 1-3ms civarındadır. Uygulama ile normal kullanım sırasında db sunucusunun GÇ maksimum 20MB / s yazma hızındadır (ort. 7-9MB / s). Stres testi yaptığımda maksimum 5GB / s alırım.
Arabellek önbellek boyutu ERP sistemimizin DB'si için 60GB, finansman yazılımımız için 20GB, kalite güvence yazılımı için 1GB, belge arşivleme sistemi için 3GB'dir.
SQL Server hesabına Anında Dosya Başlatma özelliğini kullanma hakkı verdim . Bu, performansı en ufak bir şekilde artırmadı.
Normal kullanım sırasında sayfa ömrü yaklaşık 15k + 'dır. Beklenecek olan ağır stres testinin sonunda .05k civarında düşer. Parti / sn, iş yüküne bağlı olarak 2-8k civarındadır.
ERP uygulamasının sadece kötü yazılmış olduğunu söyleyebilirim, ancak yapamıyorum çünkü tüm uygulamalar etkilendi. Minimum iş yükünde bile.
Ancak buna neyin sebep olduğunu tam olarak anlayamıyorum. Herhangi bir ipucu, ipucu öğretici, uygulama, en iyi / en kötü uygulama belgeleri veya bu sorunla ilgili aklınıza gelen başka bir şey var mı?
Bunlar sp_BlitzFirst:
600 saniye çalıştırdım. Uygulamanın yüksek bir iş yükü sırasında başlattım. Zamanın 1 / 3'ü ASYNC_NETWORK_IO. Ben de birlikte ağ bağlantısını test NTttcp, PsPing, ipferf3, ve pathping. Alışılmadık bir şey yok. Tepki süreleri en fazla 3ms, ortalama 0.3ms'dir. Verim yaklaşık 1000 MB / s'dir.
Araştırmam her zaman bir ASYNC_NETWORK_IOnumaralı waitstat oldu.
VMware'deki Large-Receive-Offloadözelliği devre dışı bırakmanın sonucunu araştırdık . Hala test ediyoruz, ancak sonuçlar tutarsız görünüyor. İlk 'karşılaştırmalı değerlendirmemiz' 19 dakika sürdü (en iyi sonuç 13 dakikadır, bu da yalnızca uygulama VM'de SQL uygulamasıyla çalıştığında elde edilir). İkinci sonuç 28 dakika, bu gerçekten kötü.
'Benchmark'ımızın ilk sonucu 19 dakikadır. Hangisi iyi. En iyi sonuç 13 dakika olduğu için (bu yalnızca uygulama VM'de SQL Server'ın kendisi ile kıyaslandığında elde edilebilir). Bu, ağla ilgili bazı sorunlara şiddetle işaret eder. Veya VMware yapılandırmasıyla ilgili bir sorun.
Şu anda hangi darboğazda çivilemek için hangi yöntemleri kullanacağım kayboluyorum.
Uygulama ile maksimum performans ancak uygulama VM üzerinde SQL Server ile çalıştığında elde edilebilir. Uygulama başka bir VM veya sanal masaüstünde yürütülürse, karşılaştırmalı değerlendirmemizin süresi üç katına çıkar (13 dakikadan 40 dakikaya veya daha fazla). Tüm uç noktalar (SQL Server'ın VM'si, uygulama sunucusunun VM'si ve Sanal Masaüstü) aynı fiziksel donanımı kullanıyor. Diğer tüm uç noktaları başka bir donanıma taşıdık.
EDIT: Sorun geri döndü gibi görünüyor. Enerji tasarruf modunu dengeliden yüksek performansa ayarladıktan sonra, aslında tepki sürelerini önemli ölçüde geliştirdik. Ama bugün sp_BlitzFirst'i 300 saniyelik bir örnekle tekrar çalıştırdım. Sonuç budur:
ASYNC_NETWORK_IO için sp_blitzfirst'in kaç saniye sürdüğünden daha fazla bekleme süresi gösterir.