Daha fazla CPU ve RAM tahsis ettikten sonra daha yavaş SQL Server performansı

Sanal bir Windows 2008 R2 sunucusunda çalışan SQL Server 2008 R2 (10.50.1600) sahibiz. CPU'yu 1 çekirdekten 4'e ve RAM'i 4 gb'den 10 gb'ye yükselttikten sonra, performansın daha kötü olduğunu fark ettik.

Gördüğüm bazı gözlemler:

1. Çalışması <5 saniye sürdü bir sorgu şimdi> 200 saniye alıyor.
2. İşlemci, suçlu olarak sqlservr.exe ile 100'de sabitlenmiştir.
3. 4.6 milyon satırlık bir masadaki seçim sayımı (*) 90 saniyeden fazla sürdü.
4. Sunucuda çalışan işlemler değişmedi. Tek değişiklik CPU ve RAM'i arttırmaktı.
5. Diğer sql sunucuları, bu sunucuyu kendi başına yönetecek şekilde ayarlanmış statik bir disk belleği dosyasına sahiptir.

Bu konuyla daha önce karşılaşan var mı?

Sp_BlitzErik başına koştum

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

Bana bu sonuçları veriyor.

Burada çok şey oluyor ve çoğu oldukça geniş ve belirsiz.

1. 2008R2 RTM 21 Nisan 2010'da çıktı. Tamamen desteksiz kaldı. Günden yaklaşık 3 yıl önce çıkan en son Hizmet Paketine girmeye öncelik vermek istersiniz. Eğer garip bir böcek veya başka bir şeye çarpıyorsanız, bu şekilde karşılanacaksınız. Kafa buraya indirmeye gerek anlamaya.

2. VCPU'ları eklediğinizden (1'den 4'e kadar) ve hiçbir ayarı değiştirmediğinden, sorgularınız artık paralel olabilir. Kulağa daha hızlı olacak gibi geldiğini biliyorum, ama dayan!

3. RAM eklenmiş olabilirsiniz, ancak sunucunuzdan yararlanabilmesi için Maks. Sunucu Belleğini değiştirmemiş olabilirsiniz.

4. Sunucunuzun ne beklediğini bulun. Üzerinde çalıştığım açık kaynaklı bir proje, SQL Server'ınızı ölçmenize yardımcı olacak ücretsiz scriptler sunuyor. Üzerinde Baş buraya sen bir denemek istiyorsan.

Sunucunuzun bekleme istatistiklerini kontrol etmek için sp_BlitzFirst'i yakalamak istersiniz. Bunu birkaç yolla çalıştırabilirsin.

Bu, başlatıldığından beri sunucunuzun ne beklediğini size gösterir.

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

Bu, 30 saniyelik bir pencerede şu anda bekleyen sorguları gösterir.

EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;

Hangi sorguların beklediğini bulduğunuzda (orada bekleme istatistikleri hakkında yazılmış bir sürü şey var), kontrol altına almak için değişiklikler yapmaya başlayabilirsiniz.

Onları beklediğini görüyorsanız CXPACKET, bu, sorgularınızın paralel hale geldiği ve belki de birbirlerinin üzerinde dolaştığı anlamına gelir. Buna çarptıysanız, muhtemelen Parallelism için Maliyet Eşiğini 50'ye kadar düşürmeyi ve MAXDOP'u 2'ye düşürmeyi düşünebilirsiniz.

Bu adımdan sonra, sorgu planlarını yakalamaya başlamak için sp_WhoIsActive veya sp_BlitzWho (ikincisi GitHub deposunda) gibi bir şey kullanmak istediğinizde olur . Bekleme istatistiklerinin yanı sıra, neyin yanlış gittiğini anlamak için bakabileceğiniz en önemli şeylerden biri.

Ayrıca , SQL Server ile ilgili olarak check-out yapmak için Jonathan Kehayias'ın VMWare Sayaçları hakkında yazdığı makaleye de bakabilirsiniz .

Güncelleştirme

Bekleme istatistiklerine bakılırsa oğlanlar tuhaflar. İşlemcilerde kesinlikle bir şeyler var. Sunucunuz çoğunlukla oturuyor ve sıkılıyor, ancak işler ısındığında işler kötüleşiyor. Bunu kolayca parçalamaya çalışacağım.

1. Bir zehir bekliyorsunuz diye adlandırıyorsunuz THREADPOOL. Bir tonunuz yok, ancak bu mantıklı çünkü sunucunuz çok aktif değil. Neden bir dakika içinde açıklayacağım.

2. Üzerinde gerçekten uzun ortalama beklediği sahip SOS_SCHEDULER_YIELDve CXPACKET. Sanal makinedesin, yani SQL Server'ın çekinceleri olduğundan veya kutunun çok fazla abonelikten çıkmadığından emin olmak isteyeceksin. Gürültülü bir komşu burada gününüzü gerçekten mahvedebilir. Ayrıca, sunucu / VM konuğu / VM sunucusunun Dengeli Güç modunda çalışmadığından emin olmak isteyeceksiniz. Bu, CPU'larınızın gereksiz yere düşük hızlara dönmesini sağlar ve hemen tam hıza dönmezler.

3. Nasıl bağlanırlar? 4 işlemciyle 512 iş parçacığına sahipsiniz. Unutmayın, tek bir CPU ile aynı miktarda kullandınız , ancak şimdi sorgularınız paralel gidebiliyorsa, çok daha fazla çalışan iş parçacığı tüketebilirler. Senin durumunda bir paralel sorgunun paralel dalı başına 4 konu.

Ne paralel gidiyor? Büyük olasılıkla her şey. Paralellik için varsayılan Maliyet Eşik numara baktım bir masaüstü çalışma 90'lı yılların sonunda varsayılan ara uygun yapıldığı İşte 5. olduğunu böyle .

Verilmiş, donanımınız çoğu dizüstü bilgisayardan daha küçük, ancak hala bu şeyin biraz ötesindesiniz.

Çok sayıda paralel sorgu olduğunda, bu çalışan iş parçacığı bitiyor. Bu olduğunda, sorgular sadece iş parçacığının gitmesini beklerken oturuyor. Burası aynı zamanda SOS_SCHEDULER_YIELDdevreye giriyor. Sorgu CPU'ları atlatıyor ve uzun süre geri dönmüyor. Herhangi bir engelleme bekleyişi göremiyorum, bu yüzden büyük olasılıkla hepiniz sorgu içi paralellik bekleyişlerini dolduruyorsunuz.

Ne yapabilirsin?

1. Balanced Power modunda hiçbir şeyin bulunmadığından emin olun.
2. MAXDOP değerini 2 olarak değiştirin.
3. Paralellik için maliyet eşiğini 50 olarak değiştir
4. VM sağlığını doğrulamak için yukarıdaki Jon K. makalesini takip edin
5. sp_BlitzIndexEksik dizin isteklerini aramak için çağrılan komut dosyasını kullanın .

Daha ayrıntılı sorun giderme için Google’da bulutta donanım boyutlandırma konusunda yazdığım teknik incelemeye bakın .

Bu yardımcı olur umarım!

Evet! Bu tür durumları, sunucu grubumuzdaki SQL Server vms'de yaşadım. Vm'nin ana CPU hazır zamanına ve hafıza balonu sürücüsü sayaçlarına bakın. CPU HAZIR ZAMAN - BLOG BÖLÜM I ve VMware Balonculuğunu Anlamak sysadmin ile çalışmak çok önemliydi ama kolay değildi ...

Görmediğim bir şey var ki, bir VM'ye vCPU'ların eklenmesi, zamanlama nedeniyle onu çok yavaşlatabilir.

Temel fikir, eğer bir VM'nin 4 vCPU'su varsa, o zaman hipervizörün 4 fiziksel çekirdeği olmasını beklemesi gerekir, böylece 3 tanesi boşta olsa bile, tüm vCPU'ları programlayabilir.

Ana makinenizde çok fazla çekirdek yoksa ve diğer iş yükleriniz meşgulse, bu daha fazla beklemeye ve performansta önemli bir düşüşe neden olabilir.

VMware ESXi'de CPU Ready ile gelişmiş grafiklerde görebilirsiniz.

İşte bunun gerçek dünya örneğini ve nasıl teşhis edildiğini gösteren birçok makaleden biri .

Daha fazla RAM eklemek, VM'nin RAM ayırması bir NUMA düğümünden daha büyükse, ani bir performans düşüşüne neden olabilir.

Ayrıca, vCPU'larınızın yapılandırması (vSockets vs. vCores) aslında SQL server gibi bazı uygulamaları etkileyebilir. Bunun nedeni, SQL sunucunun NUMA konusunda farkında olması (aynı NUMA yayılma performansı düşüşünden kaçınmak için) ve VMware'in sanal NUMA düğümlerini farklı şekilde sunması olabilir.

Bu, VMware'in kendi sitesindeki bir blog yazısında yer almaktadır .

Bu söyleniyor, Erik'in yardımı ile sorunları çözdüğünüze sevindim, ama bunlara da bakmak isteyebilirsiniz.

Sadece sp_BlitzErik'in cevabını devam ettirerek küçük bir yardım (bunu yorum olarak gönderemiyorum), Pinal ve Max Vernon ile ne kadar MAXDOP kullanmanız gerektiğini söyleyen bazı soruları aldım:

/*************************************************************************
Author          :   Kin Shah
Purpose         :   Recommend MaxDop settings for the server instance
Tested RDBMS    :   SQL Server 2008R2

**************************************************************************/
declare @hyperthreadingRatio bit
declare @logicalCPUs int
declare @HTEnabled int
declare @physicalCPU int
declare @SOCKET int
declare @logicalCPUPerNuma int
declare @NoOfNUMA int

select @logicalCPUs = cpu_count -- [Logical CPU Count]
    ,@hyperthreadingRatio = hyperthread_ratio --  [Hyperthread Ratio]
    ,@physicalCPU = cpu_count / hyperthread_ratio -- [Physical CPU Count]
    ,@HTEnabled = case 
        when cpu_count > hyperthread_ratio
            then 1
        else 0
        end -- HTEnabled
from sys.dm_os_sys_info
option (recompile);

select @logicalCPUPerNuma = COUNT(parent_node_id) -- [NumberOfLogicalProcessorsPerNuma]
from sys.dm_os_schedulers
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64
group by parent_node_id
option (recompile);

select @NoOfNUMA = count(distinct parent_node_id)
from sys.dm_os_schedulers -- find NO OF NUMA Nodes 
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64

-- Report the recommendations ....
select
    --- 8 or less processors and NO HT enabled
    case 
        when @logicalCPUs < 8
            and @HTEnabled = 0
            then 'MAXDOP setting should be : ' + CAST(@logicalCPUs as varchar(3))
                --- 8 or more processors and NO HT enabled
        when @logicalCPUs >= 8
            and @HTEnabled = 0
            then 'MAXDOP setting should be : 8'
                --- 8 or more processors and HT enabled and NO NUMA
        when @logicalCPUs >= 8
            and @HTEnabled = 1
            and @NoofNUMA = 1
            then 'MaxDop setting should be : ' + CAST(@logicalCPUPerNuma / @physicalCPU as varchar(3))
                --- 8 or more processors and HT enabled and NUMA
        when @logicalCPUs >= 8
            and @HTEnabled = 1
            and @NoofNUMA > 1
            then 'MaxDop setting should be : ' + CAST(@logicalCPUPerNuma / @physicalCPU as varchar(3))
        else ''
        end as Recommendations

-------------------------------------------------- -------

--MAX VERNON 

/* 
   This will recommend a MAXDOP setting appropriate for your machine's NUMA memory
   configuration.  You will need to evaluate this setting in a non-production 
   environment before moving it to production.

   MAXDOP can be configured using:  
   EXEC sp_configure 'max degree of parallelism',X;
   RECONFIGURE

   If this instance is hosting a Sharepoint database, you MUST specify MAXDOP=1 
   (URL wrapped for readability)
   http://blogs.msdn.com/b/rcormier/archive/2012/10/25/
   you-shall-configure-your-maxdop-when-using-sharepoint-2013.aspx

   Biztalk (all versions, including 2010): 
   MAXDOP = 1 is only required on the BizTalk Message Box
   database server(s), and must not be changed; all other servers hosting other 
   BizTalk Server databases may return this value to 0 if set.
   http://support.microsoft.com/kb/899000
*/
SET NOCOUNT ON;

DECLARE @CoreCount int;
SET @CoreCount = 0;
DECLARE @NumaNodes int;

/*  see if xp_cmdshell is enabled, so we can try to use 
    PowerShell to determine the real core count
*/
DECLARE @T TABLE (
    name varchar(255)
    , minimum int
    , maximum int
    , config_value int
    , run_value int
);
INSERT INTO @T 
EXEC sp_configure 'xp_cmdshell';
DECLARE @cmdshellEnabled BIT;
SET @cmdshellEnabled = 0;
SELECT @cmdshellEnabled = 1 
FROM @T
WHERE run_value = 1;
IF @cmdshellEnabled = 1
BEGIN
    CREATE TABLE #cmdshell
    (
        txt VARCHAR(255)
    );
    INSERT INTO #cmdshell (txt)
    EXEC xp_cmdshell 'powershell -OutputFormat Text -NoLogo -Command "& {Get-WmiObject -namespace "root\CIMV2" -class Win32_Processor -Property NumberOfCores} | select NumberOfCores"';
    SELECT @CoreCount = CONVERT(INT, LTRIM(RTRIM(txt)))
    FROM #cmdshell
    WHERE ISNUMERIC(LTRIM(RTRIM(txt)))=1;
    DROP TABLE #cmdshell;
END
IF @CoreCount = 0 
BEGIN
    /* 
        Could not use PowerShell to get the corecount, use SQL Server's 
        unreliable number.  For machines with hyperthreading enabled
        this number is (typically) twice the physical core count.
    */
    SET @CoreCount = (SELECT i.cpu_count from sys.dm_os_sys_info i); 
END

SET @NumaNodes = (
    SELECT MAX(c.memory_node_id) + 1 
    FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64
    );

DECLARE @MaxDOP int;

/* 3/4 of Total Cores in Machine */
SET @MaxDOP = @CoreCount * 0.75; 

/* if @MaxDOP is greater than the per NUMA node
    Core Count, set @MaxDOP = per NUMA node core count
*/
IF @MaxDOP > (@CoreCount / @NumaNodes) 
    SET @MaxDOP = (@CoreCount / @NumaNodes) * 0.75;

/*
    Reduce @MaxDOP to an even number 
*/
SET @MaxDOP = @MaxDOP - (@MaxDOP % 2);

/* Cap MAXDOP at 8, according to Microsoft */
IF @MaxDOP > 8 SET @MaxDOP = 8;

PRINT 'Suggested MAXDOP = ' + CAST(@MaxDOP as varchar(max));