Salah satu hal yang secara bersamaan hebat dan mengerikan tentang Internet adalah, begitu sesuatu diposkan di eter, pada dasarnya tidak pernah hilang. (Suatu hari, politisi akan menyadari hal ini. Kita dapat dengan mudah memeriksa konsistensi mereka.) Karena umur panjang konten yang diposting ke Internet, banyak topik penyesuaian kinerja menjadi "zombie". Kami menembak mati mereka, tapi mereka terus kembali!
Dengan kata lain, rekomendasi lama tersebut adalah praktik terbaik yang disarankan sejak lama, untuk versi SQL Server tertentu, tetapi sekarang tidak sesuai untuk versi yang lebih baru. Bukan hal yang aneh bagi saya, ketika berbicara di sebuah konferensi, untuk menemukan seseorang yang masih berpegang teguh pada pengaturan dan teknik yang belum menjadi praktik yang baik sejak zaman SQL Server 2000. Panduan Operasi SQL Server 2000 tentang Kapasitas/Penyimpanan berisi banyak " rekomendasi praktik terbaik" yang sangat khusus versi dan tidak berlaku lagi saat ini.
Jadi inilah contohnya. % Disk Time dan Disk Queue Length Penghitung PerfMon sangat direkomendasikan sebagai indikator kinerja utama untuk kinerja I/O. SQL Server melempar banyak I/O ke disk menggunakan scatter/gather untuk memaksimalkan pemanfaatan subsistem I/O berbasis disk. Pendekatan ini mengarah ke semburan pendek kedalaman antrian panjang selama pos pemeriksaan dan membaca-depan untuk contoh SQL Server. Terkadang beban kerja server sedemikian rupa sehingga disk Anda tidak dapat mengikuti I/O yang didorong ke sana dan, ketika itu terjadi, Anda juga akan melihat antrian yang panjang. Skenario short burst tidak menjadi masalah. Skenario perpanjangan antrian biasanya menjadi masalah. Jadi, apakah itu praktik yang baik?
Singkatnya, tidak terlalu banyak.
Penghitung tersebut masih dapat digunakan pada instance SQL Server yang hanya memiliki satu hard disk (meskipun itu sangat langka hari ini). Mengapa?
Penghitung PerfMon % Disk Time adalah metrik kinerja palsu karena beberapa alasan. Ini tidak memperhitungkan permintaan I/O asinkron. Itu tidak dapat mengetahui seperti apa profil performa sebenarnya untuk kumpulan RAID yang mendasarinya, karena berisi beberapa drive disk. Penghitung PerfMon Disk Queue Length juga sebagian besar tidak berguna, kecuali pada SQL Server dengan satu disk fisik, karena cache pengontrol hard disk mengaburkan berapa banyak operasi I/O yang sebenarnya tertunda pada antrian atau tidak. Faktanya, beberapa hard disk bahkan memiliki cache tulis kecil juga, yang selanjutnya memperumit masalah apakah I/O benar-benar antri, dalam cache di suatu tempat antara sistem operasi dan disk, atau akhirnya berhasil sepenuhnya. ke CMOS pada disk.
Penghitung PerfMon I/O yang Lebih Baik
Alih-alih menggunakan penghitung PerfMon tersebut, gunakan Avg Disk Reads/sec , Avg Disk Writes/sec , dan Avg Disk Transfers/sec untuk melacak kinerja subsistem disk. Penghitung ini melacak jumlah rata-rata I/O baca, I/O tulis, dan gabungan I/O baca dan tulis yang terjadi pada detik terakhir. Terkadang, saya suka melacak metrik yang sama berdasarkan volume data daripada kecepatan operasi I/O. Jadi, untuk mendapatkan data tersebut, Anda mungkin ingin mencoba penghitung PerfMon khusus volume berikut: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec , dan Avg Disk Write Bytes/sec .
Untuk Kinerja I/O SQL Server, Gunakan Tampilan Manajemen Dinamis (DMV)
Dan kecuali Anda telah tinggal di gua, Anda harus memastikan untuk menggunakan Tampilan Manajemen Dinamis (DMV) SQL Server untuk memeriksa kinerja I/O untuk versi terbaru SQL Server. Beberapa DMV favorit saya untuk I/O meliputi:
- sys.dm_os_wait_stats
- sys.dm_os_waiting_tasks
- sys.dm_os_performance_counters
- sys.dm_io_virtual_file_stats
- sys.dm_io_pending_io_requests
- sys.dm_db_index_operational_stats
- sys.dm_db_index_usage_stats
Jadi, bagaimana Anda melacak metrik kinerja I/O? Yang mana yang Anda gunakan?
Saya menantikan kabar dari Anda!
Selamat menikmati,
-Kev
–Ikuti saya di Twitter!
