Kinerja lebih buruk di server baru


11

Kami telah berada di server khusus (quad-core tunggal, 6 GB RAM) dan sedang pindah ke server khusus baru (2x hex-core, 32 GB RAM). Keduanya adalah Windows Server 2008, SQL Server 2008. Kinerja pada server baru sedikit lebih buruk daripada server lama yang lebih lambat.

Dalam pengujian, aplikasi ASP.NET kami berjalan 10 - 20% lebih lambat. Menjalankan kueri mahal individual dengan STATISTIK IO dan STATISTIK TIME menunjukkan 10 - 20% waktu berlalu yang lebih besar di server baru. Profil SQL Query menunjukkan penggunaan CPU yang lebih tinggi pada permintaan yang mahal.

Task Manager pada server baru menunjukkan sqlserver.exe mengkonsumsi 22 GB RAM, tetapi nilai CPU selalu tetap sangat rendah.

Saya telah memperbarui semua statistik, indeks yang dibangun kembali atau direorganisasi, dll. Rencana pelaksanaan harus disimpan pada server baru pada saat ini, mengingat jumlah pengujian yang telah saya lakukan. Jika ada indeks yang hilang (saya tidak berpikir ada) mereka mempengaruhi server lama dan baru sama. Baru memiliki cadangan yang dipulihkan dari data yang sama pada yang lama.

Saya berharap bahwa kinerja pada server baru akan lebih baik, tetapi yang lebih penting adalah beban. Jika server lama berkinerja lebih baik bahkan di bawah beban, lalu apa yang akan terjadi ketika server baru ini, yang sedikit lebih buruk, harus mengambil beban itu?

Apa lagi yang bisa saya lewatkan di sini?

EDIT: MAXDOP diatur ke 6.

Server lama memiliki OS, database, dan tempdb pada drive fisik yang sama (RAID 10). Total 4 15k 3 Gb / s 3,5 inci SAS. Server baru memiliki tiga set drive: OS pada RAID 1, database pada RAID 10, tempdb pada RAID 5. Total 9 15K 6 Gb / s 2,5 Inch SAS.

Server lama memiliki 1 x Intel Xeon E5620 2,40 GHz Quad-Core 8 Threads (w H / T). Server baru memiliki 2 x Intel Xeon E5-2640 2,5 GHz Enam-Core 12 Thread (w H / T).

EDIT 2: Inilah analisis terakhirnya:

Rencana kekuatannya seimbang, bukan kinerja tinggi. Mengalihkannya.

Tempdb menggunakan RAID 5, bukan RAID 10. Menambahkan HD lain untuk membuat dua konfigurasi RAID 10 yang berbeda secara fisik, satu untuk tempdb dan satu untuk yang lainnya.

File terkait SQL yang dikecualikan (mdf, ldf, ndf, bak) dari pemindaian virus.

Buat ulang semua indeks setelah pindah ke server baru. Mereka sangat terfragmentasi - mungkin karena cadangan, salin, pulihkan?

Dan saya menyadari bahwa lompatan prosesor tidak sebesar itu. Kueri tidak akan mengeksekusi lebih cepat, tetapi dengan lebih banyak prosesor, lebih banyak core, lebih banyak RAM, kami akan lebih terukur.


Selain rencana daya O / S, ada juga pengaturan BIOS terkait: stackoverflow.com/a/27807572/538763
crokusek

Jawaban:


11

Raid 5 lebih lambat dari raid 10, terutama untuk beban kerja tulis-berat. Karena itu, umumnya tidak disarankan untuk SQL server dan tentu saja tidak untuk tempdb. Ini saja dapat dengan mudah menjelaskan perbedaan kinerja.

Rekomendasi saya adalah memindahkan tempdb ke raid 10.


4

Ini adalah masalah yang sangat umum, jadi sulit untuk memberikan saran khusus. Tetapi, jika saya berada dalam situasi ini, saya akan mulai dari dasar-dasar, memeriksa pertanyaan paling mahal. Fungsi apa yang lebih lama? Apa yang paling menghabiskan waktu apa yang Anda jalankan kueri dengan waktu statistik? Setelah Anda mempersempit fokus Anda, Anda dapat membandingkan beberapa hal dengan server lama. Juga, sesuatu untuk diperiksa, adalah untuk memastikan bahwa kedua server berada pada level patch yang sama (SQL dan Windows).


3

Nah, Anda tidak mengatakan apa pun tentang hard disk dan jumlah file tempdb yang Anda miliki. Ada rekomendasi umum bahwa nr tempdb = jumlah core hingga 32, ada juga saklar untuk melempar untuk memastikan bahwa temp dbs digunakan sama.

Namun dalam: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data- file-per-prosesor-core.aspx juga sudahkah Anda mengubah kemasan untuk tabel dan indeks selama migrasi? Cadangkan dan pulihkan dapat berakhir secara default ke padding berbeda pada indeks (termasuk yang berkerumun)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.