Oke, untuk siapa saja yang tertarik,
Kami memecahkan masalah di Pertanyaan beberapa bulan yang lalu hanya dengan menginstal drive SSD yang terpasang langsung ke masing-masing dari 3 server, dan memindahkan data DB dan mencatat file dari SAN ke drive SSD tersebut
Berikut ringkasan tentang apa yang saya lakukan untuk meneliti masalah ini (menggunakan rekomendasi dari semua posting, pertanyaan ini), sebelum kami memutuskan untuk menginstal drive SSD:
1) mulai mengumpulkan counter PerfMon untuk drive berikut di ketiga server:
Disk F:
adalah disk logis berdasarkan SAN, berisi file data MDF
Disk I:
disk logis berdasarkan SAN, berisi file log LDF
Disk T:
yang langsung terpasang SSD, didedikasikan hanya untuk tempDB
Gambar di bawah ini adalah nilai rata-rata yang dikumpulkan selama periode 2 minggu
Disk I: (LDF)
memiliki IO yang sangat kecil dan Latency sangat rendah, jadi Disk I: dapat diabaikan
Anda dapat melihat bahwa Disk T: (TempDB)
IO lebih besar dibandingkan dengan Disk F: (MDF)
, dan memiliki Latensi yang jauh lebih baik pada saat yang sama - 0 ms
Jelas ada sesuatu yang salah dengan Disk F: di mana file data berada, ia memiliki Latensi tinggi dan Rta Tulis Disk Antrian, meskipun IO rendah
2) Memeriksa Latensi untuk basis data individual menggunakan kueri dari situs web ini
https://www.brentozar.com/blitz/slow-storage-reads-writes/
Beberapa basis data aktif di server Utama memiliki latensi baca 150-250 ms dan latensi tulis 150-450 ms
Yang menarik, file basis data master dan msdb telah membaca latensi hingga 90 ms yang mencurigakan mengingat kecilnya data dan rendahnya IO - indikasi lain ada yang salah dengan SAN
3) Tidak ada timing spesifik
Selama yang "SQL Server telah mengalami kejadian ..." pesan muncul
Tidak ada pemeliharaan atau disk yang tinggi ETL berjalan ketika pesan-pesan yang login
4) Windows Event Viewer
Tidak menunjukkan entri lain yang akan mengisyaratkan masalah, kecuali "SQL Server telah mengalami kejadian ..."
5) Mulai memeriksa 10 pertanyaan teratas
Dari sp_BlitzCache (cpu, membaca, dll.), Dan mempercepat jika mungkin
Tidak ada super IO pertanyaan berat yang akan mengocok banyak data dan berdampak besar pada penyimpanan, meskipun
pengindeksan dalam basis data tidak masalah, saya mempertahankannya
6) Kami tidak memiliki tim SAN
Kami hanya memiliki 1 sysadmin yang membantu pada kesempatan
Network path ke SAN - multipathed, masing-masing dari 3 server memiliki 2 kabel jaringan yang mengarah ke switch dan kemudian ke SAN, dan seharusnya 1 Gigabyte / detik
7) Tidak ada hasil CrystalDiskMark
Atau hasil uji benchmark lainnya dari ketika server yang pengaturan, jadi saya tidak tahu apa kecepatan harus menjadi, dan tidak mungkin untuk patokan pada saat ini untuk melihat apa kecepatan saat ini adalah, karena akan berdampak Produksi
8) Atur sesi Extended Events pada acara pos pemeriksaan untuk database yang dimaksud
Sesi XE membantu menemukan bahwa selama pesan "SQL Server mengalami kejadian ...", pos pemeriksaan terjadi sangat lambat (hingga 90 detik)
9) Log Kesalahan SQL Server
Entri "FlushCache" "Saturasi" yang terkandung
Ini seharusnya muncul ketika waktu pos pemeriksaan untuk database yang diberikan melebihi pengaturan interval pemulihan
Detail menunjukkan bahwa jumlah data yang ingin diperiksa oleh checkpoint kecil dan butuh waktu lama untuk menyelesaikannya, dan kecepatan keseluruhannya sekitar 0,25 MB / detik ... aneh
10) Akhirnya, gambar ini menunjukkan bagan pemecahan masalah penyimpanan:
Tampaknya kita hanya memiliki "Masalah Perangkat Keras: - Bekerja dengan admin sistem / vendor perangkat keras untuk memperbaiki kesalahan konfigurasi SAN, driver lama / rusak, pengontrol, firmware, dll."
Dalam pertanyaan lain "Lambat periksa ..." Lambat periksa dan 15 I peringatan I / O pada penyimpanan flash
Sean memiliki daftar yang sangat bagus dari item apa yang harus diperiksa pada tingkat perangkat keras dan perangkat lunak untuk memecahkan masalah
Sysadmin kami tidak dapat memeriksa semua hal dari daftar, jadi kami hanya memilih untuk membuang beberapa perangkat keras pada masalah ini - itu tidak mahal sama sekali
Resolusi:
Kami memesan drive SSD 1 TB dan dipasang langsung ke server
Karena kami memiliki Grup yang Tersedia, memigrasikan file data DB dari SAN ke SSD pada replika sekunder, kemudian gagal, dan memigrasikan file pada mantan primer. Ini memungkinkan untuk total downtime minimum - kurang dari 1 menit
Sekarang setiap server memiliki salinan data DB lokal, dan pencadangan penuh / diff / log dilakukan ke SAN yang disebutkan di atas.
Tidak ada lagi pesan "SQL Server telah mengalami kejadian ..." di log Windows Event Viewer, dan kinerja cadangan, pemeriksaan integritas, indeks membangun kembali, permintaan dll telah meningkat secara signifikan
Berapa banyak kinerja dalam hal IO latency telah meningkat sejak kami memigrasikan file DB ke SSD?
Untuk mengevaluasi dampak, kinerja yang digunakan log Monitor Kinerja Windows 2 minggu sebelum migrasi dan 4 minggu setelah migrasi:
Juga di bawah ini adalah perbandingan statistik latensi tingkat DB (digunakan statistik file virtual yang ditangkap SQL Server sebelum dan sesudah migrasi)
Ringkasan
Migrasi dari SAN ke SSD lokal yang terpasang langsung sangat bermanfaat.
Itu berdampak besar pada latensi penyimpanan dan meningkat rata-rata lebih dari 90% (terutama operasi WRITE), dan kami tidak memiliki lonjakan 20-50 detik di IO lagi
Pindah ke SSD lokal menyelesaikan tidak hanya masalah kinerja penyimpanan tetapi juga keamanan data yang saya khawatirkan (jika SAN gagal, ketiga server kehilangan data mereka pada saat yang sama)