Uzun "istemci işlem süresi" nedeniyle yavaş uzaktan SELECT deyimi, ancak yerel olarak hızlı


12

Üretim sunucumuza (SQL Server 2008, çok güçlü bir makine) bağlıyken, bu SELECT ifadesi tüm alanlara (toplamda 4 MB veri) tükürerek 2 saniye sürer .

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Aynı ağdaki diğer herhangi bir kutudan (SQL kimlik doğrulaması veya Windows Kimlik Doğrulaması kullanarak bağlanma), aynı sorgu 1 dakika 8 saniye sürer .

Bir dizin oluşturma sorunu veya sorgu ile ilgili bir sorun olmadığını göstermek için bu çok basit bir ifade ile test ediyorum. (Şu anda tüm sorgularda performans sorunlarımız var ...)

Satırlar, bir kerede değil, parçalar halinde gelir. İlk satırlarımı hemen alıyorum ve sonra sıra gruplarının gelmesi için 1 dakikadan fazla bekliyorum.

Uzak kutudan çalıştırıldığında sorgunun İstemci İstatistikleri şunlardır:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

"Müşteri İşlem Süresinin" toplam yürütme süresine eşit olduğunu görebiliriz.

Gerçek verilerin aktarılmasının neden uzun sürdüğünü teşhis etmek için hangi adımları atabileceğimi bilen var mı?

Makineler arasındaki veri aktarım hızını sınırlayan veya sınırlayan bir SQL yapılandırma parametresi var mı?


Bu arada, DB sunucusu ile başka bir kutu arasında aynı boyutta (4 MB) dosyayı kopyalamayı denedik ve bu bir saniye sürdü. Yani bir ağ sorunu gibi görünmüyor.
FranticRock

İstemci uygulaması nedir? Son kullanıcı iş istasyonlarında SSMS?
Thomas Stringer

Evet Microsoft SQL Server Management Studio 10.50.1600.1. 2008 R2
FranticRock

Bu sorun, veri merkezlerini taşıdığımızdan ve tüm makine yeniden yüklendiğinden (SQL dahil her şey) başladı. Çok saygın bir hosting sağlayıcısı ile birlikteyiz.
FranticRock

Yanıtlar:


5

Sorununuz kesinlikle bilginize dayalı ağ ile ilgilidir. Bu nedenle, ağ profesyonelleri ile ilgilenilmelidir (ben değilim).

Yardımcı olabilecek şeyler:

  • Daha hızlı NIC kartları (SQL sunucusunda).
  • Sunucular arasına tahsis edilmiş / özel NIC kartı / alt ağ eklenmesi (web sunucusu ve SQL Server).

Web sunucusu SQL sunucusuyla aynı alt ağda mı?

Aralarında yönlendiriciler / köprüler vb. Var mı?

SQL sunucusunda pek çok olası değişiklik yok:

  • Çıktı verileri, tescilli MS "TDS protokolü" ile SQL Server tarafından gönderiliyor.
  • TDS arabelleğinin varsayılan boyutu 4 KB'dir. Bkz. MSDB: "ağ paket boyutu Seçeneği"
  • Verilerin sıkıştırılması (SQL Server veya harici bir uygulama ile) - verilerin niteliğine bağlıdır.

Varsayılan bir boyut kullanıyorsunuz: istatistiklerinize bakın: "Sunucu 1216'dan alınan TDS paketleri" (4MB / 1K = 4KB). Evet, TDS arabelleğinin boyutu değiştirilebilir: bkz. Google: "TDS protokolü toplu iş boyutu"

Şu konuda iyi bir tartışma: "sql'nin ağ paket boyutu gerçekten gidiş-dönüş trafiğini belirliyor mu?"

Bununla birlikte, TDS paket boyutunun değiştirilmesi (kaçınılmaz olarak) öngörülemeyen etkilere sahip olacaktır ve sadece istisnai durumlarda üretimde kullanılmalıdır.

Mimarinin değiştirilmesi veya verilerin orta kademe önbelleğe alınması da yardımcı olacaktır.


8

Bu sorun çözüldü.

Bu bir ağ sorunuydu ve SQL kutusu 10 GB / s NIC kartı yerine 100 MB / s NIC kartı kullanıyordu ...

Doğru ağ kartını kullanmak için bir ağ yapılandırması değişikliği sorunu çözdü. Şimdi Üretim SQL kutusundan ve ağdaki diğer kutulardan tüm sorgular için benzer performans elde ediyoruz.

Yardımlarınız için herkese teşekkürler.


Sizinle tam olarak aynı sorunum var ve SQL Server'ımın hangi NIC kartını kullandığını kontrol etmek istiyorum. Bunu nerede görebilirim?
Misha Zaslavsky

3

İlk okumada bazı ağ gecikme sorunları yaşıyormuşsunuz gibi geliyor. Network Perfmon sayaçlarından bazılarına baktınız mı? Bunlar ağda neler olup bittiğine dair bazı göstergeler verebilir.

Alıntı Ne Perfmon sayaçları ı izlemeli ve her ne anlama geldiğini?

AĞ G / Ç

Ağ G / Ç'sini ölçmek için aşağıdaki sayaçları kullanabilirsiniz:

Ağ Arayüzü Bayt Toplam / sn

Eşik: Ağ bant genişliğinin yüzde 80'inden fazlasında sürekli değerler.

Önem: Bu sayaç, baytların her ağ bağdaştırıcısı üzerinden gönderilme ve alınma hızını gösterir. Bu sayaç, ağ bağdaştırıcınızdaki trafiğin doygun olup olmadığını ve başka bir ağ bağdaştırıcısı eklemeniz gerekip gerekmediğini bilmenize yardımcı olur. Bir sorunu ne kadar hızlı tanımlayabileceğiniz, sahip olduğunuz ağın türüne ve bant genişliğini diğer uygulamalarla paylaşıp paylaşmamanıza bağlıdır.

Ağ Arayüzü Alınan Bayt / sn

Bu sayaç, her ağ bağdaştırıcısı üzerinden bayt alma hızını gösterir. Gelen verilerin hızını toplam bant genişliğinin bir parçası olarak hesaplayabilirsiniz. Bu, istemciden gelen verileri optimize etmeniz veya gelen trafiği işlemek için başka bir ağ bağdaştırıcısı eklemeniz gerektiğini bilmenize yardımcı olur.

Gönderilen Ağ Arayüzü Bayt / sn

Bu sayaç, baytların her ağ bağdaştırıcısı üzerinden gönderilme hızını gösterir. Gelen verilerin hızını toplam bant genişliğinin bir parçası olarak hesaplayabilirsiniz. Bu, istemciye gönderilen verileri optimize etmeniz veya giden trafiği işlemek için başka bir ağ bağdaştırıcısı eklemeniz gerektiğini bilmenize yardımcı olur.

ServerBytes Toplam / sn

Bu değer, ağ kapasitesinin yüzde 50'sinden fazla olmamalıdır.

Bu sayaç, ağ üzerinden gönderilen ve alınan bayt sayısını gösterir. Yüksek değerler ağ bant genişliğini darboğaz olarak gösterir. Tüm sunucular için Toplam Bayt / sn toplamı kabaca ağınızın maksimum aktarım hızına eşitse, ağı segmentlere ayırmanız gerekebilir.

İşlemci% Kesme Süresi

Bu sayaç, işlemcinin donanım kesintilerini almak ve bakımını yapmak için harcadığı sürenin yüzdesini gösterir. Bu değer, ağ bağdaştırıcıları gibi kesinti oluşturan aygıtların etkinliğinin dolaylı bir göstergesidir.

Ağ Arayüzü (*) Çıkış Sırası Uzunluğu

Bu sayaç, ağ bağdaştırıcısında kaç iş parçacığının beklendiğini kontrol eder. Ağ bağdaştırıcısında çok sayıda iş parçacığı varsa, sistem büyük olasılıkla ağ gecikmesi veya ağ bant genişliği nedeniyle ağ G / Ç'sini doyurur.

Çıktı Kuyruğu Uzunluğu, çıktı paketi kuyruğunun uzunluğudur (paketler halinde). Bu ikiden uzunsa, gecikmeler olur ve mümkünse darboğaz bulunmalı ve ortadan kaldırılmalıdır. İstekler bu uygulamada Ağ Sürücüsü Arabirim Belirtimi (NDIS) tarafından sıraya alındığından, bu her zaman 0 olur.


Perfmon'da bu istatistikleri izledikten sonra birkaç şey fark ettim. Toplam bayt / sn hiçbir ağ kartında 700K / s'nin üzerine çıkmaz. Megabayt veri isteyen bir sorgu çalıştırıyor olsam bile, bu sayı yaklaşık 500K / sn. Bant genişliğimiz 100 MBPS'dir ve% 1 oranında kullanmıyoruz. Paketlerin boyutunu zorlayan veya aktarım hızını sınırlayan bir yerde yapılandırılmış bir sınır olması gerektiğini düşünüyorum. Donanım kesintileri / sn 700-2000'de. Çıktı kuyruğu boş. Ağ kartı kullanımı en yüksek seviyede yaklaşık% 4'tür.
FranticRock

2
Ağ kartı hızı ile anahtar bağlantı noktası arasında bir uyumsuzluk olabilir. Ağ ekibinizi anahtar tarafından bakmak için görevlendirdiniz mi?
jgardner04

2

Bazı ön sorular: 1) Sunucunun Prod üzerinde bir SQL istemcisi vardır. sunucu makine kurulumu, değil mi? Aynı makinede bulunan istemciden aynı sorguyu yaparsanız, 2 saniye içinde tamamlanacak mı? Bunu yapmaya çalıştın mı? Gerçekten 2 saniye mi? 2) Üretim ortamınızın yapılandırmasının değiştiğinden (veya üretim sunucusunun başka bir ağa / toplam sunucu yeniden yapılandırmasına taşındığından) bahsetmiştiniz, değil mi? Eski üretim ortamında sorgu tüketim süresi neydi?

Aynı ağdaki diğer herhangi bir kutudan ... aynı sorgu 1 dakika 8 saniye sürer. 3) Sorgunun yaklaşık 70 saniye içinde belirli bir ağdaki herhangi bir makinede (özel makinenizi beklerken) bulunan istemciden döndüğünü ve tüketildiğini mi söylüyorsunuz? Doğru anladım? 3.1 Bu arada, bu sorgunun işletme tarafından kabul edilme süresi nedir? 4) Bununla birlikte, sorgu çıkış tüketim süresini kullandığınız belirli bir istemci makine için aşağıdakileri belirtiyorsunuz: İstemci Yürütme Süresi 15:30: 48 15 dakika? (ve bu kez açıkça kabul edilemez)? Doğru? 5) böylece sorun tek bir istemci makine ile sınırlıdır? Veya HERHANGİ BİR müşteri / orta katman vb makineye (yeni bir ortamda)? 6) Ping ile gösterilen gecikme nedir? istemci bilgisayardan sunucuya? 7) Siz (veya ağ yöneticisi) tracert'i her iki şekilde de çalıştırdınız (istemciden sunucuya, sunucudan istemciye)? Kaç şerbetçiotu? Birleştirilen süre nedir? 8) Eski üretim ağı canlı mı? Ping ve Traceroute kullanarak karşılaştırabilir misiniz - orada istemci ve sunucu arasındaki zaman ve atlama sayısı neydi?

Merak ettikten: bu sorguya bir örnek mi? veya sorgunun tam metni? Sorgu gerçekten WHERE yan tümcesi içermiyor mu? Bu çok sıradışı olduğunu bana katılıyorum .. Tablo kümelenmiş bir dizin veya bir yığın mı? Tabloda toplam kaç satır var? Masa ağır parçalanmış mı? Merak etmiyor: neden SELECT TOP NNN? Neden ROWCOUNT NNN ayarlamıyorsunuz - sonra SELECT *? Bu sorgu müşteri tarafından günde kaç kez verilir? 1? 100? 1MLN? Temel veriler statik veya dinamik ve çok değişti mi? Ne kadar (günde yüzde 0.01? Günde yüzde 1? Günde yüzde 10?) Sorgu çıktısı programlı olarak işleniyor mu? (kullanıcı tarafından değil?) Neden önbellekte saklanmaz / orta katmanda depolanmaz? teşekkürler, Alexei


Bilgi için çok teşekkürler. Aşağıdaki yanıtlarım. 1. Doğru. İstemci araçları da prod üzerine yüklendi ve bahsettiğim aynı sorgunun 30.000 kaydın tümünü (toplam 4 MB boyut) döndürmesi 2 saniye sürüyor. Bu arada, kullandığım sorgu sadece bir örnektir. Gerçek bir iş sorgusu değildir. Bu sadece bir tablodan 4 MB veri almanın bir yoludur. Şu anda herhangi bir sorgudaki herhangi bir tablodan birkaç megabayt veri okurken bir performans sorunumuz var.
FranticRock

2. Tüketim süresi yakındı, ancak aynı sorguyla aynı değilse PROD kutusundan yerel olarak kaçtı. (IE 2 saniye) 3. Bu doğru 1 dakika 8 saniye yürütme süresidir. Bu süre farklı istemci makineler arasında değişiklik gösterir. Geliştirme makinemizden (sahne makinesinden çok daha uzakta bulunur), bu sorguyu üst üste 8 kez çalıştırdım ve süre 11 saniye ila 22 saniye arasında değişti. (ortalama 18 sn.)
FranticRock

geliştirici kutusundan tradert Prod_IP_Address 1 53 ms 52 ms 53 ms SQL2008 Sahne makinesinden, süre sürekli olarak 1 dakikanın üzerindedir. tracert Prod_IP_Address tracert: 1 1 ms <1 ms <1 ms SQL2008 Üretim web sunucusundan: yürütme süresi 53 saniyedir. traktör: 1 1 ms <1 ms <1 ms SQL2008
FranticRock

4. Üst sütun "İstemci Yürütme Süresi" yalnızca makinenin yerel saatidir (IE: 15:30:00) 5. Sorun, üretim web sunucumuz da dahil olmak üzere üretim DB sunucusuna isabet eden herhangi bir makinede oluşur. 6. Ping gecikmesi, sahne kutusundan eşya SQL kutusuna <1 MS'dir. 7. Lütfen yukarıya bakınız. 8. Maalesef eski ağ artık mevcut değil.
FranticRock

DEV 53 MS'e ping atmasına rağmen, sorguyu çalıştırmak sadece 11-22 saniye sürüyor. Evre 1 MS ping yaparken, verilerin geri döndürülmesi 1 dakikadan fazla sürer. Dev coğrafi olarak çok daha uzakta. Ve sahne prod kutusunun hemen yanında ve daha uzun sürüyor.
FranticRock
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.