I read Bob Ward's post on SQL server and Large Pages (http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspx). He mentions that even without trace flag 834 enabled, SQL Server still uses Large Pages is some ways not related to the buffer pool (he listed internal lock management structures and buffer hash as two possibilities).
Can anyone provide more detail about how SQL Server utilizes Large Pages when trace flag 834 is NOT turned on?
I ask because I am running a SQL Server 2008 R2 cluster whose nodes meet the requirements for large pages (SQL Server Enterprise Edition, >=8GB RAM, LPIM set). We do not have trace flag 834 turned on. Sometimes, if a SQL Server instance is moved from one node to another, I see the message "Cannot use Large Page Extensions: Failed to allocate 32MB" in the error log. This seems to happen if the node has been up for a while. I think this is due to memory fragmentation- I believe that this line is telling me that the LargePageAllocator could not find 32MB of contiguous memory to, as Bob Ward's post puts it, "prime the system for any component that needs large pages memory."
I'm trying to understand what the ramifications of this message are to SQL instances where trace flag 834 is NOT on. What's affected within my instance? What isn't performing as well as it could be, due to Large Page Extensions' failure to allocate 32MB?
Thanks in advance for any info- there is precious little out there regarding this that I could find...
Vince Misetich