Masalah kinerja utama pada SQL Server produksi kami, bagaimana saya memecahkan masalah ini?


11

Pertanyaan ini pada dasarnya adalah pertanyaan tindak lanjut untuk pertanyaan ini:
Masalah kinerja yang aneh dengan SQL Server 2016

Kami sekarang menjadi produktif dengan sistem ini. Meskipun database aplikasi lain telah ditambahkan ke SQL Server ini sejak posting terakhir saya.

ini adalah statistik sistem:

  • 128 GB RAM (memori 110GB Maks untuk SQL Server)
  • 4 Cores @ 2.6 GHz
  • Koneksi jaringan 10 GBit
  • Semua penyimpanan berbasis SSD
  • File program, file Log, file database dan tempdb berada di partisi server yang terpisah
  • Windows Server 2012 R2
  • Versi VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
  • VMware Tools versi 10.0.9, build 3917699
  • Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 Okt 2016 18:17:30 Hak cipta (c) Edisi Standar Microsoft Corporation (64-bit) pada Windows Server 2012 R2 Standard 6.3 (Build 9600:) (Hypervisor)

masukkan deskripsi gambar di sini

Sistem kami sekarang memiliki masalah kinerja utama. Penggunaan CPU dan jumlah utas sangat tinggi: masukkan deskripsi gambar di sini

Tunggu statistik monitor aktivitas (saya tahu itu tidak terlalu bisa diandalkan)

masukkan deskripsi gambar di sini

Hasil sp_blitzfirst:

masukkan deskripsi gambar di sini

Hasil sp_configure:

masukkan deskripsi gambar di sini

Pengaturan server tingkat lanjut (hanya untuk bahasa Jerman)

masukkan deskripsi gambar di sini

Pengaturan MAXDOP diubah oleh saya.

Saya sadar bahwa ini mungkin bukan masalah dengan SQL Server itu sendiri . Ini mungkin masalah dengan virtualisasi (vmware), jaringan terkait (saya sudah menguji ini) atau aplikasi itu sendiri. Saya hanya ingin memahaminya lebih jauh.

Apakah ASYNC_NETWORK_IO yang tinggi akan menghasilkan jumlah utas yang tinggi untuk proses sqlserver? Saya membayangkan itu membuat banyak pekerja karena utas tidak dapat ditutup. Apakah itu benar?

Saya akan memberikan info tambahan yang Anda butuhkan. Terima kasih sebelumnya atas dukungan Anda!

EDIT:

Hasil dari sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Prioritas 1: Cadangkan :

  • Mencadangkan ke Drive yang Sama Tempat Basis Data berada - 5 backup dilakukan pada drive E: \ dalam dua minggu terakhir, tempat file database juga hidup. Ini merupakan risiko serius jika array itu gagal.

Prioritas 1: Keandalan :

  • CHECKDB DBCC baik terakhir lebih dari 2 minggu

    • babtec_prod - Terakhir sukses CHECKDB: 2017-08-20 00: 01: 01.513

    • D3PR - CHECKDB sukses terakhir: tidak pernah.

    • DEMO77 - Terakhir berhasil CHECKDB: 2016-02-23 20: 31: 38.590

    • FINP - Terakhir berhasil CHECKDB: 2017-04-23 22: 01: 19.133

    • GridVis_EnMs - CHECKDB sukses terakhir: 2017-05-18 22: 10: 48.120

    • master - CHECKDB sukses terakhir: tidak pernah.

    • model

    • msdb

    • PROD77 - Keberhasilan terakhir CHECKDB: 2016-02-23 21: 33: 24.343

Prioritas 10: Kinerja :

  • Query Store Dinonaktifkan - Fitur SQL Server 2016 Query Store baru belum diaktifkan pada database ini.

    • babtec_prod

    • D3PR

    • DEMO77

    • FINP

    • GridVis_EnMs

Prioritas 50: Acara DBCC :

  • DBCC DROPCLEANBUFFERS - Schorsch pengguna telah menjalankan DBCC DROPCLEANBUFFERS 1 kali antara 21 Sep 2017 2017 11:57 dan 21 Sep 2017 11:57. Jika ini adalah kotak produksi, ketahuilah bahwa Anda menghapus semua data dari memori saat ini terjadi. Monster apa yang akan melakukan itu?

  • DBCC SHRINK% - Schorsch pengguna telah menjalankan penyusutan file 6 kali antara 21 Sep 2017 11:51 PM dan 4 Okt 2017 9:02 AM. Jadi, uh, apakah mereka berusaha memperbaiki korupsi, atau menyebabkan korupsi?

  • Keseluruhan Acara - 287 acara DBCC telah terjadi antara 19 September 2017 13:40 dan 4 Okt 2017 15:20. Ini tidak termasuk CHECKDB dan acara DBCC lainnya yang biasanya tidak berbahaya.

Prioritas 50: Kinerja :

  • Pertumbuhan File Lambat PROD77 - 2 pertumbuhan masing-masing memakan waktu lebih dari 15 detik. Pertimbangkan untuk menyetel autogrowth file menjadi lebih kecil.

Prioritas 50: Keandalan :

  • Verifikasi Halaman Tidak Optimal babtec_prod - Database [babtec_prod] memiliki TORN_PAGE_DETECTION untuk verifikasi halaman. SQL Server mungkin lebih sulit mengenali dan memulihkan dari korupsi penyimpanan. Pertimbangkan untuk menggunakan CHECKSUM sebagai gantinya.

Prioritas 100: Kinerja :

  • Banyak Paket untuk Satu Kueri - 3576 paket hadir untuk satu permintaan dalam cache paket - artinya kita mungkin memiliki masalah parameterisasi.

Prioritas 110: Kinerja :

  • Tabel Aktif Tanpa Indeks Clustered

    • babtec_prod - Basis data [babtec_prod] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

    • D3PR - Basis data [D3PR] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

    • DEMO77 - Basis data [DEMO77] memiliki banyak - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

    • FINP - Database [FINP] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

    • GridVis_EnMs - Database [GridVis_EnMs] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanya secara aktif.

    • PROD77 - Basis data [PROD77] memiliki tumpukan - tabel tanpa indeks berkerumun - yang sedang ditanyakan secara aktif.

Prioritas 150: Kinerja :

  • Kunci Asing Tidak Tepercaya

    • babtec_prod - Database [babtec_prod] memiliki kunci asing yang mungkin dinonaktifkan, data diubah, dan kemudian kunci diaktifkan lagi. Cukup mengaktifkan kunci tidak cukup bagi pengoptimal untuk menggunakan kunci ini - kita harus mengubah tabel menggunakan parameter WITH CHECK CHECK CONSTRAINT.

    • D3PR - Basis data [D3PR] memiliki kunci asing yang mungkin dinonaktifkan, data diubah, dan kemudian kunci diaktifkan kembali. Cukup mengaktifkan kunci tidak cukup bagi pengoptimal untuk menggunakan kunci ini - kita harus mengubah tabel menggunakan parameter WITH CHECK CHECK CONSTRAINT.

  • Tabel Tidak Aktif Tanpa Indeks Clustered

    • D3PR - Database [D3PR] memiliki tumpukan - tabel tanpa indeks berkerumun - yang belum ditanya sejak restart terakhir. Ini mungkin tabel cadangan yang ditinggalkan dengan sembarangan.

    • GridVis_EnMs - Basis data [GridVis_EnMs] memiliki tumpukan - tabel tanpa indeks berkerumun - yang belum di-query sejak restart terakhir. Ini mungkin tabel cadangan yang ditinggalkan dengan sembarangan.

  • Pemicu pada Tabel babtec_prod - Database [babtec_prod] memiliki 26 pemicu.

Prioritas 170: Konfigurasi File :

  • Database Sistem pada Drive C

    • master - Database master memiliki file pada drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

    • model - Database model memiliki file pada drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

    • msdb - Database msdb memiliki file di drive C. Menempatkan basis data sistem pada drive C berisiko menabrak server saat kehabisan ruang.

Prioritas 170: Keandalan :

  • Set Ukuran File Maks

    • D3PR - File database [D3PR] d3_data_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_data_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File database [D3PR] d3_firm_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_firm_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_log_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File database [D3PR] d3_phys_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_phys_idx_01 memiliki ukuran file maksimum yang diatur ke 61440MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_sys_01 memiliki ukuran file maksimum yang diatur ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_usr_01 memiliki ukuran file maksimum yang ditetapkan ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File basis data [D3PR] d3_wort_01 memiliki ukuran file maksimum yang diatur ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

    • D3PR - File database [D3PR] d3_wort_idx_01 memiliki ukuran file maksimal yang ditetapkan ke 20480MB. Jika kehabisan ruang, database akan berhenti berfungsi meskipun mungkin ada ruang drive yang tersedia.

Prioritas 200: Informasi :

  • Default Kompresi Cadangan Nonaktif - Cadangan lengkap yang tidak terkompresi telah terjadi baru-baru ini, dan kompresi cadangan tidak diaktifkan di tingkat server. Kompresi cadangan disertakan dengan SQL Server 2008R2 & yang lebih baru, bahkan dalam Edisi Standar. Kami menyarankan untuk mengaktifkan kompresi cadangan secara default sehingga cadangan ad-hoc akan terkompresi.

  • Collation adalah Latin1_General_CS_AS FINP - Perbedaan collation antara database pengguna dan tempdb dapat menyebabkan konflik terutama ketika membandingkan nilai string

  • Collation adalah SQL_Latin1_General_CP1_CI_AS - Perbedaan collation antara database pengguna dan tempdb dapat menyebabkan konflik terutama ketika membandingkan nilai string

    • DEMO77

    • PROD77

  • Server Tertaut Dikonfigurasi - BWIN2 \ INFOR dikonfigurasi sebagai server tertaut. Periksa konfigurasi keamanannya saat terhubung dengan sa, karena setiap pengguna yang menanyakannya akan mendapatkan izin tingkat admin.

Prioritas 200: Pemantauan :

  • Pekerjaan Agen Tanpa Email Gagal

    • Pekerjaan syspolicy_purge_history belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan upd_durchpreis_monatl belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan upd_fertmengen_woche belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan upd_liegezeit_monatl belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan upd_vertreter_diff belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan UPDATE_CONNECT_IK belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Cleanup belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.DBCC Periksa DB belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Index neu erstellen belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Statistiken aktualisieren belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Transactionlog Backup belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Vollbackup SystemDB belum diatur untuk memberi tahu operator jika gagal.

    • Pekerjaan Wartung.Vollbackup UserDB belum diatur untuk memberi tahu operator jika gagal.

  • Tidak Ada Peringatan untuk Korupsi - Peringatan SQL Server Agent tidak ada untuk kesalahan 823, 824, dan 825. Ketiga kesalahan ini dapat memberi Anda pemberitahuan tentang kegagalan perangkat keras awal. Mengaktifkannya dapat mencegah Anda patah hati.

  • Tidak Ada Peringatan untuk Sev 19-25 - Peringatan SQL Server Agent tidak ada untuk tingkat keparahan 19 hingga 25. Ini adalah beberapa kesalahan SQL Server yang sangat parah. Mengetahui bahwa ini terjadi dapat membuat Anda pulih dari kesalahan lebih cepat.

  • Not All Alerts Configured - Tidak semua peringatan SQL Server Agent telah dikonfigurasi. Ini adalah cara gratis dan mudah untuk mendapatkan pemberitahuan tentang korupsi, kegagalan pekerjaan, atau pemadaman besar bahkan sebelum sistem pemantauan mengambilnya.

Prioritas 200: Konfigurasi Server Non-Default :

  • Agent XPs - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

  • Database Mail XPs - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

  • bahasa teks lengkap default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 1033 dan telah ditetapkan ke 1031.

  • bahasa default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

  • filestream access level - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

  • derajat paralelisme maksimum - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 4.

  • max server memory (MB) - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 2147483647 dan telah ditetapkan ke 115000.

  • min server memory (MB) - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 10000.

  • koneksi admin jarak jauh - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah diatur ke 1.

Prioritas 200: Kinerja :

  • ambang biaya untuk paralelisme - Set ke 5, nilai standarnya. Mengubah pengaturan sp_configure ini dapat mengurangi waktu tunggu CXPACKET.

  • Snapshot Backups Terjadi - 9 backup yang terlihat snapshot telah terjadi dalam dua minggu terakhir, menunjukkan bahwa IO mungkin membeku.

Prioritas 210: Konfigurasi Basis Data Non-Default :

  • Baca Committed Snapshot Isolasi Diaktifkan - Pengaturan basis data ini bukan default.

    • D3PR

    • FINP

  • Pemicu Rekursif Diaktifkan - Pengaturan basis data ini bukan default.

    • DEMO77

    • PROD77

  • Snapshot Isolasi Diaktifkan FINP - Pengaturan basis data ini bukan default.

Prioritas 240: Tunggu Statistik :

  • 1 - ASYNC_NETWORK_IO - 225.9 jam menunggu, 143,5 menit waktu tunggu rata-rata per jam, menunggu sinyal 0,2%, tugas menunggu 2146022, waktu tunggu rata-rata 378,9 ms.

  • 2 - CXPACKET - 43.1 jam menunggu, 27,4 menit waktu tunggu rata-rata per jam, menunggu sinyal 1,5%, tugas menunggu 32608391, waktu tunggu rata-rata 4,8 ms.

Prioritas 250: Informasi :

  • SQL Server berjalan di bawah akun Layanan NT

    • Saya menjalankan NT Service \ MSSQL $ INFOR. Saya berharap saya memiliki akun layanan Direktori Aktif.

    • Saya menjalankan NT Service \ SQLAgent $ INFOR. Saya berharap saya memiliki akun layanan Direktori Aktif.

Prioritas 250: Info Server :

  • Isi Jejak Default - Jejak default menampung data 760 jam antara 3 September 2017 20:34 dan 5 Okt 2017 12:50 PM. File jejak default terletak di: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

  • Drive C Space - 21308.00MB gratis di drive C

  • Drive D Space - 280008.00MB gratis di D drive
  • Drive E Space - 281618.00MB gratis di drive E
  • Drive F Space - 60193.00MB gratis di drive F

  • Perangkat keras - Prosesor logis: 4. Memori fisik: 128GB.

  • Perangkat Keras - NUMA Konfigurasi - Node: 0 Negara: ONLINE Penjadwal online: 4 Penjadwal offline: 0 Grup Prosesor: 0 Node memori: 0 Memori VAS Cadangan GB: 281

  • Server Restart Terakhir - 1 Okt 2017 2:21 PM

  • Nama Server - BWINPDB \ INFOR

  • Jasa

    • Layanan: SQL Server (INFOR) berjalan di bawah akun layanan NT Service \ MSSQL $ INFOR. Waktu startup terakhir: 1 Okt 2017 2:22 PM. Jenis startup: Otomatis, Sedang Berjalan.

    • Layanan: SQL Server-Agent (INFOR) berjalan di bawah akun layanan NT Service \ SQLAgent $ INFOR. Waktu startup terakhir: tidak ditampilkan .. Jenis startup: Otomatis, saat ini Berjalan.

  • SQL Server Restart Terakhir - 1 Okt 2017 2:22 PM

  • Layanan SQL Server - Versi: 13.0.4001.0. Level Patch: SP1. Edisi: Edisi Standar (64-bit). Diaktifkan AlwaysOn: 0. Status AlwaysOn Mgr: 2

  • Server Virtual - Ketik: (HYPERVISOR)

  • Versi Windows - Anda menjalankan versi Windows yang cukup modern: Server 2012R2 era, versi 6.3

Prioritas 254: Rundate :

  • Log Kapten: menata sesuatu dan sesuatu ...

EDIT:

Saya sudah mempelajari panduan praktik terbaik tentang pengaturan sql server dengan vmware, dan kami telah mengatur sebagian besar sesuai dengan makalah ini. Padahal, hyperthreading tidak diaktifkan dan NUMA tidak aktif pada host vmware. SQL Server diatur ke NUMA.

EDIT:

Saya telah mengeluarkan RECONFIGURE setelah mengatur thresold untuk paralelisme ke 50, juga pengaturan MAXDOP saya tidak dikonfigurasi.

Saya juga memeriksa dengan admin vmware kami, sepertinya saya salah informasi. CPU kami disetel ke 2.6GHz, bukan 4.6 GHz. Saya sudah mengoreksi informasi di atas.

EDIT:

Kami mencoba mengatur beberapa jaringan yang terkait dengan vmwarekb dan panduan ini . Kami juga menambahkan 4 core lagi ke VM. Penggunaan CPU tetap sama.

masukkan deskripsi gambar di sini

masukkan deskripsi gambar di sini

masukkan deskripsi gambar di sini


Terima kasih atas info latar belakangnya. Mulailah dengan menjalankan sp_Blitz seperti yang dijelaskan di sini dan tempelkan ke pertanyaan Anda: brentozar.com/archive/2009/03/getting-help-with-a-slow-query
Brent Ozar

@BrentOzar, saya menambahkan hasil sp_blitz ke posting saya
Emptyslot

3
OK, berita buruk: jawabannya masih sama dengan yang terakhir Anda dapatkan. ASYNC_NETWORK_IO berarti bahwa SQL Server telah selesai memproses hasil kueri, dan menunggu di mesin di ujung lain pipa untuk mencerna hasilnya. Lihat jawaban aslinya: dba.stackexchange.com/a/186602/426
Brent Ozar

@Emptyslot, pastikan SQL Server di VMWare praktik terbaik diikuti: vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/… .
Dan Guzman

Bisakah Anda memeriksa apakah rencana daya diatur ke kinerja tinggi dan bukan default (seimbang). Saya telah melihat banyak masalah karena itu default.
Kin Shah

Jawaban:


18

Seperti yang dibahas terakhir kali Anda menanyakan pertanyaan ini , penantian teratas Anda adalah ASYNC_NETWORK_IO. SQL Server sedang duduk menunggu mesin di ujung pipa untuk mencerna baris berikutnya dari hasil permintaan.

Saya mendapat info ini dari menunggu statistik hasil sp_Blitz (terima kasih telah menempelkan itu di):

1 - ASYNC_NETWORK_IO - 225.9 jam menunggu, 143,5 menit waktu tunggu rata-rata per jam, menunggu sinyal 0,2%, tugas menunggu 2146022, waktu tunggu rata-rata 378,9 ms.

Jangan mematikan pemecahan masalah utas CPU - itu tidak terkait. Fokus pada tipe tunggu utama Anda dan hal-hal yang akan menyebabkan tipe tunggu itu.

Untuk memecahkan masalah ini lebih jauh, jalankan sp_WhoIsActive atau sp_BlitzFirst (penafian: Saya salah satu penulisnya) - keduanya akan mencantumkan kueri yang sedang berjalan saat ini. Lihat kolom info tunggu, cari pertanyaan yang menunggu ASYNC_NETWORK_IO, dan lihat aplikasi & server tempat mereka menjalankannya.

Dari sana, Anda dapat mencoba:

  • Memeriksa untuk melihat apakah server aplikasi itu kekurangan daya (seperti apakah mereka dimaksimalkan pada CPU, atau paging ke disk) dan tune mereka
  • Bekerja dengan pengembang aplikasi untuk melihat apakah mereka melakukan pemrosesan baris demi baris pada hasil (seperti untuk setiap baris yang kembali dari SQL Server, aplikasi berbunyi dan melakukan beberapa pemrosesan sebelum meminta baris hasil berikutnya)
  • Bekerja dengan pengembang aplikasi untuk memilih lebih sedikit data (seperti lebih sedikit baris atau lebih sedikit kolom jika mereka tidak membutuhkan semua data - kadang-kadang Anda melihat ini ketika orang-orang secara tidak sengaja melakukan SELECT * dan membawa kembali lebih banyak data dari yang mereka butuhkan, atau mereka meminta semua baris ketika mereka hanya benar-benar membutuhkan 1000 teratas)

Perbarui dengan sp_WhoIsActive - di tangkapan layar sp_WhoIsActive yang Anda poskan, Anda memiliki beberapa pertanyaan yang menunggu di ASYNC_NETWORK_IO. Untuk itu, lihat instruksi di atas.

Di sisa kueri, lihat kolom "status" sp_WhoIsActive - mayoritas dari mereka "tidur." Itu berarti mereka tidak berfungsi sama sekali - mereka sedang menunggu aplikasi di ujung lain pipa untuk mengirim perintah berikutnya. Mereka memiliki transaksi terbuka (lihat kolom "open_tran_count") tetapi tidak ada yang bisa dilakukan SQL Server untuk mempercepat transaksi yang tidak berjalan. Pertanyaan ini telah terbuka selama lebih dari empat puluh menit (kolom pertama di sp_WhoIsActive. Mereka tidak melakukan apa-apa lagi. Anda harus membuat orang-orang itu melakukan transaksi dan menutup koneksi mereka. Ini bukan masalah penyesuaian kinerja.

Semua yang kami lihat di sini mengarah ke skenario di mana kami menunggu di aplikasi.


Terima kasih atas jawaban anda Kami telah memeriksa server aplikasi, mereka tidak kekurangan tenaga. Kami sedang memeriksa poin Anda yang lain. Ada banyak pernyataan yang melakukan sesuatu seperti SELECT alias. * DARI tabel alias WHERE alias.clumn = nilai DAN CreateDate> = SomeDate. Yang tidak cantik, tetapi itu adalah Pernyataan SQL yang sama yang berjalan 'lancar' dengan versi terakhir dari sistem ERP kami (Infor COM 7.1) dan dengan oracle 9g. Mengapa berjalan lebih buruk dengan MS SQL Server dan Infor COM 7.1. Tidak ada pernyataan yang mendukung kami. Konsultan erp kami memeriksa semua yang saya kirim kepadanya.
Emptyslot

1
OK, Anda harus mulai dengan bagian bertanda "Untuk memecahkan masalah ini lebih lanjut" - itulah langkah selanjutnya. Saya tidak bisa membuatnya lebih jelas. Terima kasih!
Brent Ozar

1
Itu yang saya lakukan. Saya mengirimkan pertanyaan yang ditunjukkan dua prosedur kepada konsultan kami.
Emptyslot

@Emptyslot dengan baik, Anda tahu bagaimana ini, tidak bisa mempercayai konsultan tersebut. ;-)
Brent Ozar

5
@Emptyslot - ini akan menjadi yang terakhir kali saya balas kecuali Anda memasukkan hal-hal yang sudah saya minta tiga kali sekarang: jalankan sp_WhoIsActive atau sp_BlitzFirst (penafian: saya salah satu penulisnya) - keduanya akan mencantumkan kueri yang sedang berjalan saat ini. Itu juga akan mencakup koneksi SSMS Anda, dan menunjukkan apa yang menunggu. Tolong dimengerti bahwa saya menawarkan waktu saya di sini untuk membantu Anda, dan saya telah bersikap sopan, tetapi kesopanan berhenti di sini: LAKUKAN HAL YANG SAYA TELAH Minta Anda MELAKUKAN TIGA KALI.
Brent Ozar

2

Untuk menjawab pertanyaan saya sendiri. ASYNC_NETWORK_IO sebenarnya bukan masalah sebenarnya. Kami memperbaiki masalah kinerja kami dengan mengikuti panduan ini untuk beban kerja sensitif latensi:

Praktik Terbaik untuk Penyesuaian Kinerja Beban Kerja Sensitif-Latensi di vSphere VMs

Saya menandai pengaturan yang kami terapkan pada sistem kami dengan warna kuning di sini:

masukkan deskripsi gambar di sini

Saya pikir pengaturan dengan dampak paling besar adalah konfigurasi Numa dan pengaturan sensitivitas latensi ke tinggi . Yang keduanya diperlukan untuk kejelasan mengalokasikan / memesan core CPU fisik dan RAM untuk VM.

Kami juga menambahkan lebih banyak core ke VM dan sekarang perlu meningkatkan lisensi SQL Server kami dari Standard ke Enterprise.


1
Terima kasih telah membagikan detail jawaban Anda. Kami menjalankan SQL di Vsphere juga dan mungkin perlu meninjau opsi ini jika masalah terjadi. Harap pertahankan jawaban ini. Maaf seseorang telah membuat Anda marah. +1
Sting

Apakah tune ini hanya untuk SQL Server atau juga / hanya untuk aplikasi?
eckes

Kami juga menyetel server aplikasi dengan pengaturan itu. Kami juga mempertimbangkan untuk menyesuaikan desktop virtual kami dengan pengaturan latensi menjadi menengah / normal. Dugaan saya adalah bahwa ini akan menyelesaikan masalah kami tentang async_network_io
Emptyslot

1

Sepertinya Windows melaporkan kecepatan clock inti CPU Anda 4,6Ghz sebagai 2,6Ghz ... Saya akan menjalankan alat seperti CPU-Z untuk memeriksa berapa kecepatan mereka sebenarnya berjalan, dan kemudian melihat mengubah pengaturan daya di baik Windows maupun BIOS / OS Manajemen untuk menonaktifkan pengaturan penghematan daya apa pun yang mungkin memperlambat kecepatan inti.


Saya salah informasi, Core CPU berada pada 2,6 GHz sepanjang waktu. Tidak ada pengaturan hemat daya yang aktif, baik pada host maupun pada tamu.
Emptyslot

Saya akan melihat lebih dekat ke peringatan 'Tabel Aktif Tanpa Clustered Indeks'. Jika Anda memiliki tumpukan besar yang secara aktif ditanyai yang akan mematikan kinerja ...
Milney

Sayangnya hanya ada satu tabel yang tidak memiliki indeks Clustered. Ini memiliki dua kolom, salah satunya adalah NVARCHAR yang lain adalah dari datatype IMAGE. Sudah memiliki indeks unik nonclustered untuk kolom pertama, saya menambahkan indeks berkerumun juga. Tapi itu tidak banyak membantu.
Emptyslot
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.