Problémy s výkonem u SQL Server 2012 Enterprise Edition v rámci licence CAL

V SQL Server 2012 byly zavedeny četné licenční změny; nejvýznamnější byl přechod od licencování založeného na socketu k licencování založenému na jádru pro Enterprise Edition. Jednou z výzev, kterým Microsoft v souvislosti s touto změnou čelil, bylo poskytnutí cesty migrace pro zákazníky, kteří dříve používali licencování založené na Server+CAL pro Enterprise Edition před SQL Server 2012. Zákazníci v rámci Software Assurance mohou upgradovat na SQL Server 2012 Enterprise Edition a nadále používat Server Licencování +CAL (také známé jako „grandfathering“), ale s omezením na 20 logických procesorů, jak je uvedeno v příručce SQL Server 2012 Licensing Guide. Toto licencování se vztahuje také na virtuální počítače s limitem 4 virtuálních počítačů, na které se vztahuje licence Enterprise Server+CAL, ale stále se stejným omezením 20 logických procesorů, jak je zdokumentováno v SQL Server 2012 Virtualization Licensing Guide.

Mnoho lidí bylo zaskočeno omezením 20 logických procesorů, i když je zdokumentováno v licenčních příručkách.

Při spuštění instance je v souboru ERRORLOG vytvořen záznam, který specifikuje počet logických procesorů a že je vynuceno omezení 20 procesorů:

S výchozí konfigurací, kterou SQL Server používá v rámci omezení 20 logických procesorů pomocí Server+CAL, je prvních 20 plánovačů VIDITELNÝCH ONLINE a všechny zbývající plánovače VIDITELNÝCH OFFLINE. V důsledku toho mohou pro instanci nastat problémy s výkonem v důsledku nevyváženosti plánovače uzlů NUMA. Abych to demonstroval, vytvořil jsem virtuální počítač na našem testovacím serveru Dell R720, který má dvě patice a nainstalované procesory Intel Xeon E5-2670, každý s 8 jádry a povoleným Hyperthreadingem, což poskytuje celkem 32 logických procesorů dostupných pod Windows Server 2012 Datacenter Edition. Virtuální počítač byl nakonfigurován tak, aby měl 32 virtuálních CPU s 16 virtuálními procesory alokovanými ve dvou uzlech vNUMA.

Obrázek 1 – nastavení vNUMA

V SQL Server v rámci licenčního modelu Enterprise Server+CAL to vede ke konfiguraci plánovače, která je podobná následující:

SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulers;

Obrázek 2 – Přiřazení plánovače pod Enterprise Server+CAL

Jak vidíte, všech 16 logických procesorů v prvním uzlu NUMA a pouze čtyři logické procesory ve druhém uzlu NUMA používá instance. To má za následek značnou nerovnováhu plánovačů mezi dvěma uzly NUMA, která může vést k významným problémům s výkonem při zatížení. Abych to demonstroval, vytvořil jsem 300 připojení s pracovní zátěží AdventureWorks Books Online proti instanci a poté jsem zachytil informace plánovače pro plánovače VISIBLE ONLINE v instanci pomocí následujícího dotazu:

SELECT parent_node_id, scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VIDIBLE ONLINE';

Příklad výstupu tohoto dotazu při zatížení je znázorněn na obrázku 3 níže.

Obrázek 3 – Plánovače v zátěži s Enterprise Server+CAL

Tento příznak můžete také vidět vizuálně v monitorovacích nástrojích, jako je SQL Sentry Performance Advisor:

Obrázek 4 – Nevyváženost NUMA, jak je znázorněno v SQL Sentry Performance Advisor

Tyto informace ukazují značnou nerovnováhu a v důsledku toho bude ovlivněn výkon. To je jasně patrné z počtu spustitelných úloh pro čtyři plánovače v druhém uzlu NUMA, které jsou třikrát až čtyřikrát větší než u plánovačů v prvním uzlu NUMA. V čem tedy přesně spočívá problém a proč k tomu dochází?

Na první pohled si můžete myslet, že se jedná o chybu v SQL Server, ale není. K tomu dochází záměrně, i když pochybuji, že tento scénář byl očekáván, když bylo původně implementováno omezení 20 logických procesorů. V systémech založených na NUMA jsou nová připojení přiřazována uzlům NUMA způsobem kruhového provozu a uvnitř uzlu NUMA je připojení přiřazeno plánovači na základě zatížení. Pokud změníme způsob, jakým se díváme na tato data, a agregujeme data na základě parent_node_id, uvidíme, že úkoly jsou ve skutečnosti vyváženy napříč uzly NUMA. K tomu použijeme následující dotaz, jehož výstup je znázorněn na obrázku 5.

SELECT parent_node_id, SUM(current_tasks_count) AS current_tasks_count, SUM(runnable_tasks_count) AS runnable_tasks_count, SUM(active_workers_count_count) AS active_workers_count, AVG(load_factor) AS avg_load_factorFROM_NORDEROS BYDULSHEstatus_BLE_LINE =NSCHdulBYHEstatusWBLE; /před> 

 
Obrázek 5 – bilance mezi jednotlivými uzly NUMA 
 

 Toto chování je zdokumentováno v Books Online pro SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Když vím, co vím o SQLOS, SQL Serveru a hardwaru, dává to smysl. Před omezením 20 logických procesorů v SQL Server 2012 Enterprise Edition s licencováním Server+CAL byl vzácný scénář, že by SQL Server měl nerovnováhu plánovače mezi uzly NUMA na produkčním serveru. Jedním z problémů v tomto konkrétním případě je způsob, jakým bylo virtuální NUMA předáno virtuálnímu počítači. Provedení přesně stejné instalace na fyzickém hardwaru umožňuje, aby všechny plánovače byly VIDITELNÉ ONLINE, protože další logické procesory prezentované hypervlákny jsou rozlišitelné pomocí SQL a jsou zdarma.
 

 Jinými slovy, limit 20 logických procesorů ve skutečnosti vede ke 40 plánovačům ONLINE, pokud (a) nejde o virtuální počítač, (b) procesory jsou Intel a (c) je povoleno hyper-threading. silný> 
 

 V protokolu chyb tedy vidíme tuto zprávu:
 Datum    14. 11. 2012 22:36:18
Protokol     SQL Server (aktuální – 14. 11. 2012 22:36:00)
Zdrojový  Server
Zpráva
SQL Server detekoval 2 sokety s 8 jádry na soket a 16 logickými procesory na soket, celkem 32 logických procesorů; pomocí 32 logických procesorů založených na licencování SQL Server. Toto je informační zpráva; není vyžadována žádná akce uživatele. 

 A stejný dotaz jako výše má za následek, že všech 32 procesorů je VIDITELNÝCH ONLINE:
 
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';
 

 
Obrázek 6 – Stejná konfigurace na fyzickém hardwaru 
 

 V tomto případě, protože existuje pouze 32 logických procesorů, limit 20 (dobře, 40) jader nás vůbec neovlivňuje a práce je rozdělena rovnoměrně mezi všechna jádra.
 

 Ve scénářích, kde omezení 20 procesorů ovlivňuje rovnováhu NUMA plánovačů, je možné ručně změnit konfiguraci serveru tak, aby se vyrovnal počet VISIBLE ONLINE plánovačů v každém z uzlů NUMA pomocí ALTER SERVER CONFIGURATION . V uvedeném příkladu virtuálního počítače následující příkaz nakonfiguruje prvních 10 logických procesorů v každém uzlu NUMA na VISIBLE ONLINE.
 
ZMĚŇTE NASTAVENÍ KONFIGURACE SERVERU PROCES AFFINITY CPU =0 AŽ 9, 16 AŽ 25;
 

 S touto novou konfigurací, se stejnou zátěží 300 relací a pracovní zátěží AdventureWorks Books Online, vidíme, že k nerovnováze zátěže již nedochází.
 

 
Obrázek 7 – Zůstatek obnoven pomocí ruční konfigurace 
 

 A opět pomocí SQL Sentry Performance Advisor můžeme vidět, že zatížení CPU je rovnoměrněji rozloženo mezi oba uzly NUMA:
 

 
Obrázek 8 – Zůstatek NUMA, jak je znázorněno v SQL Sentry Performance Advisor 
 

 Tento problém není striktně omezen na virtuální počítače a způsob, jakým jsou virtuální CPU prezentovány OS. Je také možné narazit na tento problém s fyzickým hardwarem. Například starší Dell R910 se čtyřmi sockety a osmi jádry na socket, nebo dokonce server založený na AMD Opteron 6200 Interlagos se dvěma sockety a 16 jádry na socket, který se prezentuje jako čtyři NUMA uzly s osmi jádry. V obou těchto konfiguracích může nerovnováha procesu také způsobit, že jeden z uzlů NUMA bude zcela offline. V důsledku toho mohou výkon snížit i další vedlejší účinky, jako je distribuce paměti z tohoto uzlu mezi online uzly vedoucí k problémům s přístupem do cizí paměti.
 
Shrnutí
 

 Výchozí konfigurace SQL Server 2012 pomocí licencování Enterprise Edition pro Server+CAL není ideální ve všech konfiguracích NUMA, které mohou pro SQL Server existovat. Kdykoli se používá licencování Enterprise Server+CAL, je třeba zkontrolovat stavy konfigurace NUMA a plánovače na uzel NUMA, aby bylo zajištěno, že je SQL Server nakonfigurován pro optimální výkon. Tento problém se nevyskytuje při licencování na základě jádra, protože všechny plánovače jsou licencovány a VIDITELNÉ ONLINE.