SQL Server tempdb pada RAM Disk?

Basis data aplikasi vendor kami sangat intensif TempDB.

Server virtual (VMWare) dengan 40 core dan 768GB RAM, menjalankan SQL 2012 Enterprise SP3.

Semua database termasuk TempDB berada pada Tier 1 SSD di SAN. Kami memiliki 10 file data tempdb, masing-masing ditumbuhkan ke 1GB dan tidak pernah tumbuh secara otomatis. Sama dengan file log 70GB. Bendera Jejak 1117 & 1118 sudah diatur.

sys.dm_io_virtual_file_stats menunjukkan lebih dari 50 Terabyte baca / tulis pada data tempdb & file log dalam sebulan terakhir, dengan io_stall kumulatif 250 jam atau 10 hari.

Kami telah menyetel kode vendor dan SP selama 2 tahun terakhir.

Sekarang, kami berpikir untuk menempatkan file tempdb di RAM Drive karena kami memiliki banyak memori. Karena tempdb dihancurkan / diciptakan kembali ketika server di-reboot, itu adalah kandidat yang ideal untuk ditempatkan pada memori yang mudah menguap yang juga hilang ketika server di-reboot.

Saya telah menguji ini pada lingkungan yang lebih rendah dan itu menghasilkan waktu kueri yang lebih cepat tetapi meningkatkan penggunaan CPU, karena CPU melakukan lebih banyak pekerjaan daripada menunggu di tempdb drive yang lambat.

Adakah orang lain yang menggunakan tempdb pada RAM di sistem produksi oltp tinggi? Apakah ada kerugian besar? Apakah ada vendor yang secara khusus memilih atau menghindari?

sql-server tempdb

— d -_- b
sumber

Mungkin Anda vendor menggunakan terlalu banyak tempDB?

— paparazzo

@ Max, pertanyaan itu hanya menjawab sebagian dari masalah 'apakah tempdb menulis masuk ke disk' .. tidak membaca dari tempdb

— d -_- b

Menggunakan SSD di tingkat SAN sebenarnya tidak memberi Anda banyak keuntungan karena latensi jaringan. Masukkan NVMe SSD ke dalam SQL Server dan jalankan tempdb di atasnya.

— Max Vernon

saya hanya googled 'nvme ssd vs ramdisk', dan hasil pertama adalah posting reddit mengklaim yang terakhir ~ 3 kali lebih cepat. Juga lebih mudah daripada mengemudi ke pusat data dan memasangnya di blade :)

— d -_- b

Microsoft menggunakan kartu PCI-E FusionIO di beberapa kelompoknya (ada solusi kecil di mana Anda masih dapat menggunakan tempdb dengan disk lokal yang mereka gunakan). Antarmuka PCI-E seperti yang ditunjukkan Max jauh lebih cepat. Anda ingin mengukur interupsi CPU per detik untuk mengukur jika Anda mendapatkan lebih banyak permintaan per detik. Anda harus sebagai latensi disk adalah salah satu penyebab utama permintaan interupsi rendah (bukan waktu SQL).

— Ali Razeghi

Jawaban:

Pertama, tempel: pastikan Anda menggunakan Pembaruan Kumulatif 10 Paket Layanan 1 2012 atau yang lebih baru. Di SQL 2014, Microsoft mengubah TempDB menjadi kurang bersemangat untuk menulis ke disk , dan mereka sangat mendukungnya untuk 2012 SP1 CU10 , sehingga dapat mengurangi banyak tekanan tulis TempDB.

Kedua, dapatkan angka pasti pada latensi Anda. Periksa sys.dm_io_virtual_file_stats untuk melihat rata-rata stall penulisan untuk file TempDB Anda. Cara favorit saya untuk melakukan ini adalah:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Lihatlah bagian statistik file, dan fokuslah pada tulisan fisik. Data SejakStartup bisa sedikit menyesatkan karena juga termasuk waktu ketika CHECKDB sedang berjalan, dan itu benar-benar dapat memalu TempDB Anda.

Jika latensi tulis rata-rata Anda lebih dari 3 ms, maka ya, Anda mungkin memiliki penyimpanan solid state di SAN Anda, tetapi masih belum cepat.

Pertimbangkan SSD lokal untuk TempDB terlebih dahulu. SSD lokal yang bagus (seperti kartu Intel PCIe NVMe, yang di bawah $ 2k USD terutama pada ukuran yang Anda uraikan) memiliki latensi yang sangat rendah, lebih rendah daripada yang dapat Anda capai dengan penyimpanan bersama. Namun, di bawah virtualisasi, ini disertai dengan kelemahan: Anda tidak dapat mem-vMotion tamu dari satu host ke host lain untuk bereaksi saat memuat atau masalah perangkat keras.

Pertimbangkan drive RAM yang terakhir. Ada dua gotcha besar dengan pendekatan ini:

Pertama, jika Anda benar-benar memiliki aktivitas menulis TempDB yang berat, laju perubahan pada memori mungkin sangat tinggi sehingga Anda tidak akan dapat memvosiasikan tamu dari satu host ke host lain tanpa disadari oleh semua orang. Selama vMotion, Anda harus menyalin konten RAM dari satu host ke yang lain. Jika benar-benar berubah secepat itu, lebih cepat daripada yang dapat Anda salin melalui jaringan vMotion Anda, Anda dapat mengalami masalah (terutama jika kotak ini terlibat dengan mirroring, AGs, atau cluster failover.)

Kedua, drive RAM adalah perangkat lunak. Dalam pengujian beban yang telah saya lakukan, saya belum terlalu terkesan dengan kecepatan mereka di bawah aktivitas TempDB yang sangat berat. Jika begitu berat sehingga SSD kelas perusahaan tidak dapat mengimbangi, maka Anda juga akan mengenakan pajak perangkat lunak drive RAM. Anda akan benar-benar ingin memuat pengujian ini sebelum ditayangkan - coba hal-hal seperti banyak indeks simultan membangun kembali pada indeks yang berbeda, semua menggunakan sort-in-tempdb.

— Brent Ozar
sumber

Membuat drive RAM harus sepele. Banyak Linux thumb drive yang dapat di-boot dan drive optik membuat drive RAM dan menyimpan file OS di sana. Sistem file root kemudian di memori. Di windows, pada hari itu, drive RAM dimuat sebagai driver perangkat di config.sys. Biasanya pengemudi dimuat dalam memori tinggi. Menurut saya, ini adalah solusi yang sangat bagus dan sederhana. Jika Anda telah membuat solusi menggunakan drive RAM, saya ingin mendengarnya. Saya ingin melakukan sesuatu yang serupa tetapi ingin menulis ke penyimpanan permanen dan menyimpan db dalam RAM. Dalam kasus saya, kami memiliki mesin yang dapat menginstal lebih banyak RAM daripada yang dapat digunakan OS. Membuat disk RAM sebelum OS memuat akan memungkinkan pemanfaatan RAM yang tidak dilihat oleh OS.

— Edward Coyle
sumber