MongoDB VPS Requirements: WiredTiger Cache Sizing, Memory & NVMe Storage

Sizing a KVM VPS for MongoDB requires configuring the WiredTiger storage engine's internal cache and preserving adequate system memory for the operating system filesystem cache. Because WiredTiger defaults to reserving 50% of total RAM minus 1 GB, uncalibrated VPS instances risk Out-Of-Memory termination under write-heavy workloads. Sizing memory, disk throughput, and swap correctly ensures database stability under sustained concurrency.

Understanding WiredTiger's Memory Allocation Architecture

The default storage engine for modern MongoDB is WiredTiger. WiredTiger manages memory across two distinct layers:

1. WiredTiger Internal Cache: Holds frequently accessed documents, indexes, and dirty modification buffers in uncompressed format in RAM to deliver low-latency reads and updates.
2. Operating System Filesystem Cache: MongoDB relies heavily on the Linux page cache. Data stored on disk is compressed (using Snappy by default). When MongoDB reads blocks from storage, it stores them compressed in the OS filesystem cache before decompressing them into the WiredTiger internal cache.

If an administrator allocates too much memory to WiredTiger, the operating system is starved of filesystem cache, causing increased disk I/O and latency spikes. Conversely, under-allocating memory causes working sets to spill to disk repeatedly.

The Default Cache Calculation Formula and Its Limitations

By default, MongoDB calculates the internal WiredTiger cache allocation using the following formula:

Cache Size = max(0.5 * (Total RAM - 1 GB), 256 MB)

Consider the practical allocation on standard KVM VPS configurations:

• 4 GB RAM VPS: 0.5 * (4 - 1) = 1.5 GB allocated to WiredTiger cache, leaving 2.5 GB for the OS, client connection threads, and running processes.
• 8 GB RAM VPS: 0.5 * (8 - 1) = 3.5 GB allocated to WiredTiger cache, leaving 4.5 GB for OS cache and query execution.
• 16 GB RAM VPS: 0.5 * (16 - 1) = 7.5 GB allocated to WiredTiger cache, leaving 8.5 GB for OS cache.

While this formula functions well on dedicated single-purpose database servers, problems arise if the VPS also hosts web application services, background queue workers, or connection-pooling daemons. In multi-service environments, the combined memory consumption will trigger the Linux Out-Of-Memory (OOM) killer, terminating the mongod process abruptly.

Explicitly Configuring wiredTiger.engineConfig.cacheSizeGB

To establish deterministic memory boundaries, explicitly define the cache size inside /etc/mongod.conf under the storage section:

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 3.5

After editing the configuration, restart the daemon via systemd: sudo systemctl restart mongod.

Runtime Adjustment Without Database Restart

You can also modify the internal cache size dynamically during runtime using the MongoDB administrative shell:

db.adminCommand({ 
  setParameter: 1, 
  wiredTigerEngineRuntimeConfig: "cache_size=3500M" 
})

This runtime modification takes effect immediately, allowing administrators to adjust memory boundaries during traffic surges without incurring service downtime.

Accounting for Index Size and Connection Overhead

In production sizing, internal document caching is only half the equation. Indexes must reside in memory for responsive performance. Inspect your total index footprint across collections:

// Check total index size in MongoDB shell
db.stats().indexSize / (1024 * 1024) + " MB";

If your total index size exceeds your configured cacheSizeGB, every indexed query will force cold disk reads. Furthermore, each active client connection to mongod consumes approximately 1 MB of stack memory plus buffer overhead. If your application maintains 500 concurrent connections, anticipate an additional 500 MB to 1 GB of raw system memory dedicated solely to connection tracking.

Linux Kernel Tuning: Swappiness and Transparent Huge Pages

MongoDB performance on virtualized Linux instances is directly influenced by kernel memory policies:

1. Reducing vm.swappiness

By default, Linux kernels exhibit an aggressive tendency to swap inactive memory pages to disk. Swapping database cache pages causes severe latency spikes. Lower swappiness to 1 (or 10) by updating /etc/sysctl.conf:

vm.swappiness = 1

Apply immediately using sudo sysctl -p.

2. Disabling Transparent Huge Pages (THP)

Transparent Huge Pages can cause memory fragmentation and aggressive allocation latency with database workloads. The official MongoDB documentation strongly advises disabling THP. Verify THP status and disable it via systemd service or kernel boot flags:

echo "never" | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo "never" | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

Storage Sizing on High-Speed NVMe

WiredTiger periodically flushes in-memory data to disk during checkpoint operations (typically every 60 seconds or 2 GB of journal data). Deploying on high-frequency instances—such as VPSWala's AMD Ryzen 9 9950X VPS with RAID NVMe storage—ensures that checkpoint flushes complete within milliseconds without freezing concurrent read threads.

Monitoring WiredTiger Cache Metrics with serverStatus

To inspect real-time cache behavior and verify whether your configured allocation is sufficient, query MongoDB's administrative statistics:

// Review cache statistics in mongosh
var cache = db.serverStatus().wiredTiger.cache;
print("Configured Cache: " + (cache["maximum bytes configured"] / (1024*1024)) + " MB");
print("In-Memory Bytes:  " + (cache["bytes currently in the cache"] / (1024*1024)) + " MB");
print("Tracked Dirty:    " + (cache["tracked dirty bytes in the cache"] / (1024*1024)) + " MB");

Monitor the proportion of tracked dirty bytes. WiredTiger background eviction threads initiate automatic eviction when dirty bytes reach 20% of the cache. If dirty bytes exceed 95%, MongoDB forces application client worker threads to perform synchronous eviction writes, causing significant query latency spikes. Maintaining balanced memory allocations prevents application threads from blocking on disk flushes.

Sources

• MongoDB Documentation: WiredTiger Storage Engine
• MongoDB Documentation: Configuration File Options