SQL Server 2012 2008'den yavaş


15

Eski bir sunucudan (Windows 2008 / SQL Server 2008/16 GB RAM / 2 x 2.5 GHz Dört Çekirdekli / SAS diskler) büyük bir web sitesini ve veritabanını daha yeni, çok daha iyi bir sunucuya (Windows 2008 R2 / SQL Server 2012 SP1 / 64 GB RAM / 2 x 2,1 GHz 16 Çekirdekli işlemciler / SSD diskler).

Eski sunucudaki veritabanı dosyalarını ayırdım, kopyaladım ve yeni sunucuya iliştirdim. Her şey çok iyi gitti.

Bundan sonra, uyumluluk seviyesini 110 olarak güncelledim, güncellenmiş istatistikler, dizinleri yeniden oluşturdum.

Büyük hayal kırıklığım için, çoğu sql sorgusunun yeni SQL 2012 sunucusunda eski SQL 2008 sunucusundan çok daha yavaş (2-3-4 kat daha yavaş) olduğunu fark ettim.

Örneğin, yaklaşık 700 bin kayıt içeren bir tabloda, eski sunucuda dizin üzerindeki bir sorgu yaklaşık 100 ms sürdü. Yeni sunucuda, aynı sorgu yaklaşık 350 ms sürer.

Tüm sorgular için de aynı şey geçerlidir.

Burada bazı yardımları takdir ediyorum. Neyi kontrol edeceğim / doğrulayacağımı bana bildirin. Çünkü daha yeni bir SQL Server'a sahip daha iyi bir sunucuda performansın daha kötü olduğuna inanmak çok zor.

Daha fazla detay:

Bellek maks.

Bu tablo ve dizin var:

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]

Bu sorguyu yürüttüm:

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

ESKİ SUNUCU - SQL Server Yürütme Süreleri: CPU süresi = 419 ms, geçen süre = 695 ms.

YENİ SUNUCU - SQL Server Yürütme Süreleri: CPU süresi = 1340 ms, geçen süre = 1636 ms.

İDARİ PLANLAR buraya yüklendi: http://we.tl/ARbPuvf9t8

Daha sonra güncelleme:

  • AMD 2.1GHz Opteron 16 çekirdekli işlemciler, Intel 2.5GHz dört çekirdekli işlemcilerden çok daha kötü görünüyor
  • Dengeli pencereden yüksek güce değişen Windows güç seçeneklerini büyük iyileştirme
  • Maksimum paralellik derecesini 8'e ve maliyet eşiğini 4'e değiştiren daha fazla iyileştirme

Şimdi, SQL Server Yürütme Süreleri: CPU süresi = 550 ms, geçen süre = 828 ms.

Hala eski sunucudan daha kötü, ama o kadar da kötü değil. Başka önerileriniz varsa (yerel sorgu optimizasyonları dışında) lütfen yorum yapmaktan çekinmeyin.


Yorumlar uzun tartışmalar için değildir; bu görüşme sohbete taşındı .
Paul White 9

Yanıtlar:


8

SQL Server ile benzer sorunlar yaşadım, sunucunuzun en iyi şekilde yapılandırılmamış olması mümkündür. Yeni Xeonlar, sunucu performansını önemli ölçüde etkileyebilecek TurboBoost, HT vb.

Örneğin; Dell sunucuları için Düşük Gecikme Yapılandırması

Ayarlar, Dell olmayan sunucular için geçerli olacaktır, yalnızca farklı adlara sahip olabilirler.

Ayrıca Windows güç yönetimi profilini Balanced'den yüksek performansa ayarlayarak performansı geliştirdik. Son parça, x64 sunucularında işletim sistemi için 8GB'a kadar bellek ayırmanın önerilmesidir, varsayılan SQL yüklemesi tüm belleği alır. Maksimum SQL Server bellek yapılandırmanızı toplam bellekten 4 / 8GB daha az olarak ayarlayarak 4 / 8GB rezervasyonu denemek isteyebilirsiniz.

Benim tavsiyem, mümkünse eski sunucuya dönmek olacaktır. Regresyon / otomasyon / yükleme komut dosyalarınız yoksa, yapabileceğiniz en iyi şey, yüksek etkinlik döneminde 1-4 saat boyunca sistem etkinliğinizi kaydetmektir. Sonra üretim ile aynı bir web sunucusu ve komut dosyasını çalıştırmak için bir istemci makine ayarlayın. Aynı etkinliği yeni sunucuya karşı çalıştırın, yapılandırma değişikliğini yapın ve aynı etkinliği tekrar çalıştırın. Gerçekten çok daha fazlasını yapmak istersiniz, ancak bunun geçerli olacağı ve bu sorunun kapsamı dışında olduğu görülmemektedir.


Yük sunucudaki kadar yüksek değil. SQL Server genellikle 20-35 GB bellekte oturur. Her an 16 GB'den fazla boş belleğimiz vardı. Ayrıca işlemci% 10-15 oranında kullanımdan geçemez.
prog_sr08

2
Windows güç yönetimini dengeliden yüksek güce ayarlayarak şimdiye kadarki en büyük gelişme. Yani gerçekten bir işlemci problemi gibi görünüyor. SQL Server Yürütme Süreleri: CPU süresi = 892 ms, geçen süre = 874 ms.
prog_sr08

8

Neyi kontrol edeceğim / doğrulayacağımı bana bildir

Bir performans sorununuz var. Bekleme ve Kuyruklar gibi bir performans sorun giderme yöntemini izleyin tanımlamak için . Bağlantılı metodoloji size neyi ve nasıl ölçeceğinizi gösterir. Bulguları buraya gönderin ve gerçek ölçümlerinize göre özel tavsiyelerle yardımcı olabiliriz. Olduğu gibi çok açık ve herkesin tahminidir. Belirli bir konuya daraltmak tahmin çalışmasını ortadan kaldıracaktır.

Güncellemeden sonra

Planlar oldukça farklı. Eski plan, aslında kötü bir kardinalite tahmini (141k vs 108k) ve karma matematik daha da yanlış tahminler (35k vs. 108k) olan yığın üzerinde düşük bir akıma sahipti. Yeni plan, akış toplamına sahip değildir ve en üste kadar doğru tahminlere sahiptir. Tabii ki, bu eski planın neden daha hızlı yürütüldüğünü açıklamıyor .

Alt taramalar biraz farklı sıra numarasına (anlamlı değil) ancak oldukça farklı maliyetlere sahiptir: eski 2.49884 (IO 2.28979 CPU 0.20905) ve yeni 1.59109 (IO 1.53868 CPU 0.0524084). Yine daha iyi bir 2012 uygulamasına işaret edecektir (endeks yeniden inşası belki de parçalanmayı azaltmıştır?)

Çok farklı olan iş parçacığı sayısıdır: 32'de yeni (her biri ~ 23k satır alır) ve 8'de eski (her biri ~ 95k satır alır). Masa oldukça dardır. Çok daha fazla sayıda iş parçacığı, çok daha sık önbellek geçersiz kılmaları nedeniyle performansı gerçekten düşürüyor olabilir . Ben denemek istiyorum:

  1. yeni sunucu yapılandırmasındaki (varsa) HyperThreading'i ve / veya
  2. sorguyu bir DOP 8 ile deneyin.

Yorumunuzu fark ettiniz:

Maxdop 8 Query ile yürütme planı eklendi aslında bu şekilde daha hızlı

Muhtemelen sadece CPU'lar ayak parmaklarına basmaktadır. SSD'ler mevcut olduğunda, IO muhtemelen hiçbir şeyin yanında değildir ve tablo 32 tarayıcıyı garanti etmek için kesinlikle çok küçüktür. Bu takas değişikliği muhtemelen L1 / L2'yi sürekli geçersiz kılmaktadır.


1
2012'de her şey 2008'den çok daha yavaş. Buradaki sorguları optimize etmeye çalışmıyorum. Bu yeni sunucuda aynı veritabanıyla en azından aynı performansa sahip olmaktan memnuniyet duyarım.
prog_sr08

1
Bekleme ve kuyruklar sorguları optimize etmekle ilgili değildir. Darboğazları tanımlamakla ilgilidir.
Remus Rusanu

Belgeyi indirdim. Çok ilginç görünüyor. Şu an üzereyim, ama sanki biraz zaman alacak gibi görünüyor. İlk olarak nereye bakacağınızı önerebilir misiniz?
prog_sr08

1
bekleme istatistikleri . bunları 2008 ve 2012'de sıfırlayın, her ikisinde de 5-10 dakika yükü çalıştırın, ardından 2008 ve 2012 arasındaki farkları karşılaştırın.
Remus Rusanu

Korkarım ki şu an 2 sunucu arasındaki istatistikleri karşılaştıramıyorum, çünkü yeni sunucu canlı bir site / veritabanı barındırıyor. Eski sunucuda artık yük altında olmayan veritabanı kaldı.
prog_sr08

3

Çoğu modern çok çekirdekli sistemde ve özellikle çok işlemcili sistemlerde, donanım mimarisi, belirli bellek bölümlerinin belirli çekirdeklerden / işlemcilerden çok uzak ve belirli bellek bölümlerinin belirli çekirdeklere / işlemcilere yakın olacağı şekildedir. Buna Düzgün Olmayan Bellek Mimarisi veya kısaca NUMA denir. Belirli bir sayısal düğümün veri için kendi belleğinin dışına çıkma sayısını en aza indirmek için MAXDOP ayarınızın NUMA düğümü başına çekirdek sayısıyla eşleşmesini istiyorsunuz.

Yeni makinenizin yapılandırmasını kontrol etmek ve MAXDOP'un donanım açısından en iyi ayara ayarlandığından emin olmak için aşağıdakileri kullanabilirsiniz :

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

Belirtilen sunucu için uygun değerlere ve yapılandırma seçeneklerini @ServerRamInMBayarlamak için kullandığımdan parametreyi buraya dahil ettim .Max Server MemoryMin Server Memory


1
64 GB RAM, 32 işlemci çekirdeği, 4 numa düğümüm var. Maksimum paralellik derecesini 8 ve maliyet eşiğini 4 olarak ayarladım. Bu ayar ve güç seçeneği yüksek güce ayarlandığında, SQL Server Yürütme Süreleri: CPU süresi = 550 ms, geçen süre = 828 ms.
prog_sr08

Öyleyse bu bir kazanç, o zaman? Bunun sizin için uygun olduğunu gördüğüme sevindim!
Max Vernon

0

Hangi sürüm ve lisanslama modundasınız? Muhtemelen tüm çekirdekleri kullanmıyorsunuzdur. Bu sayfadaki nota bakın - http://msdn.microsoft.com/en-us/library/ms143760.aspx

"Sunucu + İstemci Erişim Lisanslı Kurumsal Sürüm (CAL) tabanlı lisanslama, SQL Server örneği başına maksimum 20 çekirdekle sınırlıdır."


2
Bu sadece daha önce CAL varsa ve büyükbabası varsa geçerli olurdu. Yine de sadece 20 çekirdekli bile performans eski sisteme (sadece 8 olan) belirgin bir şekilde düşmemelidir.
Aaron Bertrand

Web Sürümü var (4 Soket veya 16 çekirdekten daha azıyla sınırlı). Eski sunucuda ben zaten sadece 8 çekirdek vardı.
prog_sr08

0

Bu sayfada anlatılanla aynı sorunla karşılaştım: güç ayarlarının "dengeli" durumdan "yüksek performansa" geçişi, yanıt sürelerini ikiye katlamaktan çok dramatik bir fark yarattı. Şimdi SSD'leri kullandığım için enerji tüketiminin belki de olabileceğini düşünmüyorum.


-2

Ayrıca bu konuyu en az 2 hafta boyunca bir konuyu diğeriyle karıştırmak yerine sağlam bir çözüm olmadan geçirdim.

Sonunda aşağıdaki gibi çözünürlük: -

  1. Uyumluluğu 010'dan 011'e sıfırladım

  2. Ana veritabanının uyumluluğunu da sıfırlayın. Varsayılan olarak sql eski uyumluluk ayarını korur. Manuel olarak değiştirmemiz gerektiğini.

Herşey gönlünce olsun

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.