Bagaimana cara meningkatkan kinerja pertanyaan perawan di MS SQL Server?

Saya memiliki situs web ASP.NET yang melakukan caching data sendiri dan data tidak berubah untuk jangka waktu yang lama, sehingga tidak perlu melakukan query SQL Server kedua kalinya dengan permintaan yang sama. Saya perlu meningkatkan kinerja kueri (perawan) pertama kali yang masuk ke SQL Server itu. Beberapa permintaan memproses begitu banyak data sehingga dapat menyebabkan SQL Server digunakan tempdb. Saya tidak menggunakan variabel tabel temp atau tabel temp, jadi SQL Server memutuskan untuk menggunakannya tempdbsendiri kapan pun diperlukan.

Ukuran db saya 16Gb, saya memiliki 32Gb RAM fisik yang tersedia di mesin server saya.

Saya mengerti bahwa strategi caching MS SQL Server mencoba untuk menyimpan data dalam RAM untuk mempercepat kinerja pertanyaan serupa jika mereka membutuhkan data yang sama untuk dimuat lagi. Selain itu akan mencoba menggunakan RAM yang tersedia, bukan tempdb untuk mempercepat kinerja tanpa menyebabkan akses disk.

Saya kira ketika permintaan yang perlu menyimpan sesuatu di tempdb SQL Server datang dan tidak ada cukup RAM yang tersedia, SQL Server memiliki 2 pilihan:

1) untuk membongkar beberapa data yang di-cache dan menggunakan RAM yang disimpan alih-alih tempdb untuk menghindari penulisan disk

2) menyimpan data yang di-cache untuk kueri di masa depan dan mulai menggunakan tempdb, yang menyebabkan penulisan memperlambat disk.

Saya tidak tahu pilihan apa yang akan dibuat oleh SQL Server dalam situasi ini, tapi saya ingin itu membuat pilihan # 1 karena saya hanya peduli tentang kinerja kueri (perawan) pertama kali, karena saya tidak pernah mengirim kueri yang sama ke SQL Server lagi (meskipun saya dapat mengirim permintaan serupa).

Apa strategi caching SQL Server untuk skenario ini?

Bagaimana cara menyeimbangkan penggunaan RAM antara menghindari tempdb untuk permintaan perawan dan kecepatan permintaan kedua kalinya?

Apakah mungkin untuk mengkonfigurasi SQL Server sedemikian rupa sehingga akan membuat pilihan # 1? Jika ya lalu bagaimana?

Bagaimana lagi saya bisa meningkatkan kinerja semua pertanyaan SQL perawan?

Karena saya tidak tahu tentang strategi caching SQL Server, saya ingin menempatkan database pada RAM Disk. Ini akan memastikan bahwa setiap perawan permintaan memiliki kecepatan tinggi memuat data yang tidak di-cache bahkan jika SQL Server selalu membuat pilihan # 1. Risiko itu adalah bahwa SQL Server dapat mulai menggunakan lebih banyak tempdb dengan RAM yang tersedia lebih sedikit (hanya 16Gb tersisa setelah saya menggunakan 16Gb untuk RAM Disk) jika terus membuat pilihan # 2, yang akan memperlambat permintaan perawan yang menyebabkan tumpah ke dalam tempdb.

Saya tertarik pada solusi untuk SQL 2008 R2, tapi saya rasa itu mungkin sama untuk SQL 2008, SQL 2005 dan mungkin SQL 2000.

Klarifikasi:

Tidak ada aplikasi lain yang berjalan di kotak itu, itu didedikasikan untuk SQL Server . Situs web berjalan pada kotak terpisah.

Ini SQL Server 2008 R2 Edisi Standar 64 bit pada Windows Server 2008 R2 Enterprise 64 bit.

Saya menjalankan kueri hanya-baca dan basis data diatur menjadi hanya-baca .

Mari kita asumsikan sudah ada indeks yang bagus . Pertanyaan ini adalah tentang SQL Server membuat pilihan # 1 vs pilihan # 2, bagaimana cara membuatnya, jika ada cara untuk mengendalikannya dan jika RAM Disk membantunya untuk membuat pilihan yang tepat untuk pertanyaan perawan.

— alpav
sumber

Apa yang membuat Anda berpikir bahwa tempdb sedang digunakan meskipun Anda tidak membuat tabel temp? Apakah Anda menggunakan tabel berbeda atau dikelompokkan berdasarkan tabel?

— Selat darin

32/64 bit? Fisik atau virtual? Apakah server ini didedikasikan untuk SQL Server atau Anda juga menjalankan IIS atau aplikasi lain di kotak yang sama? Sudahkah Anda melakukan analisis rencana eksekusi permintaan? Bisakah Anda memposting pertanyaan contoh dan / atau rencana eksekusi? Dan satu lagi untuk keberuntungan ... ikuti panduan Kendra untuk masuk ke sp_whoisactive saat kueri masalah Anda berjalan dan kirim hasilnya.

— Mark Storey-Smith

@darinstrait Penjelasan yang paling mungkin adalah semacam atau hash spill.

— Mark Storey-Smith

Jawaban:

Pertanyaan Anda pada dasarnya dapat diulangi sebagai 'Bagaimana cara kerja permintaan memori hibah?'. Pembacaan yang baik pada subjek adalah Memahami hibah memori server SQL . Sebelum kueri diluncurkan ke eksekusi, mungkin memerlukan hibah memori untuk jenis dan hash dan operasi lapar memori lainnya. Hibah memori ini adalah perkiraan . Berdasarkan status sistem saat ini (jumlah permintaan yang sedang berjalan dan menunggu, memori tersedia dll) sistem memberikan permintaan hibah memori hingga jumlah yang diperlukan. Setelah memori diberikan, permintaan memulai eksekusi (mungkin harus menunggu dalam antrian 'resource semaphore' yang ditakuti sebelum mendapat hibah). Pada saat pelaksanaannya, pemberian memori dijaminoleh sistem. Jumlah memori ini dapat dibagi dengan halaman data (karena mereka selalu dapat flush ke disk) tetapi tidak pernah dengan penggunaan memori lain (mis. Itu tidak bisa menjadi subjek 'mencuri'). Jadi, ketika permintaan mulai meminta memori yang dikomit dari hibahnya, mesin akan menyebarkan apa yang Anda sebut 'strategi # 1': halaman data dapat digusur (memerah jika kotor) untuk memberikan permintaan memori yang dijanjikan. Sekarang jika perkiraan itu benar dan hibahnya 100% dari memori yang diminta, kueri tidak boleh 'tumpah'. Tetapi jika perkiraan itu tidak benar (bermuara pada perkiraan kardinalitas, oleh karena itu tunduk pada statistik basi) atau jika permintaan tidak mendapatkan seluruh hibah yang diminta, permintaan akan 'tumpah'. Ini adalah saat tempdb muncul dan kinerja biasanya tank.

Satu-satunya tombol yang Anda miliki yang mengendalikan sesuatu dalam proses ini adalah Gubernur Sumber Daya . Karena RG dapat digunakan untuk menentukan pengaturan MIN untuk kumpulan, ia dapat digunakan untuk cadangan memori untuk beban kerja tertentu sehingga benar - benar mendapatkan memori yang diminta. Tentu saja, setelah Anda melakukan investigasi yang tepat yang menunjukkan bahwa berkurangnya hibah memori adalah biang keladinya, dan tentu saja setelah dampak pada beban kerja lainnya dievaluasi. Dan diuji, tentu saja.

Sekarang mari kembali ke pertanyaan awal Anda. Jika penyelidikan Anda benar (jika sangat besar) saya ingin menunjukkan dua masalah:

Anda menjalankan permintaan produksi yang membutuhkan hibah memori untuk situs web . Ini adalah no-no besar. Hibah memori adalah indikasi permintaan analitis yang tidak memiliki tempat dalam melayani permintaan HTTP.
pertanyaan Anda mungkin bukan acara mendapatkan memori hibah yang mereka minta. Sekali lagi, bahkan lebih dari tidak-tidak untuk beban kerja kritis latensi seperti situs web.

Jadi yang saya tahu adalah Anda memiliki masalah desain dan arsitektur yang mendasar. Situs web digerakkan oleh latensi dan harus membuat OLTP seperti beban kerja, tanpa hibah memori dan tanpa tekanan memori pada permintaan. Belum lagi tidak ada tumpahan. Kueri analitik harus dijalankan dalam pekerjaan offline dan menyimpan hasil yang sudah diproses untuk ketersediaan cepat ketika permintaan HTTP menginginkannya.

— Remus Rusanu
sumber

@ Mark: Sebagian besar kueri tidak memerlukan memori. Hanya beberapa operator (terutama yang mengurutkan dan menggabungkan hash) yang membutuhkan buffer kerja dan karenanya meminta hibah. Ini adalah standar 'nomenklatur'. Anda mungkin berpikir tentang lingkungan eksekusi dan rencana eksekusi permintaan, yang mana setiap permintaan tunggal membutuhkannya dan itu termasuk beberapa memori. Memori hibah jauh lebih besar (MB). Kedua, lihat sys.dm_exec_query_memory_grants: Anda memiliki requested(maks), required(min) dan granted(aktual).

— Remus Rusanu

Permintaan maaf. Saya telah mengambil dari suatu tempat bahwa minimum per permintaan dialokasikan dari petugas memori yang sama, yang tidak benar.

— Mark Storey-Smith

Masih tidak yakin saya setuju dengan dua poin Anda. Segala macam cara sepele dan operasi hash bergabung memerlukan hibah pada tingkat minimum, sehingga menyarankan mereka harus dihilangkan sepenuhnya tampak berlebihan. Bahwa tumpahan ke tempdb dari hibah yang tidak mencukupi adalah bendera merah tentu masuk akal tetapi larangan menyeluruh pada operasi apa pun yang memerlukan hibah mungkin membuat banyak orang di jalur optimisasi pre-emptive yang tidak perlu?

— Mark Storey-Smith

OP mengklaim memiliki semua indeks yang diperlukan. Jika itu benar dan beban kerja memiliki cukup memori hibah (dan bahkan tumpah) masalah untuk dapat terlihat, maka saya akan mengatakan bahwa beban kerja terlalu analitis untuk situs web . Pada akhirnya, optimasi kinerja selalu merupakan permainan investigasi untuk menentukan akar permasalahannya. Semua pernyataan selimut dan larangan akan selalu ditemukan contoh balasan yang membuktikan bahwa mereka salah, yaitu yang diberikan. Apakah OP memiliki masalah desain yang menciptakan beban kerja terlalu analitis? Saya tidak tahu Apakah saya pikir begitu? Saya akan mengatakan 87,5% kepercayaan diri ya.

— Remus Rusanu

@Remus: Tebakan Anda bagus, kueri situs web saya adalah 100% analitis. Hal ini memungkinkan pengguna untuk membangun setiap permintaan yang mungkin di UI untuk mengirim semua kemungkinan kombinasi filter, agregat dan pengelompokan ke SQL Server (yang, tentu saja, membuat pengindeksan sulit). Ya, saya dapat membuat mereka berjalan dalam mode penyimpanan async hasil untuk pengambilan nanti, tetapi tujuannya adalah untuk membuat permintaan untuk menjalankan begitu cepat sehingga hasilnya segera tersedia setelah 2-10 detik dan juga query analitik adalah satu-satunya fungsi dari situs web itu , Saya pikir membuat mereka async hanya masuk akal jika ada pertanyaan lain yang tidak analitis.

— alpav

Yang belum Anda sebutkan adalah pertanyaan apa yang dijalankan terhadap database dan jika ada indeks yang tepat untuk mempercepat kinerja pertanyaan Anda.

Anda juga perlu memastikan apakah ada aplikasi lain yang berjalan di kotak yang sama. Meskipun kotak tersebut memiliki 32 GB RAM, apakah Anda telah menetapkan pengaturan memori maks pada server database untuk memberikan batasan buatan. Jika ada aplikasi yang berjalan di server yang sama maka SQL dan aplikasi lain mungkin bersaing untuk sumber daya dan perhatikan bahwa SQL sangat membutuhkan memori.

SQL Server akan menggunakan tempdb untuk penyortiran internal atau bergabung hash / agregat atau operator spool dll dan Anda tidak dapat mengontrol perilaku ini. Yang dapat Anda lakukan adalah membatasi jumlah data yang dikembalikan.

Sudahkah Anda memeriksa statistik tunggu di kotak ini? Setiap kali SQL Server menunggu pada sumber daya, SQL Server akan melacak sumber daya tunggu dan melihat informasi itu membantu.

Lihatlah pertanyaan diagnostik Glenn Berry dan itu akan menjadi awal yang baik untuk Anda.

Lihat juga PARAMETERISASI PAKSA sebagaimana disebutkan dalam http://weblogs.sqlteam.com/dang/archive/2009/06/27/ Dipaksa-Parameterisasi-A-Turbo-Button.aspx

— Sankar Reddy
sumber

ok, anggap saja sudah ada indeks yang benar. Saya lupa menyebutkan bahwa ini adalah database hanya-baca dengan kueri hanya-baca dan tidak ada aplikasi lain yang berjalan pada kotak SQl Server.

— alpav

Apakah statistik Anda mutakhir? Basis data Read-Only tidak dapat membuat statistik jika mereka hilang atau ketinggalan zaman. Apakah data Anda miring atau memiliki nilai unik untuk kunci tersebut. Ada banyak faktor yang dapat menyebabkan perilaku ini.

— Sankar Reddy

Apa yang Anda maksud dengan "perilaku ini"? Saya tidak menyebutkan bahwa ada sesuatu yang salah. Saya hanya ingin meningkatkan kinerja dalam keadaan khusus saya. SQL Server dioptimalkan untuk dijalankan dalam situasi apa pun, tetapi mungkin atau mungkin tidak menjalankan cara terbaik dalam situasi saya. Saya tidak yakin apakah saya bisa mempercayai SQL Server untuk membuat pilihan yang seimbang # 1 vs # 2. Setiap kali saya memasukkan data baru, saya menjalankan sp_updatestats.

— alpav

# 1 dan # 2 tidak terjadi seperti yang Anda pikirkan. msdn.microsoft.com/en-us/library/ms191475(v=sql.105).aspx msdn.microsoft.com/en-us/library/aa337560(v=sql.105).aspx

— Sankar Reddy

Ketika Anda menjalankan sp_updatestats, berapa rasio sampel yang Anda pilih. Rasio default sangat sampel dan tergantung pada ukuran indeks. Jika pertanyaan Anda sebagian besar (hanya) data baru dan bahkan jika Anda melakukan sp_updatestats, SQL Server tidak dapat membuat keputusan besar pada rencana eksekusi.

— Sankar Reddy

Pertanyaan ini saat ini berbunyi seperti solusi mencari masalah. Anda telah memutuskan bahwa disk RAM adalah solusinya dan Anda ingin seseorang untuk memvalidasi pilihan itu. Maaf, tidak akan terjadi.

Jika Anda telah mengukur dan mengamati tumpahan ke tempdb, hampir pasti karena operasi pengurutan atau hash dan hibah memori kueri yang tidak mencukupi. Bergantung pada volume data yang akan diproses ini mungkin tidak dapat dihindari tetapi peluang bagus kueri dan / atau pengindeksan dapat ditingkatkan untuk menghindarinya.

Lihatlah Buffer Management untuk lebih memahami bagaimana SQL Server mengelola memori dan SQL Server Memory Management Dijelaskan untuk beberapa alat dasar dan pertanyaan DMV untuk memahami di mana memori Anda dialokasikan.

Bagaimana lagi saya bisa meningkatkan kinerja semua pertanyaan SQL perawan?

Ini adalah topik besar. Posting kueri dan rencana dan Anda akan mendapatkan umpan balik yang ditargetkan.

— Mark Storey-Smith
sumber