Batasi penggunaan CPU maksimum SQL SERVER dengan WSRM


10

Saya memiliki server fisik yang menjalankan satu contoh SQL Server.

Saya perhatikan bahwa cukup sering server ini berjalan pada penggunaan CPU 100%.

Tim IT saya tidak senang dengan hal ini, dan menyarankan kami memesan 2 dari 32 core untuk OS.

Ini berfungsi dengan baik, sekarang puncak penggunaan maksimal hanya di bawah 90%. Selain itu, pengambilan data yang lambat dari berbagai pengguna tidak lagi dilaporkan.

Apakah ada alasan untuk TIDAK menggunakan WSRM (Windows System Resource Manager) dengan cara ini - alih-alih SQL Resource Governor?


Apakah Anda benar-benar ingin menggunakan semua CPU? Menyimpan beberapa core untuk OS tampaknya lebih bijaksana bukan? Di workstation saya, jika saya menggunakan semua core untuk beberapa angka, mesin saya akan terhenti. Saya selalu menjaga beberapa core gratis. Apakah ini bukan praktik yang baik pada mesin yang didedikasikan untuk SQL Server juga?
ManInMoon

Muatan apa yang sedang berjalan di server ini? Jenis proses apa yang menggunakan 100% CPU? Apakah ini OLTP atau analitik atau grafik atau?
Max Vernon

@ Forrest Ketika Anda mengatakan penyetelan - maksud Anda SQL Server itu sendiri - atau struktur kueri / tabel? Jika maksud Anda SQL Server, tolong beri saya tautan ke apa yang harus dilihat. Jika queiries / tables, maka saya optmise mereka ketika saya bisa, tetapi beberapa pengguna kurang sadar desain!
ManInMoon

Jawaban:


14

Apakah ada alasan untuk TIDAK menggunakan pendekatan yang telah Anda tetapkan? Benar.

Bayangkan Anda telah membeli mobil - mobil yang ketika Anda menekan 50MPH mesin mulai terlalu panas. Apakah reaksi Anda terhadap situasi ini adalah dengan membatasi secara buatan mobil hingga 49MPH, atau untuk mengetahui apa masalahnya dengan mesin?

Mengapa Anda membatasi mobil Anda hingga 49MPH? Pabrikan menyatakan bahwa ia dapat melaju secepat 80MPH - Anda suka mengendarai mobil Anda dengan cepat sehingga Anda ingin mencapai kecepatan ini - jika bukan karena masalah kepanasan.

Mobil yang Anda beli juga sangat, sangat mahal. Setiap silinder mesin perlu digunakan secara maksimal sehingga Anda tidak membuang-buang uang itu!

Dengan membatasi akses SQL Server secara artifisial ke CPU, Anda kehilangan kinerja. Anda mungkin telah menyelesaikan sementara masalah kinerja dengan memastikan CPU tersedia untuk OS untuk digunakan, tetapi Anda belum menjawab pertanyaan sebenarnya - MENGAPA SQL Server menggunakan 100% CPU?

Saran saya adalah sebagai berikut:

Cari tahu apa masalah sebenarnya, dan perbaiki. Jangan menutupi masalah dengan apa yang secara efektif merupakan kludge. Masalah AKAN muncul kembali dan menampar Anda di garis bawah ketika beban kerja server secara alami meningkat dengan pertumbuhan.

Sebagai perbaikan sementara , gubernur sumber daya dapat digunakan untuk menurunkan CPU yang digunakan, SAMPAI ANDA MENCARI MASALAH NYATA.


11

Erik Darling menyebutkan alasan praktis terbesar untuk tidak menggunakan WSRM dalam komentar pada pertanyaan Anda:

... tidak ada batasan timbal balik dari penggunaan CPU dalam proses lain. SQL Server mungkin tidak menggunakan kedua core tersebut, tetapi hal-hal lain mungkin menggunakan 30 SQL Server lain yang digunakan. Ini omong kosong, sungguh.

Jika ini berhasil untuk Anda, maka pertahankan - kita semua sibuk, dan Anda hanya dapat menghabiskan begitu banyak waktu untuk masalah apa pun. The yang ideal solusi akan memperbaiki mendasari permintaan / masalah yang mendorong CPU ke titik masalah nyata-pengguna (yang George cover dalam bukunya jawaban yang sangat baik ).

Erik melanjutkan dengan mengatakan

Plus, Anda membayar lisensi SQL Server untuk mereka.

Dari sudut pandang bisnis, ini mungkin adalah bagian terburuk dari kesepakatan WSRM - Anda membayar lisensi per-inti untuk 2 core yang secara eksplisit tidak digunakan. Pada saat penulisan ini, $ 3k atau $ 14k tersisa di atas meja (tergantung pada Standar vs Perusahaan).

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.