Jumlah maksimum koneksi pengguna

24

Dalam SQL Server 2012 edisi standar, saya tahu bahwa jumlah maksimum koneksi pengguna adalah 32.767. Apa yang harus saya lakukan sebagai DBA jika saya menuju ke nomor ini?

Saat ini ada 30.000 koneksi pengguna, dan jumlah ini diperkirakan akan meningkat.

sql-server sql-server-2012 connections

— sebeid
sumber

5

Jika ini dari suatu aplikasi, maka aplikasi harus menutup koneksinya setelah selesai. Membiarkan koneksi terbuka adalah alasan yang memungkinkan untuk mencapai batas ini

— Mark Sinkinson

31

Jumlah maksimum koneksi di versi dan edisi SQL Server adalah 32.767.

Anda dapat menentukan berapa banyak koneksi yang dimiliki SQL Server saat ini dengan melihat:

SELECT ConnectionStatus = CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END
    , CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , ConnectionCount = COUNT(1)
FROM sys.dm_exec_connections dec
    INNER JOIN sys.dm_exec_sessions des ON dec.session_id = des.session_id
GROUP BY CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END;

Jika rasio antara koneksi yang digunakan dan yang tidak terpakai dari kueri di atas memprihatinkan, kemungkinan pooling koneksi diaktifkan oleh aplikasi klien yang terhubung ke server, dan koneksi tersebut tidak digunakan secara efisien. Anda mungkin ingin meminta pengembang memodifikasi string koneksi untuk aplikasi ini untuk membatasi ukuran kumpulan koneksi, dan memastikan mereka membuang koneksi dengan benar. Jika koneksi tidak dibuang dengan benar, mereka akan tetap terbuka selama aplikasi klien berjalan.

Jika Anda merasa sangat gila, dan perlu menyingkirkan semua koneksi yang belum melakukan apa-apa baru-baru ini (terlepas dari apakah mereka benar-benar sedang melakukan pekerjaan), Anda dapat menjalankan kode berikut, yang akan menghasilkan daftar sesi yang bisa terbunuh. Anda harus menyalin dan menempelkan perintah yang dihasilkan ke jendela SSMS baru untuk benar-benar menjalankan perintah. Saya juga merekomendasikan agar resume Anda diperbarui untuk berjaga-jaga .

DECLARE @cmd NVARCHAR(MAX);
SET @cmd = '';
SELECT @cmd = @cmd + 
    CASE WHEN @cmd = '' THEN '' ELSE CHAR(13) + CHAR(10) END 
    + 'KILL ' + CONVERT(VARCHAR(MAX), dec.session_id) + ';'
FROM sys.dm_exec_connections dec
WHERE dec.most_recent_sql_handle = 0x0;


PRINT @cmd;

Dimungkinkan untuk secara linear skala jumlah koneksi di luar 32.767 dengan membagikan data di beberapa node SQL Server. Namun, menurut saya, menggunakan sharding sebagai cara untuk mencapai batas jumlah koneksi sama dengan menggunakan bom atom untuk membunuh seekor laba-laba. Ini akan membunuh laba-laba, tetapi Anda mungkin memiliki masalah yang lebih besar di akhir hari. Belum lagi sangat sulit untuk membangun bom atom, belum lagi mengimplementasikan sharding dengan benar.

— Max Vernon
sumber

1

Bisakah Anda jelaskan mengapa kami harus mengidentifikasi sesi "dapat dibunuh " dengan menggunakan most_recent_sql_handle di koneksi sys.dm_exec_ daripada menggunakan, katakanlah, status dan last_request_start_time dan proses is_user_ dalam sesi sys.dm_exec_ ? Sepertinya pilihan yang aneh.

— Mike Sherrill 'Cat Recall'

Itu poin yang bagus, @Mike - Saat itu saya sedang berpikir murni tentang koneksi yang telah dibuka oleh koneksi pooling dan yang belum pernah digunakan. Ini akan menjadi ide yang baik untuk menambahkan is_user_processkualifikasi, dan tentu saja tidak ada salahnya untuk mengecualikan sesi yang memiliki last_request_start_timeyang agak baru. Bagaimana baru-baru ini? Pertanyaan bagus lainnya.

— Max Vernon

Last_request_start_time mungkin harus lebih tua daripada yang lebih baru. Saya pikir sesi pengguna yang "dapat dibunuh" dengan aman adalah sesi yang tidur dan belum memiliki permintaan selama beberapa hari. Saya kira waktu cutoff tergantung pada seberapa baik programmer aplikasi kami membersihkan diri mereka sendiri.

— Mike Sherrill 'Cat Recall'

12

Saya telah mengalami perilaku aneh dengan koneksi pool di masa lalu, dan skenario Anda selaras dengan salah satu situasi tersebut. Jika aplikasi Anda menggunakan kumpulan koneksi (dan itu masih spekulasi, pada titik ini, sampai Anda mengonfirmasi atau menyangkal hal itu) maka Anda akan memiliki banyak koneksi yang tetap terbuka. Ini dengan desain.

Koneksi pooling bertujuan untuk mengurangi overhead menciptakan koneksi database. Mari kita ambil, misalnya, kumpulan koneksi 3. Sejauh yang saya tahu siklus hidup seperti ini (dimulai dari cache pool koneksi dingin):

Pengguna aplikasi A meminta koneksi ke database
Kolam koneksi memulai utas koneksi 1 ke basis data
Pengguna aplikasi B meminta koneksi ke database
Kolam koneksi memulai utas koneksi 2 ke basis data
Pengguna aplikasi A menutup koneksi mereka ... ke kumpulan koneksi
Pengguna aplikasi C meminta koneksi ke database
Masalah koneksi kolam sp_reset_connectiondi utas 1
Kolam koneksi memberikan thread 1 ke pengguna Aplikasi C

Ini adalah penyederhanaan yang berlebihan, tetapi poin-poin penting termasuk:

Koneksi akan tetap terbuka antara pool thread koneksi pool dan database sampai database atau pool koneksi secara paksa menutup koneksi
Sambungan tetap terbuka dengan konteks eksekusi sesi terakhir hingga utas tersebut digunakan kembali oleh pengguna lain, yang pada saat sp_reset_connectionitu disebut waktu .

Inilah bahan referensi yang saya gunakan untuk sampai pada kesimpulan ini.

Pooling koneksi untuk SQL Server DBA

Kasus transaksi yatim

— swasheck
sumber