Проблеми с производителността на SQL Server 2012 Enterprise Edition при лицензиране на CAL

В SQL Server 2012 бяха въведени множество промени в лицензирането; най-значимото беше преминаването от лицензиране, базирано на сокет, към базирано на ядро ​​лицензиране за Enterprise Edition. Едно от предизвикателствата, пред които Microsoft се сблъска с тази промяна, беше предоставянето на път за миграция за клиенти, които преди това са използвали лицензиране на базата на Server+CAL за Enterprise Edition преди SQL Server 2012. Клиентите под Software Assurance могат да надстроят до SQL Server 2012 Enterprise Edition и все още да използват сървър +CAL лицензиране (известно още като "праздно"), но с ограничение до 20 логически процесора, както е документирано в Ръководството за лицензиране на SQL Server 2012. Това лицензиране се разпростира и до виртуални машини с ограничение от 4 виртуални машини, обхванати от лиценза Enterprise Server+CAL, но все пак със същото ограничение от 20 логически процесора, както е документирано в Ръководството за лицензиране на виртуализация на SQL Server 2012.

Много хора са били хванати неподготвени от ограничението от 20 логически процесора, въпреки че е документирано в ръководствата за лицензиране.

Във файла ERRORLOG се прави запис при стартиране на екземпляра, като се посочва броя на логическите процесори и че се прилага ограничението от 20 процесора:

С конфигурацията по подразбиране, която SQL Server прилага при ограничението от 20 логически процесора, използвайки Server+CAL, първите 20 планировчика са ВИДИМИ ОНЛАЙН и всички останали планировчици са ВИДИМИ ОФЛАЙН. В резултат на това могат да възникнат проблеми с производителността за екземпляра поради дисбаланси в планировчика на NUMA възел. За да демонстрирам това, създадох VM на нашия тестов сървър Dell R720, който има два гнезда и инсталирани процесори Intel Xeon E5-2670, всеки с 8 ядра и активиран Hyperthreading, осигурявайки общо 32 логически процесора, налични под Windows Server 2012 Datacenter Edition. Виртуалната машина е конфигурирана да има 32 виртуални CPU с 16 виртуални процесора, разпределени в два vNUMA възела.

Фигура 1 – настройки на vNUMA

В SQL Server при лицензионния модел Enterprise Server+CAL това води до конфигурация на планировчика, подобна на следната:

ИЗБЕРЕТЕ 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;

Фигура 2 – Присвояване на Scheduler под Enterprise Server+CAL

Както можете да видите, всички 16 логически процесори в първия NUMA възел и само четири от логическите процесори във втория NUMA възел се използват от екземпляра. Това води до значителен дисбаланс на планировчиците между двата NUMA възела, което може да доведе до значителни проблеми с производителността при натоварване. За да демонстрирам това, създадох 300 връзки, изпълняващи работното натоварване на AdventureWorks Books Online, срещу екземпляра и след това заснех информацията за планировчика за VISIBLE ONLINE планировчиците в екземпляра, като използвах следната заявка:

ИЗБЕРЕТЕ 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'VISIBLE ONLINE';

Примерен изход на тази заявка при натоварване е показан на Фигура 3 по-долу.

Фигура 3 – Планировчици при натоварване с Enterprise Server+CAL

Можете също да видите този симптом визуално в инструменти за наблюдение като SQL Sentry Performance Advisor:

Фигура 4 – NUMA дисбаланс, както е показано в SQL Sentry Performance Advisor

Тази информация показва значителен дисбаланс и в резултат на това производителността ще бъде засегната. Това е ясно видимо в броя на изпълняваните задачи за четирите планировчици във втория NUMA възел, които са три до четири пъти по-големи от тези за планировчиците в първия NUMA възел. И така, какъв точно е проблемът и защо се случва това?

На пръв поглед може да си помислите, че това е грешка в SQL Server, но не е така. Това е нещо, което се случва по проект, въпреки че се съмнявам, че този сценарий е бил очакван, когато първоначално е въведено ограничението от 20 логически процесора. В NUMA-базирани системи, новите връзки се присвояват на NUMA възлите по кръгъл начин, а след това вътре в NUMA възела връзката се присвоява на планировчик въз основа на натоварването. Ако променим начина, по който разглеждаме тези данни и обобщим данните въз основа на parent_node_id, ще видим, че задачите всъщност се балансират в NUMA възлите. За да направим това, ще използваме следната заявка, чийто изход е показан на Фигура 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) AS active_workers_count, AVG(load_factor) AS avg_load_factorFROM_HERN [название_натоварване] /предварително> 

 
Фигура 5 – кръгов баланс на NUMA възел 
 

 Това поведение е документирано в Books Online за SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Като знам какво знам за SQLOS, SQL Server и хардуера, това има смисъл. Преди ограничението от 20 логически процесора в SQL Server 2012 Enterprise Edition с лицензиране Server+CAL, беше рядък сценарий SQL Server да има дисбаланс на планировчика между NUMA възли в производствен сървър. Един от проблемите в този конкретен случай е начинът, по който виртуалната NUMA беше предадена към VM. Извършването на точно същата инсталация на физическия хардуер позволява на всички планировчици да бъдат ВИДИМИ ОНЛАЙН, тъй като допълнителните логически процесори, представени от хипернишките, се различават от SQL и са безплатни.
 

 С други думи, ограничението от 20 логически процесора всъщност води до 40 планировчици ОНЛАЙН, ако (а) не е виртуална машина, (б) процесорите са Intel и (в) хипер-нишката е активирана. силно> 
 

 Така че виждаме това съобщение в регистъра за грешки:
 Дата    14.11.2012 г. 22:36:18 ч.
Регистър     SQL сървър (текущ – 14.11.2012 г. 22:36:00)
Източник  сървър
Съобщение
SQL Сървърът откри 2 сокета с 8 ядра на сокет и 16 логически процесора на сокет, общо 32 логически процесора; използвайки 32 логически процесора, базирани на лицензиране на SQL Server. Това е информационно съобщение; не се изисква действие от потребителя. 

 И същата заявка като по-горе води до това, че всички 32 процесора са ВИДИМИ ОНЛАЙН:
 
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'; 

 
Фигура 6 – Същата конфигурация на физически хардуер 
 

 В този случай, тъй като има само 32 логически процесора, ограничението от 20 (добре, 40) ядра изобщо не ни влияе и работата се разпределя равномерно между всички ядра.
 

 В сценарии, при които ограничението от 20 процесора засяга NUMA баланса на планировчиците, е възможно ръчно да промените конфигурацията на сървъра, за да балансирате броя на ВИДИМИТЕ ОНЛАЙН планировчици във всеки от NUMA възлите чрез използването на ALTER SERVER CONFIGURATION . В предоставения пример за VM следната команда ще конфигурира първите 10 логически процесора във всеки NUMA възел да са ВИДИМИ ОНЛАЙН.
 
ПРОМЕНЯ КОНФИГУРАЦИЯ НА СЪРВЪРНАСТРОЙТЕ ПРОЦЕС АФИНИТЕТ CPU =0 ДО 9, 16 ДО 25;
 

 С тази нова конфигурация, изпълняваща същото натоварване от 300 сесии и работното натоварване на AdventureWorks Books Online, можем да видим, че дисбалансът на натоварването вече не възниква.
 

 
Фигура 7 – Балансът е възстановен с ръчна конфигурация 
 

 И отново с помощта на SQL Sentry Performance Advisor можем да видим натоварването на процесора, разпределено по-равномерно между двата NUMA възела:
 

 
Фигура 8 – NUMA баланс, както е показано в SQL Sentry Performance Advisor 
 

 Този проблем не е строго ограничен до виртуалните машини и начина, по който виртуалните процесори се представят на операционната система. Възможно е също да срещнете този проблем с физически хардуер. Например, по-стар Dell R910 с четири гнезда и осем ядра на сокет или дори сървър, базиран на AMD Opteron 6200 Interlagos с два сокета и 16 ядра на сокет, който се представя като четири NUMA възела с по осем ядра всеки. При която и да е от тези конфигурации дисбалансът на процеса може също да доведе до това, че един от възлите NUMA бъде изцяло офлайн. Следователно други странични ефекти, като например паметта от този възел, която се разпределя между онлайн възлите, водещи до проблеми с достъпа до чужда памет, също могат да влошат производителността.
 
Резюме
 

 Конфигурацията по подразбиране на SQL Server 2012, използваща лицензирането на Enterprise Edition за Server+CAL, не е идеална при всички NUMA конфигурации, които може да съществуват за SQL Server. Всеки път, когато се използва лицензиране на Enterprise Server+CAL, конфигурацията на NUMA и статусите на планировчика на NUMA възел трябва да бъдат прегледани, за да се гарантира, че SQL Server е конфигуриран за оптимална производителност. Този проблем не възниква при лицензиране, базирано на ядрото, тъй като всички планировчици са лицензирани и ВИДИМ ОНЛАЙН.