none
Why does attempting to allocate more than approx 900MB with VirtualAlloc fail on Nano Server Tech Preview 4? RRS feed

  • Question

  • I've been trying to run MySQL on Nano Server and discovered that when I requested an InnoDB buffer pool size larger than a few hundred MB, MySQL server failed to start with Windows error 1455: ERROR_COMMITMENT_LIMIT "The paging file is too small for this operation to complete."  

    As far as I could tell, the paging file size should have been sufficient (I was running Nano Server in a "boot from VHD" configuration) and the machine had 4GB of physical RAM. I wrote a little test application to display the result of GlobalMemoryStatusEx and call VirtualAlloc in a loop allocating 4K chunks until VirtualAlloc returned NULL.

    According to GlobalMemoryStatusEx, there were several GB of available memory, but VirtualAlloc failed after having allocated approx 900MB in 4K chunks.  The VirtualAlloc calls looks like this:

    SIZE_T size = 4096;
    while (true)
    {
      LPVOID ptr = VirtualAlloc(NULL, size, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE);
      if(!ptr)
      {
        // Display failure message
        // ...
        break;
      }
      else
      {
        // Increment total allocated so far etc
        // ...
      }
    }

    I thought the problem might be related to the "boot from VHD" configuration that I was running Nano Server with, so I also tried running Nano Server as a virtual machine hosted in Hyper-V and VirtualBox and obtained very similar results.

    I used Get-WmiObject to vary the size of the paging file and observed the expected size changes in the results of the GlobalMemoryStatusEx but varying the size of the paging file didn't seem to affect the point at which VirtualAlloc failed.

    Am I doing something wrong here, or is this a bug in Nano Server's virtual memory management?



    Dan

    Update 14 Dec 2015

    It turns out that running the test under the (remote) debugger may be the culprit!

    I just re-ran the memory allocation loop above using a PowerShell Direct connection without using the debugger and successfully allocated approx 3.1GB of virtual memory before encountering the ERROR_COMMITMENT_LIMIT.

    After the ERROR_COMMITMENT_LIMIT is encountered, GlobalMemoryStatusEx returns the following:

    There is       64 percent of memory in use.
    There are  523828 total KB of physical memory.
    There are  186492 free  KB of physical memory.
    There are 3669556 total KB of paging file.
    There are    4464 free  KB of paging file.
    There are 137438953344 total KB of virtual memory.
    There are 137435684072 free  KB of virtual memory.
    There are       0 free  KB of extended memory.

    This looks much more plausible.

    This makes me think that the (remote) debugging environment is somehow interfering with the virtual memory system.

    • Edited by DanBlan Monday, December 14, 2015 10:47 AM New information
    Friday, December 11, 2015 4:37 PM

All replies

  • Hi,

    Running under the debugger shouldn't make a difference. Can you check to see if _NO_DEBUG_HEAP=1 is sett in your app's environment block?

    Thanks,

    Andrew

    Monday, December 14, 2015 6:31 PM