Uygulama sorgulama boş tablolar

Şirketim oldukça önemli performans sorunları olan bir uygulama kullanıyor. Ben çalışma sürecinde olan veritabanı kendisi ile ilgili bir takım sorunlar var, ama sorunların çoğu tamamen uygulama ile ilgilidir.

Benim araştırmada boş tabloları sorgulayan SQL Server veritabanına isabet milyonlarca sorgu olduğunu buldum. Yaklaşık 300 boş masamız var ve bu tablolardan bazıları dakikada 100-200 kez sorgulandı. Tablolar bizim iş alanı ile ilgisi yoktur ve aslında firmamız tarafından bizim için bir yazılım çözümü üretmek için sözleşme yaptıklarında satıcının kaldırmadıkları orijinal uygulamanın parçalarıdır.

Uygulama hata günlüğümüzün bu sorunla ilgili hatalarla dolu olduğundan şüphelenmemizin yanı sıra, satıcı uygulama veya veritabanı sunucusu için performans veya kararlılık etkisi olmadığını bize garanti eder. Hata günlüğü, tanılama yapmak için 2 dakikadan fazla hata göremediğimiz ölçüde sular altında kalır.

Bu sorguların gerçek maliyeti açıkça CPU döngüleri vb açısından düşük olacak. Ama herkes SQL Server ve uygulama üzerindeki etkisinin ne olacağını önerebilir? Bir istek gönderme, onaylama, işleme, geri gönderme ve makbuzun uygulama tarafından kabul edilmesinin gerçek mekaniğinin performans üzerinde bir etkisi olacağını sanıyorum.

Uygulama için SQL Server 2008 R2, Oracle Weblogic 11g kullanıyoruz.

@ Frizbi- Uzun öykü, uygulamanın veritabanındaki boş tablolara çarpan sorgu metnini içeren bir tablo oluşturdum, sonra bildiğim tüm tablenames için boş ve çok uzun bir liste aldım. En çok isabet, 30 günlük çalışma süresi boyunca 2,7 milyon uygulamada gerçekleşti. Uygulamanın genellikle sabah 8 ile akşam 6 arasında kullanıldığını ve bu rakamların çalışma saatlerine daha yoğunlaştığını unutmayın. Birden çok tablo, birden çok sorgu, muhtemelen bazı birleşimler yoluyla ilgili, bazıları değil. En iyi hit (o zaman 2.7 milyon), nerede cümlesi olan, birleştirme içermeyen tek bir boş masadan basit bir seçimdi. Boş tablolar birleştirme ile daha büyük sorgular bağlantılı tablolarda güncelleştirmeler içerebilir, ancak bunu kontrol ve bu soruyu en kısa sürede güncelleyeceğim.

Güncelleme: Yürütme sayısı 1043 - 4622614 (2,5 aydan fazla) olan 1000 sorgu vardır. Önbelleğe alınan planın ne zaman kaynaklandığını öğrenmek için daha fazla araştırma yapmam gerekecek. Bu sadece sorguların kapsamı hakkında bir fikir vermek içindir. Çoğu, 20'den fazla birleştirme ile makul derecede karmaşıktır.

@ srutzky- evet Planın ne zaman derlendiğiyle ilgili bir tarih sütunu olduğuna inanıyorum ki bu ilgi çekiciydi, bu yüzden kontrol edeceğim. SQL Server bir VMware kümesinde oturduğunda iş parçacığı sınırları hiç bir faktör olacağını merak ediyorum? Çok yakında özel bir Dell PE 730xD olacak.

@Frisbee - Geç cevap verdiğim için üzgünüm. Önerdiğiniz gibi, boş tablodan SQLQueryStress (aslında 240.000 yineleme) kullanarak 24 iş parçacığında 10.000 kez 10.000 kez çalıştırdım ve hemen 10.000 Toplu İstek / sn'ye ulaştım. Sonra 24 iş parçacığı üzerinde 1000 katına düştüm ve 4.000 Toplu İstek / sn'nin altına düştüm. Ayrıca sadece 12 iş parçacığında (toplam 120000 yineleme) 10.000 yineleme denedim ve bu sürekli 6.505 Parti / sn üretti. CPU üzerindeki etkisi, her test çalışması sırasında toplam CPU kullanımının yaklaşık% 5-10'unun gerçekten fark edildi. Ağ beklemeleri ihmal edilebilir (benim iş istasyonunda müşteri ile 3 ms gibi) ama CPU etkisi orada oldu, ki ben endişeliyim kadar oldukça kesin. CPU kullanımı ve biraz gereksiz veritabanı dosyası IO'ya kaynıyor gibi görünüyor. Toplam infaz / saniye 3000'in hemen altında çalışıyor, bu da üretimde olduğundan daha fazla, ancak bunun gibi düzinelerce sorgudan yalnızca birini test ediyorum. Boş tablolara dakikada 300-4000 kez vuran yüzlerce sorgunun net etkisi bu nedenle CPU zamanı söz konusu olduğunda göz ardı edilemez. Tüm testler, çift flaş dizisi ve 256 GB RAM, 12 modern çekirdek ile boş bir PE 730xD'ye karşı yapılmıştır.

@ srutzky- iyi düşünce. SQLQueryStress varsayılan olarak bağlantı havuzu kullanmak gibi görünüyor ama yine de bir göz vardı ve evet, bağlantı havuzu kutusu işaretlenmiş bulundu. Takip etmek için güncelleme

@ srutzky- Uygulamada bağlantı havuzlaması etkin değil - ya da çalışıyorsa çalışmıyor. Bir profil oluşturucu izledim ve bağlantıların Denetim Giriş etkinlikleri için EventSubClass "1 - Arabasız" olduğunu buldum.

RE: Bağlantı Havuzu Oluşturma - Weblogları kontrol etti ve bağlantı havuzu oluşturmayı etkin buldum. Canlıya karşı daha fazla iz bıraktı ve doğru bir şekilde / hiç gerçekleşmeyen havuz belirtileri buldu:

Ve burada nüfuslu bir tablo karşı birleştirme ile tek bir sorgu çalıştırdığınızda nasıl görünüyor; istisnalar "SQL Server'a bağlantı kurulurken ağla ilgili veya örneğe özgü bir hata oluştu. Sunucu bulunamadı veya erişilemedi. Örnek adının doğru olduğunu ve SQL Server'ın uzak bağlantılara izin verecek şekilde yapılandırıldığını doğrulayın. (sağlayıcı: Adlandırılmış Kanallar Sağlayıcısı, hata: 40 - SQL Server bağlantısı açılamadı) "Toplu işlem istekleri sayacına dikkat edin. İstisnalar oluşturulduğu sırada sunucuyu pinglemek başarılı bir ping yanıtıyla sonuçlanır.

Güncelleme - art arda iki test çalıştırması, aynı iş yükü (BoşTable'dan * seçin), havuzlama etkin / etkin değil. Biraz daha fazla CPU kullanımı ve birçok arıza ve 500 toplu işlem isteğinin / saniyesinin üzerine çıkmaz. Testler 10.000 Parti / sn ve havuzlama AÇIK durumdayken hiçbir hata göstermez ve yaklaşık 400 parti / sn sonra havuzlamanın devre dışı bırakılması nedeniyle bir çok arıza gösterir. Acaba bu başarısızlık bağlantı kullanılabilirliği eksikliği ile ilgili mi?

@ srutzky- sys.dm_exec_connections içinden Sayıyı (*) seçin;

• Havuzlama etkin: Yük testi durduktan sonra bile 37 tutarlı

• Havuz devre dışı bırakıldı:
  SQLQueryStress'de istisnaların oluşup oluşmadığına bağlı olarak 11-37; yani: oluklar
  Toplu İşler / sn grafiğinde göründüğünde , SQLQueryStress'de istisnalar oluşur ve
  bağlantı sayısı 11'e düşer, sonra yavaş yavaş 37'ye kadar geri döner gruplar zirve yapmaya başladığında ve istisnalar meydana gelmediğinde. Çok, çok ilginç.

Test / canlı örneklerinde varsayılan olarak 0 olarak ayarlanmış maksimum bağlantılar.

Uygulama günlüklerini kontrol ettiniz ve bağlantı sorunlarını bulamıyorsunuz, ancak hataların çok sayıda ve boyutundan dolayı günlüğe kaydetme için sadece birkaç dakika var, yani yığın izleme hataları. Uygulama desteğindeki bir iş arkadaşı, bağlantıyla ilgili önemli sayıda HTTP hatasının oluştuğunu bildirir. Buna dayanıyor gibi görünüyor, bazı nedenlerden dolayı uygulama bağlantıları doğru bir şekilde havuzlamıyor ve sonuç olarak sunucunun bağlantıları sürekli olarak tükeniyor. Uygulama günlüklerine daha fazla bakacağım. Bu üretimde SQL Server tarafında olduğunu kanıtlamanın bir yolu var mı acaba?

@ srutzky- Teşekkür ederim. Yarın weblogic yapılandırmasını kontrol edip güncelleyeceğim. Ben sadece 37 bağlantıları hakkında olsa da düşünüyordum - SQLQueryStress 10.000 yinelemelerde 12 iş parçacığı = 120.000 seçin ifadeler havuzsuz, her seçim sql örneğine farklı bir bağlantı oluşturur anlamına gelmez?

@ srutzky- Weblogics bağlantıları birleştirecek şekilde yapılandırılmıştır, bu yüzden iyi çalışıyor olmalıdır. Bağlantı havuzu, yük dengeli 4 weblogun her birinde şu şekilde yapılandırılır:

• Başlangıç ​​Kapasitesi: 10
• Maksimum Kapasite: 50
• Minimum Kapasite: 5

Boş tablo sorgusundan seçim yapan iş parçacığı sayısını artırdığımda, bağlantı sayısı 47 civarında zirve yapıyor. Bağlantı havuzu oluşturma devre dışı bırakıldığında, sürekli olarak daha düşük bir maksimum toplu istek / sn (10.000'den 400'e kadar) görüyorum. Her seferinde ne olacağı, SQLQueryStress üzerindeki 'istisnalar', kümeler / sn bir oluğa girdikten kısa bir süre sonra gerçekleşir. Bağlanabilirlikle ilgilidir, ancak bunun neden olduğunu tam olarak anlayamıyorum. Hiçbir test yapılmadığında, #connections yaklaşık 12'ye düşer.

Bağlantı havuzu devre dışı bırakıldığında, istisnaların neden oluştuğunu anlamada sorun yaşıyorum, ancak belki de başka bir yığınDaha Machanic için soru / soru değiştirme?

@srutzky O zaman SQL Server bağlantıları tükenmese bile neden özelleştirme havuzu etkin olmadan gerçekleşir acaba?

Bir istek gönderme, onaylama, işleme, geri gönderme ve makbuzun uygulama tarafından kabul edilmesinin gerçek mekaniğinin performans üzerinde bir etkisi olacağını sanıyorum.

Evet ve bazı ek faktörler bile var, ancak bunların herhangi birinin sisteminizi gerçekten etkileme derecesi, sistemi analiz etmeden söylemek mümkün değildir.

Bununla birlikte, neyin bir sorun olabileceğini soruyorsunuz ve bunlardan bazıları şu anda sizin durumunuzda bir faktör olmasa bile, söylenecek bazı şeyler var. Bunu sen söyledin:

Yaklaşık 300 boş masamız var ve bu tabloların bazıları dakikada 100-200 kez sorgulandı.

• Sorgulanmayan boş tablolar sorun oluşturmaz. Ama sanırım hepsinin sorgulandığı anlamına da gelebilirsin, sadece bazıları diğerlerinden daha fazla vurulur.
• Sorgu ayrıştırma ve yürütme planı oluşturma çok sorunu olmamalı eğer sorgu metni kalıntıları çağrıları arasında aynı sunulmadan. SQL Server, sorgunun metnini toplar ve plan önbelleğinde arar. Bulunursa, ayrıştırma veya derleme adımlarını tekrar yapmaz (plan önbellekten kaldırılana kadar).
• Boş veya boş olmayan herhangi bir tablo, kaynağın kullanıldığını belirtmek için en az bir "paylaşılan" kilit gerektirir. Bu, özel kilitler gerektiren işlemlerin (sütun ekleme / değiştirme / kaldırma, vb.) Kaynak kullanımdayken değişiklik yapmasını engeller. Veri olmadığı için 1 milisaniyeden daha kısa bir sürede tamamlansa bile kilitleme ve kilidi açma, bu kilit işlemlerini yönetmek için yine de sistem kaynakları (bellek ve CPU) gerektirir.
• SQL Server'dan uygulamaya geri dönen hiçbir sonuç kümesi olmasa bile, sorgunun sonuç verip vermediğine bakılmaksızın SQL Server'a giden aynı miktarda ağ trafiği vardır. Saklanan yordamın sorgusunun veya adının gönderilmesi gerekir. Hiçbir sonuç geri gelmese bile, SQL Server, istemciye bir sonuç kümesinin başladığını (hiç satır bulunmasa bile) ve sonuç kümesinin ve kapatılmalıdır. Ve baskı ifadelerinden ve / veya satır sayımlarından ek mesajlar olabilir.
• SQL Server'a bağlanmak için bir miktar sistem kaynağı gerekir. Kimlik doğrulamasını işlemek için CPU ve bellek gerekir (ayrıca ağ paketlerini ileri geri) ve bu da zaman alır. İşte bu nedenle Bağlantı Havuzu Oluşturma: bu masrafı azaltmak.
• Sistem havuzu kullanımını azaltan Connection Pooling ile bile, SQL Server'ın bu bağlantıları sürdürmesi gerekir ve bu da bellek ve minimum CPU gerektirir.
• Hiçbir satır olmadan ve dolayısıyla çok hızlı bir yürütme süresi olsa bile , sorgu yine de yürütülmüştür. 10 veya 10.000 satır olsa ve bunlar sık ​​kullanıldıkları için Tampon Havuzundan (yani bellek) çekilse bile, bir iş parçacığının yine de bu işi yapması gerekir. Ve bu yararsız sorguyu çalışan bir iş parçacığı olduğunu değil gerçek kullanışlı sorgusu üzerinde çalışıyor.

Daha fazlası da olabilir, ama bu bir şeyler anlamanıza yardımcı olacaktır. Ve çoğu performans sorunu gibi, bunların hepsinin bir ölçek meselesi olduğunu unutmayın. Yukarıda belirtilen öğelerin tümü, dakikada bir kez vurulursa sorun değildir. İş istasyonunuzdaki veya geliştirme veritabanındaki bir değişikliği test etmek gibidir: her zaman tablolarda yalnızca 10 - 100 satırla çalışır. Bu kodu üretime taşıyın ve çalışması 10 dakika sürüyor ve birisi şunu söylemek zorunda: "iyi, kutumda çalışıyor" ;-). Yani, sadece bir sorun gördüğünüzde yapılan çağrıların hacmi nedeniyle, ancak mevcut olan durum budur.

Yani, 1 milyon yararsız, 0 satırlı sorguda bile, bu şu anlama gelir:

• fazladan 2 milyon kilit işlemi (her kilidin kilidi açılmalıdır, değil mi?). bu çoğunlukla yararlı bir operasyon yerine işe yaramaz bir operasyon için harcanan zaman maliyetidir.
• fazla ağ trafiği o olabilir daha yakın doygunluk sizi elde edilecektir (bu değil emin ne kadar muhtemel, ama yine de)

• daha fazla bağlantı korunur ve bu da daha fazla bellek gerektirir. Kullanılmayan fiziksel RAM miktarınız nedir? bu bellek, sorguları ve / veya sorgu planı önbelleğini çalıştırmak için daha iyi kullanılır. En kötü durum, fiziksel belleğinizin olmaması ve SQL Server'ın sanal belleği (takas) kullanmaya başlaması gerektiğidir, çünkü bu işleri yavaşlatır (disk belleği ile ilgili mesajlar alıp almadığınızı görmek için SQL Server hata günlüğünüzü kontrol edin).

  Ve herkesin bahsetmesi durumunda, "iyi, bağlantı havuzu var". Evet, bu kesinlikle gerekli bağlantı sayısını azaltmaya yardımcı olur. Ancak, sorguların dakikada 200 defaya kadar gelmesiyle, bu, meşru talepler için hala çok sayıda eşzamanlı etkinlik ve bağlantı bulunması gerekir. SELECT * FROM sys.dm_exec_connections;Kaç tane aktif bağlantı sağladığınızı görmek için a yapın.

• başka bir şeyden bağımsız olarak, bu her gün en az 1 milyon kez faydalı bir şey yapmış olabilecek bir iş parçacığının kullanılamamasıdır.

Burada belirttiğim şey hakkında yanlış değilsem, o zaman bana öyle geliyor ki, küçük bir ölçekte bile olsa, ağa ve SQL Server'ınıza sahte isteklerle su bastığından bu bir tür DDoS saldırısı sisteminizde gerçek isteklerin SQL Server'a ulaşmasını veya SQL Server tarafından işlenmesini önler.

Tablolar dakikada 100-200 kez vuruluyorsa (umarım) hafızadadırlar. Sunucudaki yük çok düşük. Veritabanı sunucusunda yüksek CPU veya bellek yoksa, bu muhtemelen bir sorun değildir.

Evet, sorgular paylaşılan kilitler alır, ancak umarım güncelleştirme kilitlerini engellemez veya herhangi bir güncelleme kilidi tarafından engellenmez. Bu tablolarda güncelleme, ekleme veya silme işleminiz var mı? Değilse ben sadece gitmek istiyorum - performans sorunları yaşıyorsanız bir veritabanı sunucusu perspektifinden kızartmak için daha büyük balık olması gerekir.

Boş bir masada 100.000 seçme sayısı (*) üzerinde bir test yaptım ve 32 saniye içinde koştu ve sorgular bir ağ üzerinden yapıldı. Yani 1/3 milisaniye. Ağınız aşırı yüklenmedikçe, bu istemciyi bile etkilemez. Büyük performans sorunları yaşıyorsanız, bu 1/3 milisaniye boş sorgular uygulamayı öldüren şey değildir.

Ve bunlar, geçerli uygulamanın bir parçası olmayan bazı statik tip verileri alan sol birleştirme işleminin bir parçası olabilir. Böylece ekstra bir yolculuk değil diğer sorguları ile zincirlenmiş olabilir. Eğer öyleyse, özensizdir ama daha fazla trafiğe bile neden olmaz.

Yani gerçek ifadelere bakmak için. Bu tablolarda güncelleme, ekleme veya silme işlemi görüyor musunuz?

Evet, birçok boş tablo ve boş tablolara yapılan sorgular özensiz kodlamanın bir göstergesidir. Ancak büyük performans sorunları yaşıyorsanız, bu tablolarla devam eden bazı gerçekten özensiz yazma işlemleriniz olmadıkça bu neden değildir.

Genel olarak her sorguda aşağıdaki adımlar uygulanır:

1. Başvuru Talebi.
2. Veritabanı Sorguyu ayrıştırın.
3. Veritabanı sorgusu, bu sorgunun zaten RAM'de depolanıp depolanmadığını kontrol eder. Bellekte varsa yürütme planını kullanın.
4. RAM'de yoksa, Veritabanı motoru sorgudaki nesneler hakkında mevcut istatistikleri kontrol eder ve yürütme planını belirler.
5. Yürütme planını çalıştırın, diskten veri almak için i / o kullanın.
6. uygulamaya yanıt.

Bahsettiğiniz gibi birçok sorgu zaten ağır olan bir sistemde ekstra yüke neden olabilir - bağlantılar, CPU, RAM ve G / Ç üzerinde ekstra yük.