it-swarm-eu.dev

SQL Server 2012 pomalejší než 2008

Migroval jsem velký web a databázi ze staršího serveru (Windows 2008/SQL Server 2008/16 GB RAM/2 x 2,5 GHz Quad Core/SAS disky) ) na novější, mnohem lepší server (Windows 2008 R2/SQL Server 2012 SP1/64 GB RAM/2 x 2,1 GHz 16 jádrových procesorů/SSD disky).

Odpojil jsem databázové soubory na starém serveru, zkopíroval a připojil je k novému serveru. Všechno šlo velmi dobře.

Poté jsem se přepnul na úroveň kompatibility na 110, aktualizované statistiky, znovu vytvořili indexy.

K mému velkému zklamání jsem si všiml, že většina dotazů na SQL je na novém serveru SQL 2012 mnohem pomalejší (2-3–4krát pomaleji) než na starém serveru SQL 2008.

Například v tabulce s přibližně 700 000 záznamy trvalo na starém serveru dotaz na index okolo 100 ms. Na novém serveru trvá stejný dotaz přibližně 350 ms.

Totéž se stane pro všechny dotazy.

Ocenil bych nějakou pomoc zde. Dejte mi vědět, co zkontrolovat/ověřit. Protože je pro mě velmi těžké uvěřit, že na lepším serveru s novějším serverem SQL je výkon horší.

Více informací:

Paměť je nastavena na max.

Mám tuto tabulku a index:

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]

Tento dotaz jsem provedl:

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

STARÝ SERVER - Časy provádění serveru SQL: Čas CPU = 419 ms, uplynulý čas = 695 ms.

NOVÝ SERVER - Časy provádění serveru SQL: Čas CPU = 1340 ms, uplynulý čas = 1636 ms.

PLÁNY PRO PROVEDENÍ nahrané zde: http://we.tl/ARbPuvf9t8

Pozdější aktualizace:

  • Jádrové procesory AMD 2.1GHz Opteron 16 vypadají mnohem horší než čtyřjádrové procesory Intel 2,5 GHz
  • Velké zlepšení měnící možnosti napájení oken z vyváženého na vysoký výkon
  • Další vylepšení mění maximální stupeň rovnoběžnosti na 8 a práh nákladů na 4

Nyní časy spuštění serveru SQL: Čas CPU = 550 ms, uplynulý čas = 828 ms.

Je to stále horší než starý server, ale není to tak špatné. Pokud máte nějaké další návrhy (jiné než lokální optimalizace dotazů), neváhejte se vyjádřit.

16
prog_sr08

Mám podobné problémy se serverem SQL, je možné, že váš server není optimálně nakonfigurován. Novější Xeony přicházejí s TurboBoost, HT atd., Které mohou výrazně ovlivnit výkon serveru.

Například jsme měli úspěch; Konfigurace s nízkou latencí pro servery Dell

Nastavení se bude vztahovat na servery jiných společností než Dell, pouze mohou mít různá jména.

Rovněž jsme vylepšili výkon nastavením profilu správy napájení systému Windows na vysoký výkon, od společnosti Balanced. Poslední část je, že je doporučeno vyhradit až 8 GB paměti pro OS na x64 serverech, výchozí instalace SQL vezme veškerou paměť. Možná budete chtít vyzkoušet rezervaci 4/8 GB nastavením maximální konfigurace paměti serveru SQL na 4/8 GB méně než celková paměť.

Mým doporučením by bylo vrátit se ke starému serveru, pokud je to možné. Pokud nemáte k dispozici regresní/automatizační/načtovací skripty, pak nejlepší, co můžete udělat, je zaznamenat aktivitu systému po dobu 1-4 hodin během období vysoké aktivity. Poté nastavte webový server stejně jako produkci a klientský počítač ke spuštění skriptu. Spusťte stejnou aktivitu proti novému serveru, změňte konfiguraci a znovu spusťte stejnou aktivitu. Opravdu byste chtěli udělat mnohem víc, ale nezdá se, že by to bylo proveditelné a je mimo rozsah této otázky.

8
AceCTO

Dejte mi vědět, co zkontrolovat/ověřit

Máte problém s výkonem. Postupujte podle metodiky řešení problémů s výkonem, jako je Waits and Queues a identifikujte překážku. Propojená metodika ukazuje, co měřit a jak. Zveřejněte zde zjištění a my vám můžeme pomoci s konkrétními radami založenými na vašich skutečných měřeních. Protože je příliš otevřený a někdo hádá. Zúžení na konkrétní problém eliminuje hádání.

Po aktualizaci

Plány jsou zcela odlišné. Starý plán měl nízký součet proudů na stacku, který má ve skutečnosti špatný odhad kardinality (141k vs. 108k) a hashova matematika dále mylně předpovídá, naopak (35k vs. 108k). Nový plán nemá agregovaný proud a má přesné odhady až na vrchol. To samozřejmě nevysvětluje, proč byl starý plán prováděn rychleji .

Dolní skenování má mírně odlišné číslo řádku (není významné), ale zcela odlišné náklady: starý je 2.49884 (IO 2.28979 CPU 0.20905) vs nový 1.59109 (IO 1.53868 CPU 0,05524084). Opět by to ukazovalo na lepší provedení v roce 2012 (přestavba indexu možná snížila fragmentaci?).

Velmi rozdílný je počet vláken: 32 v nových (každý získává ~ 23 000 řádků) oproti 8 ve starých (každý získává ~ 95 000 řádků). Stůl je poměrně úzký. Mohlo by to znamenat, že velký počet vláken skutečně poškozuje výkon kvůli mnohem častějším zrušení platnosti mezipaměti . Chtěl bych zkusit:

  1. eliminovat HyperThreading v nové konfiguraci serveru (pokud existuje) a/nebo
  2. zkuste dotaz pomocí DOP 8.

Všiml jsem si vašeho komentáře:

Přidaný plán provádění s programem maxdop 8 Query je tímto způsobem skutečně rychlejší

Pravděpodobně jde jen o CPU šlápnutí na sebe. S SSD na místě je IO) pravděpodobně téměř nic a tabulka je rozhodně příliš malá na to, aby zaručovala 32 skenerů.

8
Remus Rusanu

U většiny moderních vícejádrových systémů, a zejména systémů s více procesory, je hardwarová architektura taková, že určité části paměti jsou daleko od určitých jader/procesorů a určité části paměti jsou blízké určitým jádrům/procesorům. Tomu se říká Non-Uniform Memory Architecture, zkrátka NUMA. Chcete, aby vaše nastavení MAXDOP odpovídalo počtu jader na NUMA uzlu, aby se minimalizovalo kolikrát musí daný numový uzel jít mimo svou vlastní paměť pro data.

Pomocí následujícího můžete zkontrolovat konfiguraci nového stroje a zajistit, aby byl MAXDOP nastaven na nejlepší nastavení hardwarově:

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

Zahrnul jsem @ServerRamInMB parametr zde, protože jej používám k nastavení Max Server Memory a Min Server Memory možnosti konfigurace na hodnoty, které jsou vhodné pro daný server.

3
Max Vernon

V jakém edičním a licenčním režimu se nacházíte? Pravděpodobně nepoužíváte všechna jádra. Viz poznámka na této stránce - http://msdn.Microsoft.com/en-us/library/ms143760.aspx

„Licence Enterprise Edition s licencí CAL (Server + Client Access License) je omezena na maximálně 20 jader na instanci serveru SQL.“

0
Jeff Sacksteder

Měl jsem stejný problém, jaký je popsán na této stránce: přepnutí nastavení výkonu z „vyváženého“ na „vysoký výkon“ způsobilo dramatický rozdíl - více než zdvojnásobení doby odezvy. Nyní, když používáme SSD, nemyslím si, že by to mohla být spotřeba energie.

0
tom