SQL server 2012 Ent using less memory than the allocated amount after enabling -T834

Question

I am facing the situation mentioned here.
http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspx
My SQL Server 2012 is not able to use all the 112 GB RAM that was allocated to it after enabling -T834.
This was not the case earlier. Now I see the Total server memory and target server memory counters are just 27 GB constantly. I found the below error while starting SQL after enabling -T834. I restarted services again and this time it started fine. But I
didnt bother about the error untill users complained slowness and SQL memory usage was found to be low.
 Detected 131068 MB of RAM. This is an informational message; no user action is required.
 Using large pages in the memory manager.
 Large Page Allocated: 32MB
 Large page allocation failed during memory manager initialization
 Failed to initialize the memory manager
 Failed allocate pages: FAIL_PAGE_ALLOCATION 2
 Error: 17138, Severity: 16, State: 1.
 Unable to allocate enough memory to start 'SQL OS Boot'. Reduce non-essential memory load or increase system memory.
Now, SQL is started by its Total server memory is only 27 GB. How can I make SQL server use all the allocated max server memory with -T834 still on ?
Bharath Kumar ------------- Please mark solved if I've answered your question, vote for it as helpful to help other user's find a solution quicker

Answer 1

Hi Bharath , 
in the below post the scenario is mentioned clearly 
http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspx
Unable to allocate enough memory to start 'SQL OS Boot'. Reduce non-essential memory load or increase system memory.
This shows one of the problems with large pages: the memory size requested must be contiguous. This is called out very nicely at the MSDN
article on Large Pages
These memory regions may be difficult to obtain after the system has been running for a long time because the space for each large page must be contiguous, but the memory may have become fragmented. This is an expensive operation;
therefore, applications should avoid making repeated large page allocations and allocate them all one time at startup instead.
In this case above, even if ‘max server memory’ was set to say 8Gb, the server could only allocate 2Gb and that now becomes a maximum allocation for the buffer pool. Remember we don’t grow the buffer pool when using large pages so whatever memory we allocate
at startup is the max you get.
The other interesting thing you will find out with large pages is a possible slowdown in server startup time. Notice in the ERRORLOG entry above the gap of 7 minutes between the server discovering trace flag 834 was on (the "Using large pages..” message)
and the message about how much large memory was allocated for the buffer pool. Not only does it take a long time to call VirtualAlloc() but in the case where we cannot allocate total physical memory or ‘max server memory” we attempt to allocate lower values
several times before either finding one that works or failing to start. We have had some customers report the time to start the server when using trace flag 834 was over 30 minutes.
regards,
Ram
ramakrishna