Виртуализацията е много популярна за организациите:позволява им да използват по-добре хардуера чрез комбиниране на множество сървъри в един хост, осигурява HA възможности и дава намаляване на различни разходи като отопление/охлаждане, лицензи за SQL Server и хардуер. Участвал съм в множество проекти с организации, за да им помогна да мигрират от физическа към виртуална среда и съм им помогнал да изпитат тези предимства.
Това, което искам да споделя с вас в тази статия, е особен проблем, на който се натъкнах, докато работех с Hyper-V на Windows Server 2012 R2, използвайки динамична памет. Трябва да призная, че повечето от познанията ми за виртуализацията са свързани с VMware, но сега това се променя.
Когато работя със SQL Server на VMware, винаги препоръчвам да зададете резервации за памет, така че когато срещнах тази функция за динамична памет с Hyper-V, трябваше да направя някои проучвания. Намерих статия (Ръководство за конфигуриране на динамична памет Hyper-V), която обяснява много от предимствата и системните изисквания за използване на динамична памет. Тази функция е доста готина в начина, по който можете да предоставите на виртуална машина повече или по-малко памет, без да се налага да се изключва.
Поигравайки с Hyper-V, установих, че осигуряването на виртуални машини е лесно и лесно за научаване. С малко усилия успях да изградя лабораторна среда, за да симулирам опита, който моят клиент имаше. Заслугата е на шефа ми, че ми предостави страхотен хардуер, с който да работя. Работя с Dell M6800 с процесор i7, 32GB RAM и два 1TB SSD. Този звяр е по-добър от много сървъри, върху които съм работил.
Използвайки VMware Workstation 11 на моя лаптоп, създадох Windows Server 2012 R2 гост с 4 vCPU, 24 GB RAM и 100 GB място за съхранение. След като гостът беше създаден и коригиран, добавих ролята на Hyper-V и осигурих гост под Hyper-V. Новият гост е създаден с Windows Server 2012 R2 с 2 vCPU, 22 GB RAM и 60 GB място за съхранение, работещо с SQL Server 2014 RTM.
Проведох три комплекта тестове, всеки използващ динамична памет. За всеки тест използвах SQL генератора на данни на Red Gate срещу базата данни AdventureWorks2014, за да попълня буферния пул. За първия тест започнах с 512MB за стойността на Startup RAM, тъй като това е минималното количество памет за стартиране на Windows Server 2012 R2 и буферният пул спря да се увеличава на около 8GB.
За всеки тест бих съкратил моята тестова таблица, бих изключал госта, променях настройките на паметта и стартирах резервното копие на госта. За втория тест увеличих началната RAM до 768 MB и буферният пул се увеличи само до малко над 12 GB.
За третия и последен тест увеличихме началната RAM до 1024 MB, стартирахме генератора на данни и буферният пул успя да се увеличи до малко под 16 GB.
Извършването на малко математика за тези стойности показва, че буферният пул не може да нарасне повече от 16 пъти по-висока от RAM при стартиране. Това може да бъде много проблематично за SQL Server, ако стартиращата RAM памет е по-малка от 1/16 от размера на максималната памет. Нека помислим за Hyper-V гост с 64GB RAM, работещ с SQL Server със стойност на стартираща RAM памет от 1GB. Забелязахме, че буферният пул няма да може да използва повече от 16 GB с тази конфигурация, но ако зададем стойността на Startup RAM на 4096 MB, тогава буферният пул ще може да се увеличи 16 пъти, което ни позволява да използваме всичките 64 GB.
Единствените препратки, които успях да намеря за това защо буферният пул е ограничен до 16 пъти стойността на Startup RAM, бяха на страници 8 и 16 в бялата книга, Най-добри практики за изпълнение на SQL Server с HVDM. Този документ обяснява, че тъй като стойността на кеша на буфера се изчислява при стартиране, тя е статична стойност и не нараства. Ако обаче SQL Server открие, че се поддържа Hot Add Memory, той увеличава размера, запазен за виртуалното адресно пространство за буферния пул с 16 пъти по-голяма от стартовата памет. Този документ също така посочва, че това поведение засяга SQL Server 2008 R2 и по-стари, но тестът ми беше проведен на Windows Server 2012 R2 със SQL Server 2014, така че ще се свържа с Microsoft, за да актуализирам документа с най-добрите практики.
Тъй като повечето производствени DBA не предоставят виртуални машини или работят силно в това пространство, а инженерите за виртуализация не изучават най-новата и най-добра технология на SQL Server, мога да разбера как тази важна информация за това как буферният пул обработва динамичната памет е неизвестна на много хора от хора.
Дори следването на статиите може да бъде подвеждащо. В статията Hyper-V Dynamic Memory Configuration Guide, описанието за Startup RAM гласи:
Указва количеството памет, необходима за стартиране на виртуалната машина. Стойността трябва да е достатъчно висока, за да позволи стартирането на операционната система за гости, но трябва да бъде възможно най-ниска, за да позволи оптимално използване на паметта и потенциално високи коефициенти на консолидация.Оптимално използване на паметта за кого, за домакина или за госта? Ако администраторът за виртуализация четеше това, те вероятно биха определили, че това означава минималната памет, позволена за стартиране на операционната система.
Отговорността за SQL Server означава, че трябва да знаем за други технологии, които могат да повлияят на нашата среда. С въвеждането на SAN и виртуализацията трябва да разберем напълно как нещата в тези среди могат да повлияят негативно на SQL Server и, което е по-важно, как ефективно да съобщим опасенията на хората, отговорни за тези системи. DBA не трябва непременно да знае как да осигури съхранение в SAN или как да предоставя или да може да администрира среда VMWare или Hyper-V, но те трябва да знаят основите на това как работят нещата.
Познавайки основите за това как SAN работи с масиви за съхранение, мрежи за съхранение, мулти-пейтинг и така нататък, както и как хипервизорът работи с планирането на процесорите и разпределението на паметта в рамките на виртуализацията, DBA може по-добре да комуникира и да отстранява проблеми, когато възникнат проблеми . През годините успешно работих с редица администратори на SAN и виртуализация за изграждане на стандарти за SQL Server. Тези стандарти са уникални за SQL Server и не се прилагат непременно за уеб сървъри или сървъри на приложения.
DBA не могат наистина да разчитат на администраторите на SAN и виртуализация, за да разберат напълно най-добрите практики за SQL Server, независимо колко хубаво би било това, така че трябва да се образоваме възможно най-добре за това как техните области на експертиза могат да ни повлияят.
По време на моето тестване използвах заявка от публикацията в блога на Пол Рандал, Проблеми с производителността от пропиляна памет на буферния пул, за да определя колко буферен пул използва базата данни AdventureWorks2014. Включих кода по-долу:
SELECT
(CASE WHEN ([database_id] = 32767)
THEN N'Resource Database'
ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
COUNT (*) * 8 / 1024 AS [MBUsed],
SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id]; Този код също е чудесен за отстраняване на неизправности коя от вашите бази данни консумира по-голямата част от вашия буферен пул, така че можете да знаете коя база данни трябва да се съсредоточите върху настройката на скъпите заявки. Ако сте магазин на Hyper-V, консултирайте се с вашия администратор, за да видите дали динамичната памет може да бъде конфигурирана по такъв начин, че да повлияе негативно на сървъра ви.
