Dalam kelanjutan seri 'penyetelan kinerja spontan' ini, saya ingin membahas Solid State Disk (SSD) dan beberapa masalah yang saya lihat dengan penggunaannya di lingkungan SQL Server. Untuk deskripsi mendalam tentang SSD, lihat artikel Wikipedia ini.
Apa Fungsi SSD Untuk Kinerja SQL Server?
SSD tidak memiliki bagian yang bergerak sehingga ketika membaca atau menulis terjadi, hampir tidak ada latensi I/O. Latensi dalam hard disk yang berputar berasal dari dua hal:
- Memindahkan kepala disk ke jalur yang benar pada permukaan disk (dikenal sebagai waktu pencarian)
- Menunggu disk berputar ke titik yang tepat di trek (dikenal sebagai latensi rotasi)
Artinya, SSD memberikan peningkatan performa yang besar saat terjadi kemacetan I/O.
Sesederhana itu.
Ada sedikit komplikasi yang perlu disebutkan tetapi di luar cakupan artikel ini untuk membahas secara mendalam:kinerja SSD dapat mulai menurun karena drive menjadi sangat penuh (diinvestigasi dan dijelaskan secara rinci dalam artikel ini dari AnandTech). Mungkin juga ada beberapa memori sistem yang diperlukan untuk driver SSD untuk membantu meratakan keausan (memperpanjang umur sel NAND di SSD), dan itu akan bervariasi menurut vendor. Cukup itu – kembali ke hal-hal SQL Server.
Hindari Saran Internet yang Buruk
Ada dua saran yang sangat buruk yang saya lihat di Internet seputar SQL Server dan SSD.
Yang pertama adalah tentang apa yang harus dipasang di SSD, di mana sarannya adalah selalu menempatkan tempdb dan log transaksi Anda di SSD. Sepintas kedengarannya seperti saran yang bagus, karena log transaksi dan tempdb biasanya merupakan hambatan dalam sistem.
Tapi bagaimana jika tidak?
Beban kerja Anda mungkin sebagian besar dibaca, dalam hal ini log transaksi kemungkinan besar tidak akan menjadi hambatan beban kerja sehingga menempatkannya di SSD mungkin membuang-buang SSD yang mahal.
Tempdb Anda mungkin tidak terlalu banyak digunakan oleh beban kerja Anda, jadi memasangnya di SSD mungkin membuang-buang SSD yang mahal.
Saat Anda mempertimbangkan bagian mana dari lingkungan SQL Server yang akan dipindahkan ke SSD, Anda ingin menyelidiki di mana hambatan I/O berada. Ini dapat dilakukan dengan sangat mudah menggunakan kode yang saya posting minggu lalu yang menggunakan sys.dm_io_virtual_file_stats DMV untuk memberikan snapshot latensi I/O untuk semua file di semua database pada instance. Untuk memahami angka latensi Anda, dan membandingkannya dengan nilai baik/buruk, baca postingan panjang ini yang saya lakukan secara khusus seputar tempdb dan log transaksi latensi I/O.
Dan bahkan jika Anda memiliki latensi tinggi, jangan terburu-buru dan berpikir bahwa satu-satunya solusi adalah memindahkan file yang berkinerja buruk ke SSD:
- Untuk latensi baca file data, selidiki mengapa ada begitu banyak pembacaan yang terjadi. Saya membahasnya di sini.
- Untuk latensi penulisan file log, pertimbangkan semua cara untuk menyesuaikan kinerja log dan apa yang dicatat. Saya membahasnya di sini, di sini, dan di sini.
Kasus terburuk yang mungkin terjadi adalah ketika Anda diberikan banyak SSD, ikuti saran Internet untuk memindahkan tempdb dan file log Anda ke sana, dan kemudian tidak ada peningkatan kinerja beban kerja. Itu tidak akan mendorong manajemen Anda untuk memberi Anda SSD yang lebih mahal.
Saran buruk kedua adalah seputar fragmentasi indeks, di mana sarannya adalah karena SSD sangat cepat, Anda tidak perlu khawatir tentang fragmentasi indeks saat menggunakan SSD.
Omong kosong apa!
Ada tiga cara saya menyangkal nasihat buruk itu:
- SSD sama sekali tidak menghentikan penyebab fragmentasi indeks:pemisahan halaman dari halaman yang membutuhkan ruang kosong untuk penyisipan acak atau peningkatan ukuran baris. Pemisahan halaman menghasilkan jumlah log transaksi, penggunaan sumber daya, dan utas potensial yang sama, terlepas dari tempat penyimpanan data/file log.
- Fragmentasi indeks termasuk memiliki banyak data/halaman indeks dengan kepadatan halaman rendah (yaitu banyak ruang kosong dan kosong). Apakah Anda benar-benar ingin SSD mahal Anda menyimpan banyak ruang kosong? SSD sama sekali tidak membantu di sini.
- Rekan saya Jonathan Kehayias melakukan investigasi mendalam, menggunakan Extended Events, dari pola I/O seputar fragmentasi indeks secara khusus untuk mengatasi saran buruk ini dan menemukan bahwa masih ada penurunan kinerja karena fragmentasi indeks saat menggunakan SSD. Anda dapat membaca postingan panjangnya di sini.
Satu-satunya hal yang dilakukan SSD di sekitar fragmentasi indeks adalah membuat pembacaan berjalan lebih cepat, jadi ada lebih sedikit penalti kinerja untuk pemindaian rentang indeks saat ada fragmentasi indeks, tetapi poin 3 di atas menunjukkan bahwa masih ada penalti.
SSD tidak mengubah cara Anda menangani dan/atau mencegah fragmentasi indeks di lingkungan SQL Server Anda.
Pastikan untuk Melindungi Data Anda
Salah satu dosa besar yang saya lihat dilakukan orang-orang menggunakan SSD adalah hanya menggunakan salah satunya. Dengan hanya satu drive, level RAID apa yang Anda gunakan? Nol. RAID-0 tidak memberikan redundansi sama sekali.
Jika Anda akan menggunakan SSD, maka Anda harus menggunakan setidaknya dua, dalam konfigurasi RAID-1 (mirroring). Tidak ada gunanya meningkatkan performa jika Anda mengorbankan ketersediaan sistem sebagai trade-off.
Satu dorongan mundur yang terkadang saya gunakan untuk menggunakan setidaknya dua SSD adalah bahwa kartu SSD menyediakan dua drive untuk Windows, dan tentu saja membuat volume cermin Windows pada dua drive sama dengan RAID-1 di dua SSD yang terpisah secara fisik?
Tidak. Ini masih satu SSD fisik, tanpa redundansi. Pernahkah Anda melihat setengah dari kartu SSD gagal? Tidak, saya juga tidak. Lakukan dengan benar dan gunakan dua di antaranya dan dapatkan redundansi nyata untuk data Anda.
Dorongan lain yang saya dapatkan adalah SSD, bukan drive yang berputar, jadi tidak akan gagal. Itu salah. SSD dapat dan memang gagal seperti drive yang berputar. Saya pribadi telah melihat dua SSD tingkat perusahaan gagal selama pengujian di lingkungan lab kami. Menurut artikel di StorageReview.com ini, SSD tingkat konsumen memiliki MTBF 2 juta jam vs. 1,5 juta jam untuk drive pemintalan tingkat konsumen, dan saya mengharapkan hasil yang sama untuk drive tingkat perusahaan, tetapi SSD gagal.
Ringkasan
Jangan terjebak dalam pemikiran bahwa apa pun yang Anda masukkan ke dalam SSD berarti Anda akan mendapatkan peningkatan kinerja – Anda harus memilih dan memilih dengan hati-hati. Dan jangan percaya omong kosong di luar sana tentang mengabaikan fragmentasi indeks saat menggunakan SSD.
SSD adalah cara yang sangat berguna untuk meningkatkan kinerja, tetapi untuk biayanya, Anda ingin memastikan bahwa Anda memaksimalkan laba atas investasi perusahaan Anda dengan menggunakannya dengan benar dan hanya jika sesuai.
Dalam artikel berikutnya dalam seri ini, saya akan membahas penyebab umum lain dari penyetelan performa spontan. Sampai saat itu, selamat memecahkan masalah!
