|
Koneksi Pengguna SQLSERVER Statistik UmumKoneksi Pengguna dari instans SQL di penghitung performa sesuai dengannya Anda juga dapat merujuk ke TCPv4Connections Established di penghitung performa
Pada komputer yang hanya dengan layanan SQLSERVER,Koneksi TCPV4 Dibangun && Mssql UserConnectionsKedua parameter ini pada dasarnya disinkronkan dan disebut sebagai jumlah koneksi dalam konten pengujian berikut
Jumlah koneksi ini terbatas, mirip dengan jumlah maksimum batas konkurensi. Ketika batas ini tercapai, itu akan menyebabkan kueri menjadi tidak responsif meskipun ada sumber daya CPU, IO, dan MEM gratis (beberapa, tidak semua kueri terpengaruh)
Nilai maksimum TCPV4 Connections Established && Mssql UserConnections tergantung pada faktor-faktor berikut
a. Kompleksitas pernyataan eksekusi terkait, semakin kompleks pernyataannya, semakin kecil jumlah maksimum koneksi (efek ini sangat penting)
b. Ini terkait dengan konkurensi utas permintaan,
10 proses, setiap proses membuka 5.000 utas untuk diminta,PILIH getdate()Pernyataan tersebut sudah ditinggalkan ketika mencapai sekitar 4000 (pemahaman saya adalah bahwa meskipun banyak utas belum meminta sumber daya, jumlah permintaannya besar, yang juga berdampak).
10 proses, setiap proses membuka 1000 utas untuk diminta, PILIH getdate()Pernyataan bisa mencapai lebih dari 10.000.
c. Ini terkait dengan frekuensi permintaan utas
Jika setiap utas menjalankan kueri dan menjeda selama 0-10.000 milidetik, itu akan membutuhkan lebih sedikit koneksi daripada jika tidak ditangguhkan
d. Dalam pengujian, juga ditemukan bahwa beberapa sambungan yang tidak tertutup akan menyebabkan penghitung mengembang, yang tidak dibahas
10 proses, setiap proses membuka 1000 utas permintaan, jeda secara acak (0 hingga 10 detik) setelah setiap kueri di server Hasil pengujian adalah sebagai berikut:
Eksekusi:PILIH * DARI [sistem]. [dbo]. [DBA_alert]pernyataan (kueri ini mengembalikan 200 baris, dan jumlah maksimum koneksi adalah 700 dan masalah mulai dikeluarkan)
Ketika jumlah koneksi mencapai 700, beberapa kesalahan mulai dilaporkan, dan pada 1200, sejumlah besar kesalahan mulai muncul, dan jumlah koneksi sekitar 1800 macet dan tidak lagi meningkat. Kesalahan dan koneksi lamban berlimpah
Eksekusi:PILIH getdate()Waktu hukuman(Jumlah maksimum koneksi adalah 3500 dan masalah dimulai)
Ketika jumlah koneksi mencapai 3500, beberapa dari mereka mulai melaporkan kesalahan, dan tekanan tertinggi mencapai sekitar 11000, dan jumlah koneksi masih perlahan meningkat. Kesalahan dan ledakan koneksi yang lamban
Kesimpulannya adalah: dalam kondisi tekanan tertentu: yang paling sederhana untuk dilakukanJumlah maksimum koneksi dapat mencapai 3500 saat SELECT getdate(), dan jalankan SELECT * FROM [system]. [dbo]. [DBA_alert], jumlah maksimum koneksi hanya dapat hingga 700. Batas waktu kueri terjadi ketika CPU, IO, dan MEM semuanya memiliki sejumlah besar sumber daya yang menganggur.
Di lingkungan produksi, tekanan 10*1000 utas tidak dapat dicapai, tetapi SQL akan lebih kompleks daripada lingkungan pengujian.
Nomor bersamaanKemacetan tidak disebabkan oleh bandwidth komputer atau kartu jaringan server saya
Untuk membuktikan hal di atas. Saya melakukan pengujian berikut, exec dbo.run2 dalam kasus konkurensi besar;
ALTER proc [dbo]. [berjalan2]
sebagai
Atur Nocount pada
Pilih getdate()
Deklarasikan @i int
atur @i=0
sedangkan @i<1000 Ketika nilai ini adalah 1000, jumlah maksimum koneksi adalah sekitar 1300, dan ketika nilai ini adalah 10, normal untuk mencapai 5000.
mulai
MASUKKAN KE DALAM [PUB]. [dbo]. [tb_test] ([nama]) nilai (newid())
atur @i=@i+1
akhir
pergi
Jumlah siklus perubahan tidak akan mempengaruhi hasil pengembalian, yaitu tekanan pada lalu lintas kartu jaringan sama, tetapi yang satu akan habis dengan cepat dan yang lainnya selalu dapat diperiksa, sehingga dampak bandwidth kartu jaringan di kedua sisi dapat dihilangkan.
Konten kesalahan saat jumlah maksimum koneksi terhenti:
netstat-hasil ketika jumlah koneksi maksimum macet (sangat ditetapkan):
Uji diagram berjalan program saat jumlah maksimum koneksi terhenti:
Perlu dicatat:Hubungan dengan kesalahan atau batas waktu tidak rata, dan akan terkonsentrasi dalam beberapa proses, artinya, beberapa proses selalu dapat berjalan normal, dan bagian lainnya akan melaporkan kesalahan untuk waktu yang lama (tidak ada hubungannya dengan urutan mulai proses, pemahaman saya adalah bahwa beberapa proses memiliki sumber daya, dapat terus bekerja secara normal, sementara proses lain di utas di sumber daya asli didahulukan dan tidak dapat mengajukan sumber daya baru, akan terus berulang kali melaporkan kesalahan) Seperti yang ditunjukkan pada gambar di atas, proses ke-2 dan ke-7 mulai memiliki banyak batas waktu, dan proses lain terus bekerja. Di server, kueri mungkin tampak tidak terpengaruh atau kurang terpengaruh oleh beberapa mesin, dan beberapa komputer terpengaruh secara signifikan.
Kesimpulan: Meskipun batas atas Koneksi Pengguna SQLSERVER terkait dengan serangkaian kondisi, masih dimungkinkan untuk memperkirakan dan memprediksi kemacetan, ketika batas atas ini tercapai, akan ada sejumlah besar kueri yang lambat dan batas waktu (meskipun CPU, IO. MEM, lalu lintas juga dapat terjadi ketika ada sumber daya yang menganggur). Faktanya, mengubah beberapa parameter TCP akan meningkatkan batas atas ini, dan saya mungkin menulis suplemen nanti
|
Diposting pada 26/11/2014 15.11.08
|
|
|
|
