Когато ESX 5 и Hyper-V в Windows Server 2012 пуснаха и промениха ограниченията, съществуващи преди за размерите на VM, почти веднага разбрах, че ще видим, че повече мащабни натоварвания на SQL Server започват да се виртуализират. Работил съм с редица клиенти през последната година, които виртуализираха 16-32 ядрени SQL сървъри по различни причини, от опростени стратегии за възстановяване след бедствие, които съответстваха на останалата част от бизнеса, до консолидация и по-ниски общи разходи за притежание на по-нов хардуер платформи. Една от причините за промяната на мащабируемостта с ESX 5+ беше въвеждането на виртуална NUMA (vNUMA) за широки гости, които надвишават размера на отделен хардуерен NUMA възел. С vNUMA гост VM е оптимизиран да съответства на хардуерната NUMA топология, позволявайки на операционната система за гости и всички NUMA приложения, като SQL Server, които се изпълняват на VM, да се възползват от оптимизациите на производителността на NUMA, точно както ако са били работи на физически сървър.
В рамките на VMware топологията vNUMA е налична на хардуерна версия 8 или по-нова и се конфигурира по подразбиране, ако броят на vCPU е по-голям от осем за госта. Възможно е също така ръчно да се конфигурира топологията vNUMA за VM, като се използват разширени опции за конфигуриране, което може да бъде полезно за VM, които имат повече памет, разпределена за тях, отколкото физически NUMA възел може да предостави, но все пак използва осем или по-малко vCPU. В по-голямата си част настройките за конфигурация по подразбиране работят за по-голямата част от виртуалните машини, които разгледах през последните няколко години, но има определени сценарии, при които топологията на vNUMA по подразбиране не е идеална и ръчната конфигурация може да осигури някои предимства. Наскоро работех с клиент с няколко vCPU SQL Server виртуални машини с 512GB RAM, разпределени, правейки някои настройки на производителността, където vNUMA топологията не беше нищо близко до очакваното.
Хост сървърите на VM в тази среда бяха четири сокета E5-4650, осем ядрени процесора и 1TB RAM, всеки посветен на един SQL Server VM при типични операции, но с наличен капацитет за поддържане на две VM в сценарий на отказ. С това хардуерно оформление има четири NUMA възела, по един на сокет, а очакваната конфигурация на VM също ще има 4 vNUMA възела, представени за 32 vCPU конфигурация. Въпреки това, това, което открих, докато разглеждах DMVs в SQL Server, беше, че това не е така:
Фигура 1 – Неправилна vNUMA конфигурация
Както вероятно можете да видите на изображението, нещо наистина не е наред с NUMA конфигурацията на този сървър. Има четири възела на паметта в SQLOS и само един възел на процесора, като всички vCPU са разпределени в него. За да бъда напълно честен, това ме взриви, когато го видях, защото противоречи на всичко, което знаех за това как SQLOS конфигурира вътрешните структури при стартиране на екземпляра. След като се разрових малко във файловете ErrorLog, монитора на производителността и диспечера на задачите на Windows, изтеглих копие на CoreInfo от SysInternals и разгледах оформлението на NUMA, което се съобщава на Windows.
Логически процесор към карта на гнездото:********———————— Сокет 0
——–********—————- Сокет 1
—————-********——– Гнездо 2
————————******** Гнездо 3
Логически процесор към карта на NUMA възел:
*********************************** NUMA възел 0
Изходът на CoreInfo потвърди, че VM представя 32 vCPU като 4 различни сокета, но след това групира всички 32 vCPU в NUMA Node 0. Разглеждайки броячите на производителността на Windows Server 2012 на VM, видях от групата на броячите на паметта на NUMA Node, че 4 възела на паметта NUMA бяха представени на ОС с паметта, равномерно разпределена между възлите. Всичко това съвпада с това, което виждах в SQLOS и можех също да разбера от записите на ERRORLOG при стартиране, че маската на процесора за възела маскира всички налични процесори в CPU Node 0, но бяха създадени четири големи разпределители на страници, един за всеки възел на паметта.
22.09.2013 05:03:37,Сървър,Неизвестен,Конфигурация на възел:възел 0:Маска на процесора:0x00000000ffffffff:0 Активна маска на процесора:0x00000000ffffffff:0. Това съобщение предоставя описание на NUMA конфигурацията за този компютър. Това е само информационно съобщение. Не се изисква действие от потребителя.22.09.2013 05:03:37,Сървър,Неизвестен,Последният отчет за този екземпляр на SQL Server с идентификатор на процеса 1596 на 22.09.2013 г. 5:00:25 ч. (местно) 22.09.2013 г. 10:00:25 ч. (UTC). Това е само информационно съобщение; не се изисква действие от потребителя.
22.09.2013 05:03:35,Сървър,Неизвестен,Разпределена голяма страница:32MB
22.09.2013 05:03:35,Сървър,Неизвестен,Голяма Разпределена страница:32MB
22.09.2013 05:03:35,Сървър,Неизвестен,Разпределена голяма страница:32MB
09/22/2013 05:03:35,Сървър,Неизвестен,Разпределена голяма страница :32MB
09/22/2013 05:03:35,Сървър,Неизвестен,Използване на заключени страници в мениджъра на паметта.
09/22/2013 05:03:35,Сървър,Неизвестен,Открит 524287 MB RAM. Това е информационно съобщение; не се изисква действие от потребителя.
22.09.2013 05:03:35,Сървър,Неизвестен,SQL сървърът стартира с нормален приоритет (=7). Това е само информационно съобщение. Не се изисква действие от потребителя.
22.09.2013 05:03:35,Сървърът,Неизвестен,SQL Server откри 4 сокета с 8 ядра на сокет и 8 логически процесора на сокет 32 общо логически процесора; използвайки 32 логически процесора, базирани на лицензиране на SQL Server. Това е информационно съобщение; не се изисква действие от потребителя.
В този момент бях сигурен, че това е нещо, свързано с конфигурацията на VM, но не можах да идентифицирам какъв конкретно е проблемът, тъй като никога не бях виждал това поведение на други широки SQL Server VM, на които съм помагал на клиенти на VMware ESX 5+ в миналото. След като направи няколко промени в конфигурацията на тестов VM сървър, който беше наличен, само никой от тях не коригира конфигурацията на vNUMA, представена във VM. След като се обадихме в поддръжката на VMware, бяхме помолени да деактивираме функцията за горещо включване на vCPU за тестовата VM и да видим дали това е коригирало проблема. С деактивирана гореща връзка на VM, изходът на CoreInfo потвърди, че vNUMA картографирането на процесорите за VM сега е правилно:
Логически процесор към карта на гнездото:********———————— Сокет 0
——–********—————- Сокет 1
—————-********——– Гнездо 2
————————******** Гнездо 3
Логически процесор към карта на NUMA възел:
********———————— NUMA възел 0
——–********————— - NUMA възел 1
—————-********——– NUMA възел 2
————————******** NUMA възел 3
Това поведение всъщност е документирано в статията на VMware KB (vNUMA е деактивирана, ако VCPU hotplug е активирана), от октомври 2013 г. Това беше първата широка VM за SQL Server, с която работих, където беше активирана hotplug vCPU, и е не е типична конфигурация, която бих очаквал за 32 vCPU VM, но беше част от стандартния шаблон, използван от клиента и се случи да повлияе на техния SQL Server.
Ефекти от деактивирането на vNUMA
Има редица ефекти, които деактивирането на vNUMA по този начин може да има върху работното натоварване, но има два специфични проблема, които биха могли да засегнат SQL Server конкретно при този тип конфигурация. Първото е, че сървърът може да има проблеми с натрупванията на изчакване CMEMTHREAD, тъй като има 32 vCPU, разпределени към един възел NUMA, а разделянето по подразбиране за обекти на паметта в SQLOS е на NUMA възел. Този специфичен проблем е документиран от Боб Дор в CSS групата в Microsoft в публикацията им в блога им SQL Server 2008/2008 R2 на по-нови машини с повече от 8 CPU, представени на NUMA възел, може да се нуждае от флаг за проследяване 8048. Като част от прегледа на изчакване на статистиката на VM с клиента отбелязах, че CMEMTHREAD е вторият им най-висок тип изчакване, което е необичайно от моя опит и ме накара да разгледам конфигурацията на SQLOS NUMA, показана на фигура 1 по-горе. В този случай флагът за проследяване не е решението, премахването на hotplug vCPU от конфигурацията на VM решава проблема.
Вторият проблем, който би засегнал SQL Server конкретно, ако сте на непоправена версия, е свързан с управлението на паметта NUMA в SQLOS и начина, по който SQLOS проследява и управлява отдалечени страници по време на първоначалната фаза на нарастване на паметта след стартиране на екземпляра. Това поведение е документирано от Боб Дор в публикацията в блога на CSS, Как работи:SQL Server (NUMA локални, чужди и отдалечени блокове с памет). По същество, когато SQLOS се опита да разпредели памет на локален възел по време на първоначалното нарастване, ако върнатият адрес на паметта е от различен възел на паметта, страницата се добавя към списъка Away и се извършва друг опит за локално разпределение на паметта и процесът се повтаря, докато локалното разпределение на паметта е успешно или целта на паметта на сървъра е достигната. Тъй като три четвърти от паметта на нашите екземпляри съществува на NUMA възли без планировчици, това създава влошено състояние на производителността по време на първоначалното нарастване на паметта за екземпляра. Последните актуализации промениха поведението на разпределението на паметта по време на първоначалното нарастване, за да се опитат само разпределяне на локална памет фиксиран брой пъти (конкретният брой не е документиран), преди да се използва външната памет за продължаване на обработката. Тези актуализации са документирани в KB #2819662, КОРЕКЦИЯ:Проблеми с производителността на SQL Server в NUMA среди.
Резюме
За широки виртуални машини, дефинирани като имащи повече от 8 vCPU, е желателно да има vNUMA, прехвърлен във виртуалната машина от хипервизора, за да позволи на Windows и SQL Server да използват NUMA оптимизациите в тяхната кодова база. В резултат на това тези по-широки виртуални машини не трябва да имат активирана конфигурация на vCPU hotplug, тъй като това е несъвместимо с vNUMA и може да доведе до влошена производителност за SQL Server при виртуализация.
