![\"MemoryTaskManager\"](\"https:\/\/www.sqlinthewild.co.za\/wp-content\/uploads\/2016\/01\/MemoryTaskManager.png\" "\\"MemoryTaskManager\\"")
<\/a><\/p>\nErr, what? SQL Server\u2019s not even using 100MB? I\u2019ve just read 30GB of data and SQL Server\u2019s not even using 1% of it\u2019s allowed memory!!!<\/p>\n
Or is it?<\/p>\n
A look at perfmon shows a completely different picture. Total and target server memory are both at 10GB. So why is Task Manager showing such a low figure?<\/p>\n The service account that SQL\u2019s running under has been granted the Lock Pages in Memory permission. This means that SQL\u2019s not using the normal Windows memory routines to allocate memory.<\/p>\n Normally, SQL Server and other Windows applications allocate memory using the VirtualAlloc API call. This allocates virtual memory which is pageable. When SQL Server has been given the Lock Pages in Memory permission, it doesn\u2019t use VirtualAlloc to allocate memory. Instead it uses the API call AllocateUserPhysicalPages. Memory allocated with this API call is not pageable, it has to remain in physical memory.<\/p>\n Task Manager\u2019s memory counters (the Working Set ones) only show memory that\u2019s been allocated using VirtualAlloc. Hence, when SQL Server has the Lock Pages in Memory permission and is allocating most of its memory using AllocateUserPhysicalPages, its memory usage in Task Manager will appear to be extraordinarily low. As far as I recall, in that case it\u2019s only the non-buffer memory which is still allocated with VirtualAlloc, and that\u2019s just things like the thread stacks, the CLR memory, backup buffers, and similar. It\u2019s not the buffer pool. The buffer pool gets allocated with AllocateUserPhysicalPages.<\/p>\n If I remove the Lock Pages in Memory and re-run the test, Task Manager shows completely different values<\/p>\n<\/a><\/p>\n<\/a><\/p>\n