Kami memiliki server DB produksi pada SQL 2005. Semuanya berjalan normal untuk sementara waktu, tetapi setelah beberapa minggu kami melihat penurunan kinerja yang penting. Hanya dengan me-restart SQL Server, kinerja kembali normal.
Beberapa latar belakang:
- Menjalankan lebih dari 1.200 basis data (kebanyakan penyewa tunggal, beberapa penyewa multi). Sebelum ada yang memberi kuliah tentang pindah ke hanya multi-penyewa, ada alasan yang sah untuk menjaga struktur ini ......
- RAM adalah 16 GB. Setelah memulai ulang, SQL Server tidak perlu terlalu lama untuk kembali ke penggunaan 15 GB.
- Koneksi DB aktif adalah sekitar 80 koneksi - yang kami rasa cukup sehat mengingat ada satu kolam koneksi per server web per proses - jadi kami tidak memiliki masalah kebocoran koneksi.
Kami telah mencoba beberapa hal di waktu non-puncak: - Jalankan DBCC DROPCLEANBUFFERS (dengan CHECKPOINT) untuk menghapus cache data. Ini tidak berpengaruh, juga tidak menghapus penggunaan RAM). - Jalankan FREEPROCCACHE dan FREESYSTEMCACHE untuk menghapus rencana kueri dan menyimpan cache proc. Tidak berpengaruh.
Jelas memulai ulang SQL Server tidak ideal dalam lingkungan produksi aktif. Kami melewatkan sesuatu. Adakah yang lain melalui ini?
UPDATE: April-28-2012 Masih berjuang melawan masalah ini. Saya telah menurunkan memori untuk SQL Server menjadi 10 GB, hanya untuk mengesampingkan pertikaian dengan OS. Saya semakin dekat dengan mempersempitnya, tetapi butuh bantuan dari langkah selanjutnya.
Inilah yang saya temukan, setelah me-restart SQL Server, file halaman berkisar antara 12,3 GB dan 12,5 GB. Itu akan tetap seperti itu selama berhari-hari. Total utas server akan nongkrong di antara 850 dan 930 - juga stabil dan konsisten selama berhari-hari (sqlserver stabil antara 55 dan 85 yang tergantung pada lalu lintas).
Lalu, ada "sebuah acara". Saya tidak tahu apa acara itu, saya tidak bisa melihatnya di log, dan saya tidak bisa melihat sesuatu yang konsisten pada hari minggu atau waktu itu terjadi, tetapi semua suddent dia pagefile melompat ke 14.1 atau 14.2 GB, dan utas melompat ke antara 1750 dan 1785.
Memeriksa perfom ketika ini terjadi, lebih dari 900 di antaranya adalah sqlserver. Jadi saya pergi ke sp_who2 untuk melihat dari mana asal utas-utas ini ... dan hanya ada 80 koneksi db yang digunakan.
Jadi .... apakah ada yang punya ide bagaimana saya dapat menemukan di mana sisa 900 thread ini di SQL server, dan apa yang mereka lakukan?
UPDATE: Juni-01-2012 Masih berjuang melawan masalah ini. Bagi siapa pun yang membaca ini masih, masalah dengan utas melompat telah diatasi. Ini disebabkan oleh perangkat lunak cadangan ComVault yang diautodisasi. Itu membuat utas yang mencoba untuk membuat cadangan basis data yang sudah tidak ada lagi (itu mempertahankan daftar basis data sebelumnya) daripada hanya membuat cadangan basis data saat ini.
Tetapi - masalahnya masih ada, dan kita harus memulai kembali setiap minggu, memberi atau mengambil beberapa hari. Bekerja dengan tim Rackspace untuk melihat apakah mereka dapat menjelaskan.