Pagefile Sizing on a Windows VPS: Disk Pressure, Commit Limit and Crash Dumps

Pagefile sizing is one of the few Windows Server settings that looks administrative and is actually architectural. On a VPS it becomes urgent, because the default answer — “let Windows manage it” — assumes a system disk with room to grow. Many VPS plans ship with a 40 to 80 GB system volume, of which Windows and its updates consume most, leaving a managed pagefile that cannot expand when it needs to. The result is not usually a dramatic crash. It is a server that gets slower under load, logs a resource-exhaustion event, and reboots at the worst possible moment.

This article is about the mechanics: what commit charge actually is, why the commit limit matters more than free RAM, how to choose between fixed and system-managed sizing, and how to read the events that tell you the pagefile is the problem.

Commit charge is not physical memory

Windows gives every process a private commit when it allocates virtual memory, whether or not those pages are ever resident. The sum of those commitments is the commit charge. The commit limit is what the system is allowed to promise: roughly physical RAM plus the current pagefile size, minus a small reserve. A process can allocate several gigabytes of commit and use a few hundred megabytes of RAM; that is normal and correct. The danger is the opposite case — commit charge approaching the commit limit, at which point new allocations fail even though Task Manager shows plenty of “free” memory.

This is why “we have 8 GB and only use 5” is not evidence of headroom. A .NET application that reserves large buffers, a SQL Server with a generous max server memory, or a Java service with a fixed heap all consume commit that never appears as working set. When the commit limit is hit, you get allocation failures in application logs, services that stop responding, and eventually a bugcheck. The pagefile is what keeps the limit above the workload’s appetite.

# Current commit position
Get-CimInstance Win32_OperatingSystem |
  Select TotalVisibleMemorySize,FreePhysicalMemory,TotalVirtualMemorySize,FreeVirtualMemory
# Pagefile configuration and current usage
Get-CimInstance Win32_PageFileUsage | Select Name,AllocatedBaseSize,CurrentUsage,PeakUsage
Get-CimInstance Win32_ComputerSystem | Select AutomaticManagedPagefile

Treat TotalVirtualMemorySize minus TotalVisibleMemorySize as the current pagefile contribution, and PeakUsage as the historical high-water mark for that file. If peak usage is a large fraction of the allocation, the system has already been short of room at least once. For context on how the surrounding storage affects this, our notes on running Windows Server on VPS storage are worth reading alongside this.

Why system-managed sizing fails on small VPS disks

System-managed mode lets Windows pick the initial size and grow the file as needed, up to three times RAM or a third of the volume, whichever is smaller. On a large physical disk this works fine. On a VPS system volume with a few gigabytes free, the growth ceiling is the free space, not the formula. You end up with a pagefile that is technically valid and practically too small, and the growth happens under memory pressure — precisely when the disk is also busy and the resize is slowest.

There is a second problem: fragmentation and burst behaviour. A fixed file is allocated contiguously at boot; a managed file that grows late is not. On thin-provisioned VPS storage, late growth can also trip a provider-side quota or fill the underlying datastore. Neither failure is obvious from inside the guest, which is why “it worked on my lab VM” is a poor guide.

Choosing a fixed size

A defensible starting point for a general-purpose server is a fixed initial size equal to physical RAM, with a maximum of two to three times RAM, placed on a volume that is not the one your application writes logs and databases to if you have that option. That gives you meaningful commit headroom without letting the file consume the whole disk. If you run SQL Server, keep max server memory set so the instance does not outgrow the box; if you run a large .NET service, check its GC mode and reserved memory before assuming the pagefile needs to compensate.

If you need a full memory dump for crash analysis, the pagefile rule is separate and stricter: the dump target requires enough space on the volume hosting the pagefile to hold the dump, and a dedicated dump file can be configured so the pagefile itself does not have to be RAM-sized. Plan this deliberately, because discovering it after a bugcheck means the dump you wanted was never captured.

# Fixed 8192 MB initial / 16384 MB maximum on D:
$cs = Get-CimInstance Win32_ComputerSystem
if ($cs.AutomaticManagedPagefile) {
  Set-CimInstance -InputObject $cs -Property @{AutomaticManagedPagefile=$false}
}
New-CimInstance -ClassName Win32_PageFileSetting -Property @{Name="D:\pagefile.sys";InitialSize=8192;MaximumSize=16384}
# Dump type (e.g. 1 = complete, 2 = kernel, 3 = small, 7 = automatic)
Get-CimInstance Win32_OSRecoveryConfiguration | Select DebugInfoType,DebugFilePath

Changing the pagefile requires a reboot to take effect for the new file. Schedule it; on a production VPS this is not a change you make at 4pm on a Friday.

Reading the events when the commit limit is the problem

Windows logs resource exhaustion rather than announcing it. In the System log, look for Event ID 2004 from the Resource-Exhaustion-Detector source, which reports that Windows successfully diagnosed a low virtual memory condition and lists the processes consuming the most commit. Event ID 26 from the same source indicates the commit limit has been reached and further allocations are failing. Event ID 2019 from srv reports a non-paged pool allocation failure, which is a different problem but often appears in the same window when the system is genuinely out of memory.

Query them directly rather than browsing:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2,3; StartTime=(Get-Date).AddDays(-7)} |
  Where-Object Id -in 2004,26,2019 |
  Select TimeCreated,Id,ProviderName,Message | Format-List

Read the process list in the 2004 message carefully: it names the top consumers of commit, which is often not the process you expected. A background job, an update agent, or a badly configured service account running a large script can dominate the list. Increasing the pagefile without looking at that list just buys you longer before the same thing happens.

Disk pressure is the other half of the problem

You can size the pagefile correctly and still lose, because the file lives on a volume that is also being filled by something else. Two things matter here: free space on the pagefile volume, and the I/O characteristics of that volume. A pagefile on a shared, oversubscribed VPS datastore will page slowly, and a server that is paging hard on slow storage behaves worse than one that simply has enough RAM.

The practical controls are to keep 20 to 30 percent free on the system volume, move logs and temp data off it, and watch for the moment the volume crosses the warning line. If you consistently see commit peaks above the allocation even after resizing, the answer is more RAM, not a bigger file — and that is a conversation about the right VPS specification rather than an OS tweak. Our guide to sizing Windows VPS plans covers how RAM and disk quotas interact in practice.

A short checklist for the next server you build

• Decide the answer before deployment: fixed pagefile on a dedicated volume, or system-managed with verified free space.
• Record the commit limit at idle and after load; compare the two.
• Set dump type deliberately and confirm there is room for it.
• Alert on commit charge above roughly 85 percent of the limit, and on system volume free space below 20 percent.
• Review Event ID 2004 and 26 weekly, not only after an outage.

None of this is exotic. It is the difference between a server that degrades predictably and one that falls over when an allocation returns an error nobody was watching for.