След като приложите тази актуализация, трябва да добавите флаг за проследяване на T8075 като параметър за стартиране, за да разрешите тази промяна.
Симптоми
Когато изпълнявате заявка в 64-битова версия на Microsoft SQL Server 2012, получавате съобщение за грешка при недостиг на памет, подобно на следното в регистрационния файл за грешки на SQL Server:
Неуспешно разпределени страници: FAIL_PAGE_ALLOCATION 513
Заявките отнемат много време, за да приключите с изпълнението и срещнете SOS_MEMORY_TOPLEVELBLOCKALLOCATOR изчаква. Когато преглеждате следните информационни точки, ще откриете, че има много ниско налично виртуално адресно пространство:
-
Разделът "DBCC MEMORYSTATUS"
-
DMV: sys.dm_os_process_memory-колонен virtual_address_space_available_kb
Тези стойности започват около 8 терабайта (ТБ) върху x64 процеса и продължават да слизат надолу и да достигнат няколко гигабайта (ГБ). Когато сте на етап, където наличните виртуални адреси са много ниски, заявките, които се опитват да изпълнят разпределение на паметта, също могат да се сблъскат с тип "CMEMTHREAD". Следните точки от данни ще продължат да се увеличават с течение на времето:
-
DMV: sys.dm_os_process_memory и sys.dm_os_memory_nodes колони virtual_address_space_reserved_kb
-
DBCC MEMORYSTATUS-секция "Диспечер на паметта"-VM запазени
Тези стойности обикновено ще се увеличават със стойност, която е по-голяма от почти 8 ТБ.
Причина
Когато процесът на SQL Server достигне състоянието, където общо памет на сървъра = памет за целеви сървъри = Max Server Memory, има правила в диспечера за памет на SQL Server, за да позволите на нови разпределения да поискат от повече от 8 KB страници, за да могат да бъдат временно успешно. Повтарящата се схема на разпределение при такова условие може да доведе до фрагментиране на блоковете с памет и потреблението на виртуалното адресно пространство. Ако този процес се повтаря много пъти, виртуалното пространство за SQL Server ще бъде изтощено и ще забележите какви симптоми са споменати по-рано.
Решение
Информация за сборна актуализация
Проблемът е коригиран първо в следващата сборна актуализация на SQL Server.
Всяка нова сборна актуализация за SQL Server съдържа всички поправки и всички корекции на защитата, които са били включени в предишната сборна актуализация. Препоръчваме ви да изтеглите и инсталирате последните сборни актуализации за SQL Server:
Тази актуална корекция не позволява както недостиг на памет, така и непрекъснато намаляване на наличното място за виртуално адрес, което можете да изпитате.
Състоянието
Microsoft потвърди, че това е проблем в продуктите на Microsoft, които са посочени в секцията "важи за".
Повече информация
-
Windows 2012 R2 позволява виртуално адресно пространство да расте по-голямо от 128 ТБ. Следователно може да не забележите този проблем в средата на Windows 2012 R2. За повече информация вижте следната тема в центъра за разработчици на Windows:ограничения за памет за Windows и Windows Server releases
-
Ако виждате постоянен растеж във виртуалното адресно пространство дори след като приложите корекцията, можете да определите кои заявки или операции са изискващи големи парчета памет с помощта на Page_allocated Разширено събитие. Примерен скрипт изглежда по следния начин:
CREATE EVENT SESSION [memory_tracking] ON SERVERADD EVENT sqlos.page_allocated( ACTION(package0.callstack,sqlos.cpu_id,sqlos.task_address,sqlos.worker_address,sqlserver.database_id,sqlserver.query_hash,sqlserver.request_id,sqlserver.session_id,sqlserver.sql_text) WHERE ([number_pages]>(1)))ADD TARGET package0.event_file(SET filename=N'E:\Data\MSSQL11.MSSQLSERVER\MSSQL\Log\memory_tracking.xel')WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=PER_CPU,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)GO
Обикновено това са архивите за архивиране и поддръжка на индекси, които се появяват често.
