|
SQLSERVER Kullanıcı Bağlantıları Performans sayacındaki SQL örneğinin Genel İstatistikleriKullanıcı Bağlantıları buna karşılık gelir Performans sayacında TCPv4Connections Kuruldu'na da bakabilirsiniz
Sadece SQLSERVER servisi olan bir makinede,TCPV4 Bağlantıları Kuruldu && Mssql UserConnectionsBu iki parametre temelde senkronize olup, aşağıdaki test içeriğinde bağlantı sayısı olarak adlandırılır
Bu bağlantı sayısı sınırlıdır ve maksimum eşzamanlı sınırlara benzer şekilde. Bu sınıra ulaşıldığında, boş CPU, IO ve MEM kaynakları olsa bile sorguların yanıt vermemesine neden olur (bazıları, ama tüm sorgular etkilenmez)
TCPV4 Bağlantıları Kuruldu && Mssql UserConnections'ın maksimum değeri aşağıdaki faktörlere bağlıdır
a. Yürütme ifadesinin karmaşıklığı ilişkilidir, ifade ne kadar karmaşıksa, maksimum bağlantı sayısı o kadar az olur (bu etki çok önemlidir)
b. Talebin iş parçacığına eşdeğer eşzamanlılığı ile ilgilidir,
10 işlem, her süreç 5.000 iş başlığı açıp talep ediyor,GETDATE() SEÇİN()Yaklaşık 4000'e ulaştığında ifade zaten terk edilmiş (anladığım kadarıyla birçok iş başlığı kaynak talep etmemiş olsa da, istek sayısı çok fazla, bu da bir etkisi var).
10 işlem, her süreç 1000 iş parçacığını talep etmek için açar, GETDATE() SEÇİN()Açıklamalar 10.000'den fazla kişiye ulaşabilir.
c. İş parçacığı taleplerinin sıklığıyla ilgilidir
Her iş parçacağı bir sorgu çalıştırıp 0-10.000 milisaniye duraklarsa, askıya alınmadığından daha az bağlantı kaplar
d. Testte, bazı kapatılmamış bağlantıların sayaçın şişmesine yol açacağı da bulundu, ancak bu tartışılmadı
10 süreç, her süreç 1000 istek iş parçacığını açar, sunucudaki her sorgudan sonra rastgele duraklar. Test sonuçları aşağıdaki gibidir:
Uygulama:[SISTEM]'DEN * SEÇ. [dbo]. [DBA_alert](bu sorgu 200 satır döndürür ve maksimum bağlantı sayısı 700'dür ve sorun ortaya çıkmaya başlar)
Bağlantı sayısı 700'e ulaştığında bazı hatalar bildirilmeye başlar ve 1200'de çok sayıda hata ortaya çıkmaya başlar; 1800 civarındaki bağlantı sayısı takılı kalır ve artmaz. Hatalar ve yavaş bağlantılar bolca
Uygulama:GETDATE() SEÇİN()Ceza süresi(Maksimum bağlantı sayısı 3500 ve sorun başlıyor)
Bağlantı sayısı 3500'e ulaştığında, bazıları hata raporlamaya başlar ve en yüksek basınç yaklaşık 11000'e ulaşır, bağlantı sayısı hâlâ yavaş artmaktadır. Hatalar ve yavaş bağlantı kopmaları
Sonuç şudur: verilen basınç koşullarında: en basit uygulananMaksimum bağlantı sayısı SELECT getdate() ve SELECT * FROM [sistem] çalıştırıldığında 3500'e kadar olabilir. [dbo]. [DBA_alert] ifadesi, maksimum bağlantı sayısı yalnızca 700'e kadar olabilir. Sorgu zamanlaması, CPU, IO ve MEM'in çok sayıda boşta kaynağı olduğunda gerçekleşir.
Üretim ortamında 10*1000 iş parçacığı baskısı ulaşılamıyor, ancak SQL test ortamından daha karmaşık olacaktır.
Eşzamanlı sayıDar boğaz, bilgisayarımın veya sunucumun ağ kartının bant genişliğinden kaynaklanmıyor
Yukarıdakileri kanıtlamak için. Aşağıdaki testleri yaptım, büyük eşzamanlılık durumunda exec dbo.run2;
ALTER proc [dbo]. [run2]
olarak
Nocount'u üzerinde kur
getdate() seç
@i int ilan etmek
@i=0 kümesi
@i<1000 Bu değer 1000 olduğunda maksimum bağlantı sayısı yaklaşık 1300'dür ve bu değer 10 olduğunda 5000'e ulaşmak normaldir.
Başlamak
[PUBS]'a INSERT EDIN. [dbo]. [tb_test] ([name]) değerleri (newid())
set @i=@i+1
Son
Git
Değişim döngülerinin sayısı dönüş sonucunu etkilemez; yani ağ kartı trafiği üzerindeki baskı aynıdır, ancak biri hızlı zaman döner, diğeri ise her zaman kontrol edilebilir, böylece ağ kartlarının bant genişliğinin her iki taraftaki etkisi ortadan kaldırılabilir.
Bağlantı sayısının maksimum kısmı durduğunda hata içeriği:
Netstat-Maksimum bağlantı sayısı takılı kaldığında (yoğun şekilde belirlenmiş) bir sonuç:
Maksimum bağlantı sayısı durduğunda çalıştıran programı test diyagramı:
Belirtmekte fayda var:Hatalar veya zaman aşımlarıyla bağlantı eşit değildir ve bazı süreçlerde yoğunlaşır; yani bazı süreçler her zaman normal çalışabilir, diğer kısım ise uzun süre hata rapor eder (bu süreçlerin başlangıç sırasıyla ilgili değildir, anladığım kadarıyla bazı süreçler kaynaklara sahiptir, normal çalışmaya devam edebilir, oysa orijinal kaynaklardaki iş parçacıklarındaki diğer süreçler önceden durdurulur ve yeni kaynaklar için başvuru yapamaz, hata rapor etmeye devam eder). Yukarıdaki şekilde gösterildiği gibi, 2. ve 7. süreçlerde çok sayıda zaman aşımı yaşamaya başladı ve diğer süreçler çalışmaya devam etti. Sunucuda, sorgular bazı makinelerden etkilenmemiş veya daha az etkilenmiş gibi görünebilir ve bazı makineler önemli ölçüde etkilenir.
Sonuç: SQLSERVER Kullanıcı Bağlantılarının üst sınırı bir dizi koşulla ilişkili olsa da, darboğazı tahmin etmek ve tahmin etmek hâlâ mümkündür; bu üst sınıra ulaşıldığında, çok sayıda sorgu yavaşlaması ve zaman aşımı yaşanacaktır (ancak CPU, IO. MEM, trafik de boşta kaynaklar olduğunda gerçekleşebilir). Aslında, bazı TCP parametrelerini değiştirmek bu üst sınırı artıracak ve belki daha sonra takviyeler yazabilirim
|
Yayınlandı 26.11.2014 15:11:08
|
|
|
|
