SQL Server 2012 lebih lambat dari 2008


15

Saya memigrasikan situs web besar dan basis data dari server lama (Windows 2008 / SQL Server 2008/16 GB RAM / 2 x 2,5 GHz Quad Core / SAS disk) ke server yang lebih baru, jauh lebih baik (Windows 2008 R2 / SQL Server 2012 SP1 / 64 GB RAM / 2 x 2.1 GHz 16 Prosesor inti / disk SSD).

Saya memisahkan file database di server lama, menyalin dan melampirkannya di server baru. Semuanya berjalan dengan sangat baik.

Setelah itu, saya mengubah ke tingkat kompatibilitas ke 110, memperbarui statistik, membangun kembali indeks.

Untuk kekecewaan besar saya, saya perhatikan bahwa sebagian besar permintaan sql jauh lebih lambat (2-3-4 kali lebih lambat) pada server SQL 2012 baru daripada pada server SQL 2008 yang lama.

Misalnya, di atas meja dengan sekitar 700 ribu catatan, pada server lama kueri pada indeks membutuhkan sekitar 100 ms. Di server baru, permintaan yang sama membutuhkan waktu sekitar 350 ms.

Hal yang sama terjadi untuk semua permintaan.

Saya akan sangat menghargai bantuan di sini. Beri tahu saya apa yang harus diperiksa / verifikasi. Karena saya merasa sangat sulit untuk percaya bahwa pada server yang lebih baik dengan SQL Server yang lebih baru, kinerjanya lebih buruk.

Keterangan lebih lanjut:

Memori diatur ke maks.

Saya punya tabel dan indeks ini:

CREATE TABLE [dbo].[Answer_Details_23](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [SurveyID] [int] NOT NULL,
    [CustomerID] [int] NOT NULL default 0,
    [SummaryID] [int] NOT NULL,
    [QuestionID] [int] NOT NULL,
    [RowID] [int] NOT NULL default 0,
    [OptionID] [int] NOT NULL default 0,
    [EnteredText] [ntext] NULL,
 CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
    [SummaryID] ASC,
    [QuestionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

Saya menjalankan kueri ini:

set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;

SERVER LAMA - Waktu Eksekusi SQL Server: Waktu CPU = 419 ms, waktu yang berlalu = 695 ms.

SERVER BARU - Waktu Eksekusi SQL Server: Waktu CPU = 1340 ms, waktu yang berlalu = 1636 ms.

RENCANA EKSEKUSI yang diunggah di sini: http://we.tl/ARbPuvf9t8

Pembaruan selanjutnya:

  • AMD 2.1GHz Opteron 16 core processor terlihat jauh lebih buruk daripada Intel 2.5GHz quad core
  • Perbaikan hebat mengubah opsi daya windows dari ballanced ke high power
  • Peningkatan lebih lanjut mengubah derajat maks paralelisme ke 8 dan ambang biaya ke 4

Sekarang, Waktu Eksekusi SQL Server: Waktu CPU = 550 ms, waktu yang berlalu = 828 ms.

Ini masih lebih buruk dari server lama, tetapi tidak terlalu buruk. Jika Anda memiliki saran lain (selain optimasi kueri lokal), jangan ragu untuk berkomentar.


Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Paul White Reinstate Monica

Jawaban:


8

Saya memiliki masalah serupa dengan SQL Server, mungkin server Anda tidak dikonfigurasi secara optimal. Xeon yang lebih baru hadir dengan TurboBoost, HT, dll. Yang dapat memengaruhi kinerja server secara signifikan.

Sebagai contoh, kami telah sukses dengan; Konfigurasi Latensi Rendah untuk server Dell

Pengaturan akan berlaku untuk server non-Dell, mereka mungkin memiliki nama yang berbeda.

Kami juga meningkatkan kinerja dengan mengatur profil manajemen daya windows ke kinerja tinggi, dari Balanced. Bagian terakhir adalah bahwa disarankan untuk menyimpan hingga 8GB memori untuk OS pada server x64, instalasi SQL default mengambil semua memori. Anda mungkin ingin mencoba reservasi 4 / 8GB dengan mengatur konfigurasi memori SQL Server maks Anda menjadi 4 / 8GB kurang dari total memori.

Rekomendasi saya adalah kembali ke server lama jika memungkinkan. Jika Anda tidak memiliki skrip regresi / otomatisasi / muat yang tersedia, maka yang terbaik yang dapat Anda lakukan adalah mencatat aktivitas sistem Anda selama 1-4 jam selama periode aktivitas tinggi. Kemudian atur server web sama dengan produksi, dan mesin klien untuk menjalankan skrip. Jalankan aktivitas yang sama terhadap server baru, buat konfigurasi berubah dan jalankan aktivitas yang sama lagi. Sungguh Anda ingin melakukan lebih banyak, tetapi tampaknya itu tidak layak dan berada di luar cakupan pertanyaan ini.


Beban tidak terlalu tinggi di server. SQL Server biasanya berada dalam memori 20-35 GB. Setiap saat kami memiliki lebih dari 16 GB memori bebas. Prosesor juga biasanya tidak melewati penggunaan 10-15%.
prog_sr08

2
Peningkatan terbesar sejauh ini dicapai dengan mengatur manajemen daya windows dari seimbang ke daya tinggi. Jadi sepertinya masalah prosesor. Waktu Eksekusi SQL Server: Waktu CPU = 892 ms, waktu yang berlalu = 874 ms.
prog_sr08

8

Beri tahu saya apa yang harus diperiksa / verifikasi

Anda memiliki masalah kinerja. Ikuti metodologi pemecahan masalah kinerja seperti Tunggu dan Antrian untuk mengidentifikasi hambatan. Metodologi yang ditautkan menunjukkan kepada Anda apa yang harus diukur dan bagaimana. Posting di sini temuan dan kami dapat membantu dengan saran khusus berdasarkan pengukuran Anda yang sebenarnya. Karena terlalu terbuka dan siapa pun bisa menebak. Mempersempitnya ke masalah tertentu akan menghilangkan dugaan.

Setelah pembaruan

Rencananya sangat berbeda. Rencana lama memiliki agregat aliran rendah pada tumpukan yang sebenarnya memiliki perkiraan kardinalitas yang buruk (141k vs 108k) dan matematika hash lebih lanjut salah duga, sebaliknya (35k vs 108k). Paket baru tidak memiliki agregat aliran dan memiliki perkiraan yang akurat sampai ke puncak. Tentu saja, ini tidak menjelaskan mengapa rencana lama dieksekusi lebih cepat .

Pemindaian bawah memiliki nomor baris yang sedikit berbeda (tidak signifikan) tetapi biaya yang sangat berbeda: lama adalah 2.49884 (IO 2.28979 CPU 0.20905) vs 1.59109 baru (IO 1.53868 CPU 0.0524084). Sekali lagi akan mengarah pada eksekusi 2012 yang lebih baik (pembangunan kembali indeks mungkin telah mengurangi fragmentasi?).

Yang sangat berbeda adalah jumlah utas: 32 di baris baru (masing-masing mendapat ~ 23rb) vs. 8 di baris lama (masing-masing mendapat ~ baris 95k). Tabelnya cukup sempit. Ini bisa jadi bahwa sejumlah besar benang sebenarnya menyakiti kinerja karena banyak lebih sering invalidations tembolok . Aku akan mencoba:

  1. menghilangkan HyperThreading di konfigurasi server baru (jika ada) dan / atau
  2. coba kueri dengan DOP 8.

Memperhatikan komentar Anda:

Menambahkan rencana eksekusi dengan maxdop 8 Query sebenarnya lebih cepat dengan cara ini

Mungkin hanya CPU yang saling menginjak jari kaki. Dengan SSD yang terpasang, IO mungkin hampir tidak ada sehingga dan tabelnya pasti terlalu kecil untuk menjamin 32 scanner. Pertukaran swap itu mungkin membuat L1 / L2 tidak valid terus-menerus.


1
Semuanya jauh lebih lambat pada 2012 dibandingkan tahun 2008. Saya tidak mencoba mengoptimalkan kueri di sini. Saya akan senang memiliki setidaknya kinerja yang sama dengan database yang sama persis di server baru ini.
prog_sr08

1
Tunggu dan antrian bukan tentang mengoptimalkan kueri. Tentang mengidentifikasi kemacetan.
Remus Rusanu

Saya mengunduh dokumen. Terlihat sangat menarik. Saya sedang mengerjakannya sekarang, tetapi sepertinya itu akan memakan waktu beberapa saat. Bisakah Anda menyarankan ke mana harus mencari dulu?
prog_sr08

1
tunggu statistik . atur ulang keduanya pada 2008 dan 2012, jalankan beban selama 5-10 menit pada keduanya, lalu bandingkan perbedaan antara 2008 dan 2012.
Remus Rusanu

Saya khawatir saya tidak dapat membandingkan statistik antara 2 server sekarang, karena server baru meng-host situs / database langsung. Di server lama tetap database yang tidak di-load lagi.
prog_sr08

3

Untuk sebagian besar sistem multi-core modern, dan khususnya sistem multi-cpu, arsitektur perangkat keras sedemikian rupa sehingga bagian memori tertentu jauh dari inti / prosesor tertentu, dan bagian memori tertentu dekat dengan inti / prosesor tertentu. Ini disebut sebagai Arsitektur Memori Non-Seragam, atau singkatnya NUMA. Anda ingin pengaturan MAXDOP Anda mencocokkan jumlah core per NUMA node untuk meminimalkan berapa kali numa node yang diberikan perlu pergi ke luar memori sendiri untuk data.

Anda dapat menggunakan yang berikut ini untuk memeriksa konfigurasi mesin baru Anda, dan memastikan MAXDOP diatur ke pengaturan terbaik, berdasarkan perangkat keras :

DECLARE @CPUs int;
DECLARE @NumaNodes int;
DECLARE @ServerRAMInMB int;

SET @ServerRAMinMB = (SELECT (i.physical_memory_kb / 1024) AS ServerMemory 
    FROM sys.dm_os_sys_info i);
SET @CPUs = (SELECT i.cpu_count from sys.dm_os_sys_info i);
SET @NumaNodes = (SELECT MAX(c.memory_node_id) + 1 FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64);

SELECT @ServerRamInMB, @CPUs, @NumaNodes;

IF @CPUs > 4 /* this would be 4 cores, not 4 CPUs */
BEGIN
    DECLARE @MaxDOP int;
    SET @MaxDOP = @CPUs * 0.75;
    IF @MaxDOP > (@CPUs / @NumaNodes) SET @MaxDOP = (@CPUs / @NumaNodes);
    EXEC sp_configure 'max degree of parallelism', @MaxDOP;
    EXEC sp_configure 'cost threshold for parallelism', 4; 
END

Saya menyertakan @ServerRamInMBparameter di sini karena saya menggunakannya untuk mengatur Max Server Memorydan Min Server Memoryopsi konfigurasi ke nilai yang sesuai untuk server yang diberikan.


1
Saya memiliki 64 GB RAM, 32 inti prosesor, 4 numa node. Saya mengatur derajat maks paralelisme ke 8 dan ambang biaya ke 4. Dengan pengaturan ini dan dengan opsi daya diatur ke daya tinggi, Waktu Eksekusi SQL Server: Waktu CPU = 550 ms, waktu yang berlalu = 828 ms.
prog_sr08

Jadi itu kemenangan, kalau begitu? Senang melihat itu bekerja untuk Anda!
Max Vernon

0

Apa edisi dan mode lisensi Anda berada? Anda mungkin tidak menggunakan semua inti. Lihat catatan di halaman ini - http://msdn.microsoft.com/en-us/library/ms143760.aspx

"Edisi Enterprise dengan lisensi berbasis Server + Lisensi Akses Klien (CAL) terbatas hingga maksimum 20 core per instance SQL Server."


2
Ini hanya akan berlaku jika dia memiliki CAL sebelumnya dan kakeknya. Masih dengan hanya 20 core kinerja tidak boleh turun secara nyata di atas sistem sebelumnya (yang hanya memiliki 8).
Aaron Bertrand

Saya memiliki Edisi Web (Terbatas untuk kurang dari 4 Soket atau 16 core). Di server lama saya hanya punya 8 core.
prog_sr08

0

Saya memiliki masalah yang sama dengan yang dijelaskan di halaman ini: beralih pengaturan daya dari "seimbang" ke "kinerja tinggi" membuat perbedaan dramatis - lebih dari dua kali lipat waktu respons. Sekarang kita menggunakan SSD, saya tidak berpikir konsumsi energi adalah masalah yang mungkin terjadi.


-2

Saya juga telah melalui masalah ini selama setidaknya 2 minggu tanpa resolusi yang kuat daripada membingungkan satu masalah dengan yang lain.

Akhirnya resolusinya sebagai berikut: -

  1. Saya telah mengatur ulang kompatibilitas dari 010 hingga 011

  2. Setel ulang kompatibilitas database master juga. Secara default sql akan mempertahankan pengaturan kompatibilitas yang lama. Itu yang perlu kita ubah secara manual.

Semua yang terbaik

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.