Perintah SQL Server untuk menghapus cache sebelum menjalankan perbandingan kinerja

Saat membandingkan waktu eksekusi dari dua query yang berbeda, penting untuk menghapus cache untuk memastikan bahwa eksekusi dari query pertama tidak mengubah kinerja yang kedua.

Di Google Penelusuran, saya dapat menemukan perintah ini:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Sebenarnya, pertanyaan saya membutuhkan waktu yang lebih realistis untuk diselesaikan setelah beberapa eksekusi daripada sebelumnya. Namun, saya tidak yakin ini adalah teknik yang direkomendasikan.

Apa praktik terbaik?

Secara pribadi, untuk kueri umum, eksekusi ke-2 dan selanjutnya lebih penting.

Apakah Anda menguji IO disk atau kinerja permintaan?

Dengan asumsi permintaan Anda sering berjalan dan sangat penting, maka Anda ingin mengukurnya dalam kondisi kehidupan nyata. Dan Anda tidak ingin menghapus cache server prod setiap kali ...

Jika kamu mau maka kamu bisa:

• DBCC DROPCLEANBUFFERSmembersihkan halaman (yang belum dimodifikasi) dari buffer pool.
  Dahului dengan CHECKPOINTmembersihkan halaman yang kotor ke disk terlebih dahulu
• DBCC FLUSHPROCINDB membersihkan rencana eksekusi untuk database itu

Lihat juga (di DBA.SE)

• Memecahkan waktu buka halaman yang tinggi menggunakan SQL Profiler

Jawaban terlambat tetapi mungkin berguna bagi pembaca lain

DBCC DROPCLEANBUFFERS adalah perintah yang sering digunakan untuk pengujian kueri dan mengukur kecepatan eksekusi kueri. Perintah ini (saat dijalankan) hanya menyisakan halaman kotor, yang sebenarnya merupakan bagian kecil dari data. Ini menghapus semua halaman bersih untuk seluruh server.

Maklum bahwa perintah ini tidak boleh dijalankan di lingkungan produksi. Menjalankan perintah ini sebagian besar akan menghasilkan cache buffer kosong. Menjalankan kueri apa pun setelah menjalankan perintah DBCC DROPCLEANBUFFERS, akan menggunakan pembacaan fisik untuk membawa kembali data ke dalam cache, yang sangat mungkin akan jauh lebih lambat daripada memori.

Sekali lagi, perlakukan perintah ini dengan cara yang sama seperti DBCC FREEPROCCACHE - ini tidak boleh dijalankan di server produksi apa pun kecuali Anda benar-benar tahu apa yang Anda lakukan.

Ini bisa menjadi alat pengembangan yang berguna karena Anda bisa menjalankan kueri di lingkungan pengujian kinerja berulang tanpa perubahan kecepatan / efisiensi karena caching data dalam memori.

Pelajari lebih lanjut di: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

Saya selalu disuruh menggunakan:

dbcc dropcleanbuffers;

Dari MSDN :

Gunakan DBCC DROPCLEANBUFFERS untuk menguji permintaan dengan cache buffer dingin tanpa mematikan dan me-restart server.

Untuk menjatuhkan buffer bersih dari kumpulan buffer, pertama-tama gunakan CHECKPOINT untuk menghasilkan cache buffer dingin. Ini memaksa semua halaman kotor untuk database saat ini ditulis ke disk dan membersihkan buffer. Setelah Anda melakukan ini, Anda bisa mengeluarkan perintah DBCC DROPCLEANBUFFERS untuk menghapus semua buffer dari kumpulan buffer.

Jawaban lainnya benar tentang alasan tidak berjalan DBCC FREEPROCCACHE. Namun, ada beberapa alasan untuk melakukannya:

1. Konsistensi

Jika Anda ingin membandingkan dua kueri atau prosedur berbeda yang mencoba melakukan hal yang sama dengan cara yang berbeda, mereka cenderung membuka halaman yang sama. Jika Anda menjalankan kueri # 1 secara naif lalu meminta # 2, yang kedua mungkin jauh lebih cepat hanya karena halaman-halaman itu di-cache oleh kueri pertama. Jika Anda menghapus cache sebelum setiap eksekusi, mereka mulai dengan pijakan yang rata.

Jika Anda ingin menguji kinerja cache panas, pastikan untuk menjalankan kueri beberapa kali, berganti-ganti, dan membuang beberapa run pertama. Rata-rata hasilnya.

2. Kinerja terburuk

Katakanlah Anda memiliki kueri yang membutuhkan satu detik terhadap cache panas tetapi satu menit terhadap cache dingin. Optimasi yang membuat kueri di dalam memori 20% lebih lambat tetapi kueri terikat IO 20% lebih cepat bisa menjadi kemenangan besar: selama operasi normal, tidak ada yang akan melihat 200 ms ekstra dalam keadaan normal, tetapi jika sesuatu memaksa kueri untuk jalankan terhadap disk, mengambil 48 detik, bukannya 60 mungkin menghemat penjualan.

Ini kurang menjadi perhatian pada sistem modern dengan memori puluhan gigabyte, dan penyimpanan SAN dan SSD yang relatif cepat, tetapi tetap penting. Jika beberapa analis menjalankan kueri pemindaian tabel besar-besaran terhadap basis data OLTP Anda yang menghapus setengah dari cache buffer Anda, kueri yang efisien penyimpanan akan membuat Anda kembali lebih cepat dengan kecepatan.