Üretim SQL Server'ımızdaki önemli performans sorunları, bu sorunu nasıl giderebilirim?

Bu soru temel olarak bu sorunun bir takip sorusudur:
SQL Server 2016 ile garip performans sorunu

Şimdi bu sistemle üretken olduk. Son yazımdan bu yana bu SQL Server'a başka bir uygulama veritabanı eklendi.

bunlar sistem istatistikleri:

• 128 GB RAM (SQL Server için 110GB Maks bellek)
• 4 Çekirdek @ 2.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
• Windows Server 2012 R2
• VMware Sürümü HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools sürüm 10.0.9, yapı 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 Ekim 2016 18:17:30 Telif Hakkı (c) Windows Server 2012 R2 Standard 6.3 (Build 9600:) üzerinde Microsoft Corporation Standard Edition (64-bit) (Hiper)

Sistemimizde artık önemli performans sorunları var. Çok Yüksek CPU kullanımı ve iş parçacığı sayısı:

Etkinlik izleyicisinin bekleme istatistikleri (çok güvenilir olmadığını biliyorum)

Sp_blitzfirst sonuçları:

Sp_configure sonuçları:

Gelişmiş sunucu ayarları (sadece Almanca'da talihsizlik)

MAXDOP Ayarı benim tarafımdan değiştirildi.

Bu muhtemelen SQL Server'ın kendisi ile ilgili bir sorun olmadığını biliyorum . Bu muhtemelen sanallaştırma (vmware), ağ ile ilgili (bunu zaten test ettim) veya uygulamanın kendisiyle ilgili bir sorun. Sadece daha da çivi çakmak istiyorum.

Yüksek ASYNC_NETWORK_IO, sqlserver işlemi için yüksek bir iş parçacığı sayısına neden olur mu? Birçok işçiyi tükettiğini düşünürdüm çünkü iplikler kapatılamaz. Bu doğru mu?

İhtiyacınız olan her türlü ek bilgiyi vereceğim. Desteğin için şimdiden teşekkür ederim!

DÜZENLE:

Sonucu sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Öncelik 1: Yedekleme :

• Veritabanlarının Bulunduğu Aynı Sürücüye Yedekleme - veritabanı dosyalarının da bulunduğu son iki hafta içinde E: \ sürücüsünde 5 yedekleme yapılır. Bu dizi başarısız olursa ciddi bir riski temsil eder.

Öncelik 1: Güvenilirlik :

• Son 2 haftadan eski DBCC CHECKDB

  • babtec_prod - Son başarılı CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - Son başarılı CHECKDB: asla.

  • DEMO77 - Son başarılı CHECKDB: 2016-02-23 20: 31: 38.590

  • FINP - Son başarılı CHECKDB: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - Son başarılı CHECKDB: 2017-05-18 22: 10: 48.120

  • master - Son başarılı CHECKDB: asla.

  • model

  • msdb

  • PROD77 - Son başarılı CHECKDB: 2016-02-23 21: 33: 24.343

Öncelik 10: Performans :

• Sorgu Deposu Devre Dışı - Bu veritabanında yeni SQL Server 2016 Sorgu Deposu özelliği etkinleştirilmedi.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Öncelik 50: DBCC Olayları :

• DBCC DROPCLEANBUFFERS - Kullanıcı schorsch, DBCC DROPCLEANBUFFERS'ı 21 Eylül 2017 11:57 ile 21 Eylül 2017 11:57 arasında 1 kez çalıştırdı. Bu bir üretim kutusuysa, bu gerçekleştiğinde tüm verileri bellekten temizlediğinizi bilin. Ne tür bir canavar bunu yapardı?

• DBCC SHRINK% - Kullanıcı schorsch, 21 Eylül 2017 23:51 ve Okt 4 2017 09:02 arasında 6 kez dosya büzüşmesi gerçekleştirdi. Yani, ah, yolsuzluğu düzeltmeye mi yoksa yolsuzluğa neden mi çalışıyorlar?

• Genel Etkinlikler - 19 Eylül 2017 13:40 ile Okt 4 2017 15:20 arasında 287 DBCC etkinliği gerçekleşti. Bu, CHECKDB ve diğer genellikle iyi huylu DBCC olaylarını içermez.

Öncelik 50: Performans :

• Dosya Büyümeleri Yavaş PROD77 - 2 büyümenin her biri 15 saniyeden fazla sürdü. Otomatik büyümeyi daha küçük bir artışa ayarlamayı düşünün.

Öncelik 50: Güvenilirlik :

• Sayfa Doğrulaması Optimal Değil babtec_prod - [babtec_prod] veritabanında sayfa doğrulaması için TORN_PAGE_DETECTION var. SQL Server, depolama bozulmasını tanımak ve kurtarmaktan daha zor olabilir. Bunun yerine CHECKSUM kullanmayı düşünün.

Öncelik 100: Performans :

• Bir Sorgu için Birçok Plan - 3576 plan, plan önbelleğindeki tek bir sorgu için mevcuttur - muhtemelen parametrelendirme sorunlarımız vardır.

Öncelik 110: Performans :

• Kümelenmiş Dizin İçermeyen Etkin Tablolar

  • babtec_prod - [babtec_prod] veritabanında aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - vardır.

  • D3PR - [D3PR] veritabanında aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - vardır.

  • DEMO77 - [DEMO77] veritabanında aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - var.

  • FINP - [FINP] veritabanında, aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - vardır.

  • GridVis_EnMs - [GridVis_EnMs] veritabanında aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - vardır.

  • PROD77 - [PROD77] veritabanında aktif olarak sorgulanan yığınlar - kümelenmiş dizin içermeyen tablolar - var.

Öncelik 150: Performans :

• Yabancı Anahtarlar Güvenilir Değil

  • babtec_prod - [babtec_prod] veritabanında büyük olasılıkla devre dışı bırakılmış yabancı anahtarlar var, veriler değiştirildi ve anahtar yeniden etkinleştirildi. Optimize edicinin bu anahtarı kullanması için sadece anahtarı etkinleştirmek yeterli değildir - WITH CHECK CHECK CONSTRAINT parametresini kullanarak tabloyu değiştirmeliyiz.

  • D3PR - [D3PR] veritabanında muhtemelen devre dışı bırakılmış yabancı anahtarlar var, veriler değiştirildi ve anahtar tekrar etkinleştirildi. Optimize edicinin bu anahtarı kullanması için sadece anahtarı etkinleştirmek yeterli değildir - WITH CHECK CHECK CONSTRAINT parametresini kullanarak tabloyu değiştirmeliyiz.

• Kümelenmiş Dizin İçermeyen Etkin Olmayan Tablolar

  • D3PR - [D3PR] veritabanında, son yeniden başlatmadan sonra sorgulanmamış yığınlar - kümelenmiş dizin içermeyen tablolar - vardır. Bunlar dikkatsizce geride bırakılan yedek tablolar olabilir.

  • GridVis_EnMs - [GridVis_EnMs] veritabanında, son yeniden başlatmadan sonra sorgulanmamış yığınlar - kümelenmiş dizin içermeyen tablolar - vardır. Bunlar dikkatsizce geride bırakılan yedek tablolar olabilir.

• Tablolardaki Tetikleyiciler babtec_prod - [babtec_prod] veritabanında 26 tetikleyici vardır.

Öncelik 170: Dosya Yapılandırması :

• C Sürücüsünde Sistem Veritabanı

  • master - Ana veritabanı C sürücüsünde bir dosyaya sahiptir. Sistem veritabanlarını C sürücüsüne koymak, boş alan kaldığında sunucuyu çökme riskiyle karşı karşıya kalır.

  • model - Model veritabanında C sürücüsünde bir dosya vardır. Sistem veritabanlarını C sürücüsüne koymak, boş alan kaldığında sunucuyu çökme riskiyle karşı karşıya kalır.

  • msdb - msdb veritabanı C sürücüsünde bir dosyaya sahiptir. Sistem veritabanlarını C sürücüsüne koymak, boş alan kaldığında sunucuyu çökme riskiyle karşı karşıya kalır.

Öncelik 170: Güvenilirlik :

• Maksimum Dosya Boyutu Seti

  • D3PR - [D3PR] veritabanı dosyasının d3_data_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_data_idx_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_firm_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_firm_idx_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_log_01 dosyası maksimum dosya boyutu 61440MB olarak ayarlanmıştır. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_phys_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_phys_idx_01 dosyası maksimum 61440MB olarak ayarlanmış dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_sys_01 dosyası maksimum 20480MB olarak ayarlanmış bir dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_usr_01 dosyası maksimum 20480MB olarak ayarlanmış bir dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_wort_01 dosyası maksimum 20480MB olarak ayarlanmış bir dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

  • D3PR - [D3PR] veritabanı dosyasının d3_wort_idx_01 dosyası maksimum 20480MB olarak ayarlanmış bir dosya boyutuna sahip. Boş alan kalmazsa, kullanılabilir sürücü alanı olsa bile veritabanı çalışmayı durduracaktır.

Öncelik 200: Bilgilendirici :

• Yedek Sıkıştırma Varsayılan Kapalı - Sıkıştırılmamış tam yedeklemeler son zamanlarda gerçekleşmiştir ve yedekleme sıkıştırması sunucu düzeyinde açılmamıştır. Yedekleme sıkıştırması, Standart Sürüm'de bile SQL Server 2008R2 ve daha yenisine dahil edilmiştir. Geçici yedeklerin sıkıştırılmasını sağlamak için yedekleme sıkıştırmasını varsayılan olarak açmanızı öneririz.

• Harmanlama Latin1_Genel_CS_AS FINP - Kullanıcı veritabanları ve tempdb arasındaki harmanlama farklılıkları, özellikle dize değerleri karşılaştırılırken çakışmalara neden olabilir

• Harmanlama SQL_Latin1_General_CP1_CI_AS - Kullanıcı veritabanları ve tempdb arasındaki harmanlama farklılıkları, özellikle dize değerleri karşılaştırılırken çakışmalara neden olabilir

  • DEMO77

  • PROD77

• Bağlı Sunucu Yapılandırıldı - BWIN2 \ INFOR bağlı bir sunucu olarak yapılandırıldı. Güvenlik yapılandırmasını sa ile bağlanırken kontrol edin, çünkü sorgulayan herhangi bir kullanıcı yönetici düzeyinde izin alacaktır.

Öncelik 200: İzleme :

• Başarısız E-postalar Olmadan Aracı İşleri

  • Syspolicy_purge_history işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Upd_durchpreis_monatl işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Upd_fertmengen_woche işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Upd_liegezeit_monatl işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Upd_vertreter_diff işi başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • UPDATE_CONNECT_IK işi başarısız olursa bir operatörü bilgilendirmek için ayarlanmamış.

  • Wartung.Cleanup işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.DBCC Check DB işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.Index neu erstellen işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.Statistiken aktualisieren işi başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.Transactionlog Backup işi başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.Vollbackup SystemDB işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

  • Wartung.Vollbackup UserDB işi, başarısız olursa bir operatörü bilgilendirmek için ayarlanmamıştır.

• Yolsuzluk Uyarısı Yok - SQL Server Agent uyarıları 823, 824 ve 825 hataları için mevcut değildir. Bu üç hata size erken donanım hatası hakkında bildirimde bulunabilir. Onları etkinleştirmek sizi çok fazla kalp kırıklığına uğratabilir.

• Sev 19-25 için Uyarı Yok - SQL Server Agent uyarıları 19 ile 25 arasındaki önem düzeyleri için mevcut değildir. Bunlar çok ciddi SQL Server hatalarıdır. Bunların olduğunu bilmek hatalardan daha hızlı iyileşmenizi sağlayabilir.

• Tüm Uyarılar Yapılandırılmadı - Tüm SQL Server Agent uyarıları yapılandırılmamıştır. Bu, izleme sistemleri tarafından alınmadan önce bile yolsuzluk, iş başarısızlıkları veya büyük kesintiler hakkında bildirim almanın ücretsiz ve kolay bir yoludur.

Öncelik 200: Varsayılan Olmayan Sunucu Yapılandırması :

• Agent XPs - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• Veritabanı Posta XP'leri - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• varsayılan tam metin dili - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 1033'tür ve 1031 olarak ayarlanmıştır.

• varsayılan dil - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• filestream erişim seviyesi - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

• maksimum paralellik derecesi - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 4 olarak ayarlanmıştır.

• max sunucu belleği (MB) - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 2147483647'dir ve 115000 olarak ayarlanmıştır.

• min sunucu belleği (MB) - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 10000 olarak ayarlanmıştır.

• uzak yönetici bağlantıları - Bu sp_configure seçeneği değiştirildi. Varsayılan değeri 0'dır ve 1 olarak ayarlanmıştır.

Öncelik 200: Performans :

• Paralellik için maliyet eşiği - Varsayılan değeri olan 5'e ayarlayın. Bu sp_configure ayarının değiştirilmesi CXPACKET beklemelerini azaltabilir.

• Anlık Görüntü Yedekleri Meydana Geliyor - Son iki hafta içinde GÇ'nin donuyor olabileceğini gösteren 9 adet anlık görüntü yedekleme gerçekleşti.

Öncelik 210: Varsayılan Olmayan Veritabanı Yapılandırması :

• Okunmuş Anlık Görüntü Yalıtımı Etkin - Bu veritabanı ayarı varsayılan değildir.

  • D3PR

  • FINP

• Özyinelemeli Tetikleyiciler Etkin - Bu veritabanı ayarı varsayılan değildir.

  • DEMO77

  • PROD77

• Anlık Görüntü Yalıtımı Etkin FINP - Bu veritabanı ayarı varsayılan değildir.

Öncelik 240: Bekleme İstatistikleri :

• 1 - ASYNC_NETWORK_IO - 225,9 saat bekleme, saatte ortalama 143,5 dakika bekleme süresi,% 0,2 sinyal bekleme, 2146022 bekleme görevi, 378,9 ms ortalama bekleme süresi.

• 2 - CXPACKET - 43,1 saat bekleme, saatte ortalama 27,4 dakika bekleme süresi,% 1,5 sinyal bekleme, 32608391 bekleme görevi, 4,8 ms ortalama bekleme süresi.

Öncelik 250: Bilgilendirici :

• SQL Server bir NT Service hesabı altında çalışıyor

  • NT Service \ MSSQL $ INFOR olarak çalışıyorum. Bunun yerine bir Active Directory hizmet hesabım olsaydı.

  • NT Service \ SQLAgent $ INFOR olarak çalışıyorum. Bunun yerine bir Active Directory hizmet hesabım olsaydı.

Öncelik 250: Sunucu Bilgisi :

• Varsayılan İzleme İçeriği - Varsayılan izleme, 3 Eylül 2017 20:34 ile Okt 5 2017 12:50 arasında 760 saatlik veri içerir. Varsayılan izleme dosyaları şu konumda bulunur: C: \ Program Dosyaları \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Drive C Space - C sürücüsünde 21308.00MB ücretsiz

• Drive D Space - D sürücüsünde 280008.00MB ücretsiz
• Drive E Space - E sürücüsünde ücretsiz 281618.00MB

• Drive F Space - F sürücüsünde ücretsiz 60193.00MB

• Donanım - Mantıksal işlemciler: 4. Fiziksel bellek: 128GB.

• Donanım - NUMA Yapılandırma - Düğüm: 0 Durum: ONLINE Çevrimiçi zamanlayıcılar: 4 Çevrimdışı zamanlayıcılar: 0 İşlemci Grup: 0 Bellek düğümü: 0 Bellek VAS Ayrılmış GB: 281

• Sunucu Son Yeniden Başlatma - Okt 1 2017 14:21

• Sunucu Adı - BWINPDB \ INFOR

• Hizmetler

  • Hizmet: SQL Server (INFOR), NT Service \ MSSQL $ INFOR hizmet hesabı altında çalışır. Son başlangıç ​​zamanı: Okt 2017 14:22. Başlangıç ​​türü: Otomatik, şu anda Çalışıyor.

  • Hizmet: SQL Server-Agent (INFOR), NT Service \ SQLAgent $ INFOR hizmet hesabı altında çalışır. Son başlangıç ​​zamanı: gösterilmiyor .. Başlangıç ​​türü: Otomatik, şu anda Çalışıyor.

• SQL Server Son Yeniden Başlatma - Okt 1 2017 14:22

• SQL Server Hizmeti - Sürüm: 13.0.4001.0. Yama Seviyesi: SP1. Sürüm: Standart Sürüm (64 bit). AlwaysOn Etkin: 0. AlwaysOn Mgr Durumu: 2

• Sanal Sunucu - Tür: (HYPERVISOR)

• Windows Sürümü - Windows'un oldukça modern bir sürümünü kullanıyorsunuz: Server 2012R2 dönemi, sürüm 6.3

Öncelik 254: Rundate :

• Kaptanın günlüğü: bir şeyleri ve şeyleri yıldızla işaretleyin ...

DÜZENLE:

Vmware ile sql sunucusu kurmayla ilgili en iyi uygulamalar kılavuzunu zaten inceledim ve çoğunu bu makaleye göre ayarladık. Bununla birlikte, hiper iş parçacığı etkinleştirilmemiştir ve vmware ana bilgisayarında NUMA etkin değildir. SQL Server NUMA olarak ayarlanmış.

DÜZENLE:

Paralellik için harmanlamayı 50'ye ayarladıktan sonra RECONFIGURE'u verdim, ayrıca MAXDOP ayarım da yapılandırılmadı.

Ayrıca vmware admin ile kontrol, ben yanlış bilgi gibi görünüyor. CPU'larımız 4.6 GHz yerine 2.6GHz olarak ayarlanmıştır. Yukarıdaki bilgileri düzelttim.

DÜZENLE:

Bu vmwarekb ve rehbere göre bazı ağlar kurmaya çalıştık . Ayrıca VM'ye 4 çekirdek daha ekledik. CPU kullanımı aynı kaldı.

Bahsedildiği gibi bu soruyu sordum son kez , üst bekleme ASYNC_NETWORK_IO olduğunu. SQL Server, borunun diğer ucundaki makinenin bir sonraki sorgu sonuçları sırasını sindirmesini beklemektedir.

Bu bilgiyi sp_Blitz'in beklediği istatistik sonuçlarından aldım (bunu yapıştırdığın için teşekkürler):

1 - ASYNC_NETWORK_IO - 225,9 saat bekleme, saatte ortalama 143,5 dakika bekleme süresi,% 0,2 sinyal bekleme, 2146022 bekleme görevi, 378,9 ms ortalama bekleme süresi.

CPU iş parçacıklarında sorun gidermeyin - bu ilgili değildir. Birincil bekleme türünüze ve bu bekleme türüne neden olabilecek şeylere odaklanın.

Bu sorunu daha da gidermek için, sp_WhoIsActive veya sp_BlitzFirst komutunu çalıştırın. Bekleme bilgisi sütununa bakın, ASYNC_NETWORK_IO için bekleyen sorguları bulun ve çalıştıkları uygulamalara ve sunuculara bakın.

Oradan deneyebilirsiniz:

• Bu uygulama sunucularının gücünün düşük olup olmadığını kontrol etmek (CPU'da maksimumda olsalar veya diske disk belleği gibi)
• Sonuçlar üzerinde satır satır işlem yapıp yapmadıklarını görmek için uygulama geliştiricileriyle birlikte çalışarak (SQL Server'dan gelen her satırda olduğu gibi, uygulama kapanır ve bir sonraki sonuç satırını sormadan önce bazı işlemler yapar)
• Daha az veri seçmek için uygulama geliştiricileriyle birlikte çalışmak (tüm verilere ihtiyaç duymuyorlarsa daha az satır veya daha az sütun gibi) bazen bunu yanlışlıkla bir SELECT * yaptığında ve gerektiğinden daha fazla veri getirdiğinde görürsünüz veya isterler sadece ilk 1000'e ihtiyaç duyduklarında tüm satırlar)

Sp_WhoIsActive ile güncelleme - gönderdiğiniz sp_WhoIsActive ekran görüntüsünde, ASYNC_NETWORK_IO üzerinde bekleyen birkaç sorgunuz var. Bunlar için yukarıdaki talimatlara bakın.

Sorguların geri kalanında sp_WhoIsActive'ın "durum" sütununa bakın - bunların çoğu "uyuyor". Yani hiç çalışmıyorlar - borunun diğer ucundaki uygulamaların bir sonraki komutlarını göndermesini bekliyorlar. İşlemleri açık ("open_tran_count" sütununa bakın) ama SQL Server'ın uyku işlemini hızlandırmak için yapabileceği hiçbir şey yok. Bu sorgular kırk dakikadan fazla süredir açıktır (sp_WhoIsActive'in ilk sütunu. Artık hiçbir şey yapmıyorlar. Bu kişileri işlemlerini gerçekleştirmeleri ve bağlantılarını kapatmaları için almanız gerekiyor. Bu bir performans ayarlama sorunu değil.

Burada gördüğümüz her şey uygulamada beklediğimiz bir senaryoya işaret ediyor.

Kendi sorumu cevaplamak için. ASYNC_NETWORK_IO aslında asıl sorun değildi. Gecikmeye duyarlı iş yükleri için bu kılavuzu izleyerek performans sorunumuzu düzelttik:

VSphere VM'lerinde Gecikme Duyarlı İş Yüklerinin Performans Ayarlaması için En İyi Uygulamalar

Sistemimize uyguladığımız ayarları burada sarı renkle işaretledim:

Ben en çok etkisi olan ayarları olduğunu düşünüyorum numa yapılandırma ve ayar gecikme hassasiyet için en yüksek . Her ikisi de VM için fiziksel CPU çekirdeği ve RAM ayırmak / ayırmak için gerekli.

Ayrıca VM'ye SQL Server lisansımızı Standard'dan Enterprise'a yükseltmek için daha fazla çekirdek ekledik.

Görünüşe göre Windows, 4.6Ghz CPU çekirdeklerinizin saat hızını 2.6Ghz olarak bildiriyor ... Gerçekte hangi hızda çalıştıklarını kontrol etmek için CPU-Z gibi bir araç çalıştıracak ve daha sonra güç ayarlarını değiştirmeye bakacağım. çekirdeği daha düşük bir hıza düşürecek güç tasarrufu ayarlarını devre dışı bırakmak için hem Windows hem de BIOS / Yönetim İşletim Sistemi.