Konsumsi "Total Server Memory" SQL Server stagnan selama berbulan-bulan dengan 64GB + lebih banyak tersedia

Saya telah mengalami masalah aneh di mana SQL Server 2016 Edisi Standar 64-bit tampaknya telah membatasi dirinya tepat pada setengah dari total memori yang dialokasikan untuk itu (64GB 128GB).

Output dari @@VERSIONadalah:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 Desember 2017 11:25:00 Hak Cipta (c) Edisi Standar Microsoft Corporation (64-bit) pada Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hypervisor)

Output dari sys.dm_os_process_memoryadalah:

Ketika saya bertanya sys.dm_os_performance_counters, saya melihat bahwa Target Server Memory (KB)at at 131072000dan Total Server Memory (KB)di bawah setengah dari at at 65308016. Dalam sebagian besar skenario, saya akan memahami hal ini sebagai perilaku normal karena SQL Server belum menentukan bahwa ia perlu mengalokasikan memori lebih lanjut untuk dirinya sendiri.

Namun, telah "macet" pada ~ 64GB selama lebih dari 2 bulan sekarang. Selama jangka waktu ini, kami telah melakukan sejumlah besar operasi memori-intensif pada beberapa database, dan telah menambahkan hampir 40 database lebih banyak ke instance. Kami memiliki total 292 basis data, masing-masing dengan file data pra-alokasi pada 4GB dengan laju autogrowth 256MB dan file log 2GB dengan laju autogrowth 128MB. Saya melakukan pencadangan penuh sekali malam pada pukul 12:00 pagi, dan mulai pencadangan log transaksi Senin hingga Jumat mulai pukul 06:00 hingga 20:00 pada interval setiap 15 menit. Database ini relatif rendah pada keseluruhan throughput mereka, tapi saya ragu ada sesuatu yang salah mengingat SQL Server belum merangkak ke atasTarget Server Memory secara alami melalui penambahan basis data baru, eksekusi permintaan normal, serta pipa ETL intensif-memori yang telah dijalankan.

Contoh SQL Server itu sendiri duduk di atas server Windows Server 2012R2 tervirtualisasi dengan 12 CPU, memori 144GB (128GB ke SQL Server, 16GB dicadangkan untuk Windows), dan 4 total disk virtual yang berada di atas vSAN dengan drive 15K SAS . Windows duduk secara alami pada disk 64GB C: dengan file halaman 32GB. File data duduk di disk 2TB D:, file log berada di atas disk 2TB L: disk, dan tempdb duduk di disk T: 256GB: dengan file 8x16GB tanpa autogrowth.

Saya telah memverifikasi bahwa tidak ada contoh lain dari SQL Server yang berjalan di server selain itu MSSQLSERVER.

Server ini sepenuhnya didedikasikan hanya untuk instance SQL Server, jadi kami tidak memiliki aplikasi atau layanan lain yang menjalankannya yang mungkin menggunakan memori.

Saya menggunakan RedGate SQL Monitor untuk analisis, dan di bawah ini adalah sejarah selama 18 hari terakhir Total Server Memory. Seperti yang Anda lihat, pemanfaatan memori tetap stagnan selain dari satu uptick ~ 300MB pada awal April.

Apa yang mungkin menjadi penyebab hal ini? Apa yang bisa saya lihat lebih dekat untuk menentukan mengapa SQL Server tidak ingin menggunakan memori 64GB + tambahan yang dialokasikan untuk itu?

Output dari menjalankan sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Prioritas 50: Kinerja :

• Penjadwal CPU Offline - Beberapa core CPU tidak dapat diakses oleh SQL Server karena masalah afinitas atau lisensi.

• Memory Nodes Offline - Karena masalah affinity masking atau lisensi, beberapa memori mungkin tidak tersedia.

Prioritas 50: Keandalan :

• Remote DAC Dinonaktifkan - Akses jarak jauh ke Dedicated Admin Connection (DAC) tidak diaktifkan. DAC dapat membuat pemecahan masalah jarak jauh lebih mudah ketika SQL Server tidak responsif.

Prioritas 100: Kinerja :

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

• Pemicu Server Diaktifkan

  • Server Trigger [RG_SQLLighthouse_DDLTrigger] diaktifkan. Pastikan Anda memahami apa yang dilakukan pemicu itu - semakin sedikit kerjanya, semakin baik.

  • Server Trigger [SSMSRemoteBlock] diaktifkan. Pastikan Anda memahami apa yang dilakukan pemicu itu - semakin sedikit kerjanya, semakin baik.

Prioritas 150: Kinerja :

• Query Forcing Join Hints - 1480 instance dari hinting join telah direkam sejak dimulai ulang. Ini berarti bahwa kueri sedang memimpin pengoptimal SQL Server, dan jika mereka tidak tahu apa yang mereka lakukan, ini dapat menyebabkan lebih banyak ruginya daripada kebaikan. Ini juga dapat menjelaskan mengapa upaya penyetelan DBA tidak berhasil.

• Petunjuk Meminta Petunjuk Pemesanan - 2153 contoh petunjuk pemesanan telah direkam sejak dimulai ulang. Ini berarti bahwa kueri sedang memimpin pengoptimal SQL Server, dan jika mereka tidak tahu apa yang mereka lakukan, ini dapat menyebabkan lebih banyak ruginya daripada kebaikan. Ini juga dapat menjelaskan mengapa upaya penyetelan DBA tidak berhasil.

Prioritas 170: Konfigurasi File :

• Database Sistem pada Drive C

  • master - Database master memiliki file di 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 200: Informasi :

• Pekerjaan Agen Memulai Secara Bersamaan - Beberapa pekerjaan Agen SQL Server dikonfigurasikan untuk memulai secara bersamaan. Untuk daftar jadwal terperinci, lihat kueri di URL.

• Tabel di master Database Master - Tabel CommandLog di database master dibuat oleh pengguna akhir pada 30 Juli 2017 17:22. Tabel dalam database master mungkin tidak dapat dipulihkan jika terjadi bencana.

• TraceFlag Aktif

  • Bendera jejak 1118 diaktifkan secara global.

  • Bendera jejak 1222 diaktifkan secara global.

  • Bendera jejak 2371 diaktifkan secara global.

Prioritas 200: Konfigurasi Server Non-Default :

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

• backup checksum default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah ditetapkan ke 1.

• backup compression default - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah ditetapkan ke 1.

• ambang biaya untuk paralelisme - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 5 dan telah diatur ke 48.

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

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

• optimalkan untuk beban kerja ad hoc - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah ditetapkan ke 1.

• tampilkan opsi lanjutan - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah ditetapkan ke 1.

• xp_cmdshell - Opsi sp_configure ini telah diubah. Nilai standarnya adalah 0 dan telah ditetapkan ke 1.

Prioritas 200: Keandalan :

• Prosedur Tersimpan Lebih Lanjut dalam Master

• master - Prosedur tersimpan tersimpan [sqbdata] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur tersimpan tersimpan [sqbdir] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur penyimpanan tersimpan [sqbmemory] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur penyimpanan tersimpan [sqbstatus] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur penyimpanan tersimpan [sqbtest] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur tersimpan tersimpan [sqbtestcancel] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur penyimpanan tersimpan [sqbteststatus] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur penyimpanan tersimpan [sqbutility] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

  • master - Prosedur tersimpan tersimpan [sqlbackup] ada di database master. CLR mungkin sedang digunakan, dan database master sekarang harus menjadi bagian dari perencanaan cadangan / pemulihan Anda.

Prioritas 210: Konfigurasi Basis Data Non-Default :

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

  • RedGate

  • RedGateMonitor

• Isolasi Snapshot Diaktifkan - Pengaturan database ini bukan default.

  • RedGate

  • RedGateMonitor

Prioritas 240: Tunggu Statistik :

• 1 - SOS_SCHEDULER_YIELD - menunggu 1770,8 jam, waktu tunggu rata-rata 115,9 menit per jam, menunggu sinyal 100,0%, tugas menunggu 1419212079, waktu tunggu rata-rata 4,5 ms.

Prioritas 250: Informasi :

• SQL Server berjalan di bawah akun Layanan NT - Saya menjalankan sebagai Layanan NT \ MSSQLSERVER. Saya berharap saya memiliki akun layanan Direktori Aktif.

Prioritas 250: Info Server :

• Default Trace Contents - Jejak default menampung data 36 jam antara 14 April 2018 11:21 PM dan 16 April 2018 11:13 AM. File jejak default terletak di: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Drive C Space - 196816.00MB gratis di drive C

• Drive D Space - 894823.00MB gratis di drive E

• Drive L Space - 1361367.00MB gratis di drive F

• Drive T Space - 114441.00MB gratis di drive G

• Perangkat keras - Prosesor logis: 12. Memori fisik: 144GB.

• Perangkat Keras - NUMA Config

  • Node: 0 Negara: ONLINE Penjadwal online: 4 Penjadwal offline: 2 Grup Prosesor: 0 Node memori: 0 Memori VAS Cadangan GB: 186

  • Node: 1 Negara: OFFLINE Penjadwal online: 0 Penjadwal offline: 6 Grup Prosesor: 0 Node memori: 0 Memori VAS Cadangan GB: 186

• Inisialisasi File Instan Diaktifkan - Akun layanan memiliki izin Perform Volume Maintenance Tasks.

• Power Plan - Server Anda memiliki 2.60GHz CPU, dan dalam mode daya seimbang - Uh ... Anda ingin CPU Anda berjalan dengan kecepatan penuh, bukan?

• Server Restart Terakhir - 9 Mar 2018 7:27 AM

• Nama Server - [dihapus]

• Jasa

  • Layanan: SQL Server (MSSQLSERVER) berjalan di bawah akun layanan NT Service \ MSSQLSERVER. Waktu startup terakhir: 9 Maret 2018 7:27. Jenis startup: Otomatis, Sedang Berjalan.

  • Layanan: SQL Server Agent (MSSQLSERVER) berjalan di bawah akun layanan LocalSystem. Waktu startup terakhir: tidak ditampilkan .. Jenis startup: Otomatis, saat ini Berjalan.

• SQL Server Restart Terakhir - 9 Mar 2018 6:27 AM

• Layanan SQL Server - Versi: 13.0.4466.4. Level Patch: SP1. Pembaruan Kumulatif: CU7. Edisi: Edisi Standar (64-bit). Grup Ketersediaan Diaktifkan: 0. Grup Ketersediaan Status Manajer: 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 ...

Saya yakin Anda telah mengkonfigurasi CPU virtual dengan cara bahwa beberapa node CPU dan / atau node memori sedang offline.

Unduh sp_Blitz (penafian: Saya salah satu penulis skrip open source gratis) dan jalankan:

sp_Blitz @CheckServerInfo = 1;

Cari peringatan tentang CPU dan / atau node memori sedang offline. SQL Server Standard Edition hanya melihat 4 soket CPU pertama, dan Anda mungkin telah mengkonfigurasi VM sebagai sesuatu seperti 6 CPU dual-core. Ini akan berakhir dengan masalah yang mirip dengan bagaimana 20-core-batas Enterprise Edition membatasi jumlah memori yang dapat Anda lihat .

Jika Anda ingin membagikan output sp_Blitz di sini, Anda dapat menjalankannya seperti ini untuk menampilkan ke Penurunan harga, yang kemudian dapat Anda salin / tempel ke pertanyaan Anda:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Pembaruan 2018/04/16 - dikonfirmasi. Anda memasang output sp_Blitz (terima kasih untuk itu!) Dan itu memang menunjukkan bahwa Anda memiliki CPU dan node memori offline. Siapa pun yang membangun VM mengkonfigurasinya sebagai 12 CPU single-core, sehingga SQL Server Standard Edition hanya melihat 4 soket (core) pertama, dan memori terpasang padanya.

Untuk memperbaikinya, matikan VM, konfigurasikan sebagai 2-socket, 6-core VM, dan kemudian SQL Server Standard Edition akan melihat semua core dan memori. Ini juga akan mengurangi menunggu SOS_SCHEDULER_YIELD Anda - saat ini, SQL Server Anda memalu 4 core pertama, tetapi hanya itu. Setelah perbaikan ini, ini akan dapat bekerja pada semua 12 core.

Sebagai tambahan untuk rencana tindakan Brent Ozar , saya ingin membagikan hasilnya. Seperti yang dicatat Brent, dalam VMware kami telah mengkonfigurasi Mesin Virtual dengan tidak benar dengan 12 CPU single-core. Ini mengakibatkan 8 core yang tersisa tidak dapat diakses oleh SQL Server, dan sebagai hasilnya, menyebabkan masalah memori yang dijelaskan dalam pertanyaan awal saya. Kami menempatkan layanan kami dalam mode pemeliharaan semalam untuk mengkonfigurasi ulang VM dengan tepat. Kita tidak hanya melihat memori merangkak naik secara normal, tetapi seperti Brent juga mengisyaratkan, jumlah menunggu turun secara eksponensial dan kinerja SQL Server kami secara keseluruhan meroket. Konfigurasi vNUMA sekarang adalah komponen-komponen kecil yang senang mengiris beban kerja kami.

Bagi mereka yang mungkin menggunakan VMware vSphere 6.5, langkah-langkah singkat untuk menyelesaikan item tindakan yang dijelaskan oleh Brent adalah sebagai berikut.

1. Masuk ke vSphere Web Client untuk kluster VMware Anda, dan browse ke Mesin Virtual yang menghosting SQL Server. VM Anda harus offline untuk menyesuaikan konfigurasi CPU dan memori.

2. Di dalam panel utama, pergi ke Configure > VM hardware, klik Edittombol di sudut kanan atas. Anda akan membuka menu konteks yang ada Edit Settings. Sebagai referensi, gambar di bawah ini adalah konfigurasi yang salah . Perhatikan bahwa saya telah Cores per Socketmengatur untuk 1. Mengingat keterbatasan SQL Server Standard Edition, ini adalah konfigurasi yang buruk.

   

3. Cara mengatasinya sesederhana menyesuaikan Cores per Socketnilai. Dalam kasus kami, kami mengaturnya 6agar kami miliki 2 Sockets. Ini memungkinkan SQL Server untuk menggunakan semua 12 prosesor.

   

Catatan penting: Jangan setel nilai ke tempat salah satu Number of Coresatau Socketsnomor ganjil. NUMA mencintai keseimbangan, dan berdasarkan aturan praktis, perlu dibagi 2. Misalnya, konfigurasi 4 core hingga 3 soket akan tidak seimbang. Bahkan, jika Anda menjalankan sp_Blitzdengan jenis konfigurasi ini, itu akan melemparkan peringatan tentang ini.

Bagian 3.3 dalam Merancang Microsoft SQL Server pada VMware vSphere (peringatan PDF) menguraikan ini secara rinci. Praktik yang diuraikan dalam whitepaper berlaku untuk sebagian besar semua virtualisasi on-premise dari SQL Server.

Berikut adalah beberapa sumber daya yang telah saya kumpulkan melalui penelitian saya setelah posting Brent:

• Virtualisasi basis data besar - perencanaan kapasitas CPU VMware

• Mesin Virtual vCPU dan vNUMA Rightsizing - Rules of Thumb

• Decoupling of Cores per Socket dari Topologi NUMA Virtual di vSphere 6.5

Saya akan mengakhiri penangkapan dari RedGate SQL Monitor selama 24 jam terakhir. Poin utama yang perlu diperhatikan adalah pemanfaatan CPU dan jumlah menunggu - selama jam sibuk kami kemarin, kami mengalami penggunaan CPU yang berat dan menunggu pertengkaran. Setelah perbaikan sederhana ini, kami telah meningkatkan kinerja kami sepuluh kali lipat. Bahkan disk I / O kami telah berkurang secara signifikan. Ini adalah pengaturan yang tampaknya mudah diabaikan yang dapat meningkatkan kinerja virtual dengan urutan besarnya. Setidaknya, itu diabaikan oleh para insinyur kami dan momen d'oh lengkap .

Juga, menurut MSDN , standar SQL Server terbatas pada 64GB RAM. Kami 'memecahkan' ini dengan memecah database menjadi beberapa contoh, tetapi situasi Anda mungkin tidak memungkinkan untuk itu.

Hmm 2016 tampaknya memiliki 128GB sebagai batas, tetapi instance-split mungkin masih menjadi opsi.