Masalah kinerja yang aneh dengan SQL Server 2016

Kami memiliki satu contoh SQL Server 2016 SP1 yang berjalan di mesin virtual VMware. Ini berisi 4 database, masing-masing untuk aplikasi yang berbeda. Semua aplikasi itu ada di server virtual terpisah. Belum ada satu pun dari mereka yang menggunakan produksi. Orang-orang yang menguji aplikasi melaporkan masalah kinerja.

Ini adalah statistik server:

• 128 GB RAM (memori 110GB Maks untuk SQL Server)
• 4 Cores @ 4,6 GHz
• Koneksi jaringan 10 GBit
• Semua penyimpanan berbasis SSD
• File program, file Log, file database dan tempdb berada di partisi server yang terpisah
• asd

Pengguna melakukan akses layar tunggal melalui aplikasi ERP berbasis C ++.

Ketika saya stres menguji SQL Server dengan Microsoft ostressmenggunakan banyak pertanyaan kecil atau permintaan besar, saya mendapatkan kinerja maksimal. Satu-satunya hal pelambatan adalah klien, karena dia tidak bisa menjawab cukup cepat.

Tetapi ketika hampir tidak ada pengguna, SQL Server nyaris tidak melakukan apa-apa. Namun orang harus menunggu selamanya hanya untuk menyimpan apa pun dalam aplikasi.

Menurut kueri " Ceritakan di mana sakitnya " Paul Randal , 50% dari semua acara menunggu adalah ASYNC_NETWORK_IO.

Ini bisa berarti masalah jaringan, atau masalah kinerja dengan server aplikasi atau klien. Tak satu pun dari mereka bahkan menggunakan sumber daya mereka pada kapasitas maksimum. Sebagian besar waktu CPU adalah sekitar 26% di semua mesin (Klien, appserver, server db).

Latensi koneksi jaringan sekitar 1-3ms. IO server db berada pada kecepatan tulis maks 20MB / s selama penggunaan normal dengan aplikasi (rata-rata 7-9MB / s). Ketika saya stress test, saya mendapatkan maks 5GB / s.

Ukuran cache penyangga adalah 60GB untuk DB sistem ERP kami, 20GB untuk perangkat lunak pembiayaan kami, 1GB untuk perangkat lunak jaminan kualitas, 3GB untuk sistem pengarsipan dokumen.

Saya memberi akun SQL Server hak untuk menggunakan Inisialisasi File Instan . Itu tidak meningkatkan kinerja sedikit pun.

Harapan hidup halaman sekitar 15k + selama penggunaan normal. Turun menjadi sekitar 0,05 ribu selama akhir pengujian stres berat, yang diharapkan. Batch / detik sekitar 2-8k, tergantung pada beban kerja.

Saya akan mengatakan aplikasi ERP ditulis dengan buruk, tetapi saya tidak bisa karena semua aplikasi terpengaruh. Bahkan dengan beban kerja minimal.

Namun saya tidak bisa menunjukkan dengan tepat apa yang menyebabkan ini. Apakah ada tips, petunjuk tutorial, aplikasi, dokumen praktik terbaik / terburuk atau hal lain yang ada dalam pikiran Anda tentang masalah ini?

Ini adalah hasil dari sp_BlitzFirst:

Saya menjalankannya 600 detik. Saya memulainya selama beban kerja aplikasi yang tinggi. 1/3 dari waktu itu ASYNC_NETWORK_IO. Saya juga menguji koneksi jaringan dengan NTttcp, PsPing, ipferf3, dan pathping. Tidak ada yang aneh. Waktu respons maksimal 3ms, rata-rata 0.3ms. Throughput sekitar 1000 MB / s.

Investigasi saya selalu menghasilkan ASYNC_NETWORK_IOmenjadi waitstat nomor satu.

Kami menyelidiki hasil menonaktifkan Large-Receive-Offload fitur di VMware. Kami masih menguji, tetapi hasilnya tampaknya tidak konsisten. 'Benchmark' pertama kami menghasilkan durasi 19 menit (hasil teratas adalah 13 menit yang hanya tercapai ketika aplikasi berjalan pada VM dengan SQL Server itu sendiri). Hasil kedua adalah 28 menit, yang sangat buruk.

Hasil pertama dari 'tolok ukur' kami adalah 19 menit. Yang mana yang bagus. Karena hasil teratas adalah 13 menit (yang hanya dapat dicapai ketika aplikasi melakukan benchmark pada VM dengan SQL Server itu sendiri). Ini sangat mengisyaratkan beberapa masalah terkait jaringan. Atau masalah dengan konfigurasi VMware.

Saat ini saya tersesat pada metode apa yang harus digunakan, untuk memakukannya ke bottleneck.

Kinerja maksimum dengan aplikasi hanya dapat dicapai ketika aplikasi berjalan pada VM dengan SQL Server itu sendiri. Jika aplikasi dijalankan pada VM atau desktop virtual apa pun, durasi tolok ukur kami akan berlipat tiga (dari durasi 13 menit menjadi 40 menit atau lebih). Semua titik akhir (VM SQL Server, VM server aplikasi dan Virtual Desktop) menggunakan perangkat keras fisik yang sama. Kami telah memindahkan semua titik akhir lainnya ke perangkat keras lain.

EDIT: Sepertinya Masalahnya kembali. Setelah mengatur mode penghematan energi dari seimbang ke kinerja tinggi, kami benar-benar meningkatkan waktu respons secara dramatis. Tapi hari ini saya menjalankan sp_BlitzFirst lagi, dengan sampel 300 detik. Ini hasilnya:

Ini menunjukkan lebih banyak waktu tunggu untuk ASYNC_NETWORK_IO daripada detik sp_blitzfirst berlari.

Jika menunggu utama Anda ASYNC_NETWORK_IO, maka masalahnya bukan pada SQL Server. Itu hampir selalu karena hambatan aplikasi. Saya tidak bermaksud bottleneck pada server aplikasi, tetapi lebih pada bottleneck dalam aplikasi.

Hambatan aplikasi biasanya karena pemrosesan baris demi baris saat SQL Server mengirim data:

• Aplikasi ini meminta data dari SQL Server
• SQL Server mengirim data dengan cepat
• Aplikasi memberi tahu SQL Server untuk menunggu saat memproses setiap baris
• SQL Server mencatat waktu tunggu saat ASYNC_NETWORK_IOaplikasi meminta untuk menunggu

Alih-alih itu, aplikasi perlu mengkonsumsi semua data dari SQL Server dan MAKA melakukan pemrosesan baris-demi-baris. SQL Server keluar dari gambar pada saat itu.

sp_BlitzFirst keluaran

The LCK_M_Smenunggu tidak tinggi. Hanya 2 detik dari sampel 30 detik yang ada di sana, dan rata-rata hanya 400 ms. Itu sangat, sangat tidak mungkin menjadi masalah. ASYNC_NETWORK_IOadalah penantian utama Anda dalam sampel itu. Masih masalah aplikasi. Jika Anda ingin bantuan dengan LCKbarang - barang itu, kami perlu melihat pertanyaan yang terlibat.

Bahkan ASYNC_NETWORK_IOtidak terlalu buruk dalam sampel itu. Mata saya menjadi besar ketika waktu tunggu sama atau lebih besar dari ukuran sampel. Saat itulah saya menggali.

Seluruh masalah Anda adalah ASYNC_NETWORK_IO. Ini bukan masalah SQL Server. Ini masalah dengan aplikasi (melakukan pemrosesan baris-demi-baris saat SQL Server mengirim data), server aplikasi (Anda sudah mengatakan itu baik-baik saja) atau jaringan (Anda telah mengatakan bahwa jaringan baik-baik saja). Jadi masalahnya ada pada aplikasi. Aplikasi C ++ perlu diperbaiki.

Untuk menjawab pertanyaan saya sendiri: Alasan utama ASYNC_NETWORK_IO muncul di SQL Server kami sebagai jenis tunggu teratas, adalah karena energy savingpengaturan server windows ditetapkan 'balanced'sebagai ganti 'high performance'. Kami berbicara dengan beberapa admin vm ware setelahnya, dan mereka semua berkata, bahwa pengaturan ini akan membunuh kinerja .

Solusi untuk ini adalah:

• Jangan memasang kontrol energi saat memasang windows server
• Atur mode hemat energi ke kinerja tinggi untuk semua server melalui kebijakan grup

Semua masalah / statistik lain tentang ASYNC_NETWORK_IO terkait dengan aplikasi ERP kami yang ditulis dengan buruk. Terima kasih kepada semua yang telah membantu saya menyelesaikan masalah ini, komentar, saran dan saran Anda sangat disambut dan membantu!