How to Optimize MongoDB on Linux Server – Easy Guide

How to Optimize MongoDB on Linux Server: start by tuning the OS (XFS filesystem, disable Transparent Huge Pages, set proper ulimit, sysctl, and NUMA), then configure mongod (WiredTiger cache, journaling, compression, security), and finally optimize schema, indexes, and queries. Monitor with mongostat/mongotop and Linux tools, and scale via replica sets or sharding as needed.

Optimizing MongoDB on a Linux server means balancing the operating system, MongoDB configuration, and workload design. In this guide, we’ll walk through practical, production-tested steps to improve throughput, reduce latency, and keep your database stable. Whether you run MongoDB on bare metal, VM, or cloud instances, these best practices will help you extract consistent performance.

Quick Optimization Checklist

• Use XFS on fast disks (NVMe SSD preferred) with appropriate mount options.
• Disable Transparent Huge Pages (THP) and tune swappiness and dirty ratios.
• Fix NUMA behavior, increase file descriptors, and tune TCP/kernel parameters.
• Right-size WiredTiger cache and choose the right compression (zstd/snappy).
• Design schema for reads, create selective compound indexes, and avoid heavy skip/limit.
• Monitor with mongostat, mongotop, and Linux perf tools; profile queries and use explain().
• Scale with replica sets and sharding as your working set grows.

Server and OS-Level Tuning (Linux)

Filesystem and Disks

MongoDB recommends XFS for WiredTiger. Use fast SSDs/NVMe. For general-purpose workloads on Linux kernels 4.x+ and MongoDB 4.4–7.x, XFS delivers excellent concurrency and predictable latency.

• Disks: Prefer NVMe SSDs; provision adequate IOPS on cloud volumes.
• Filesystem: Use XFS; ext4 is acceptable but typically slower under contention.
• Mount options: noatime,nodiratime can reduce metadata writes in read-heavy workloads.

# Example: format and mount XFS
sudo mkfs.xfs -f /dev/nvme0n1
sudo mkdir -p /var/lib/mongo
echo '/dev/nvme0n1 /var/lib/mongo xfs noatime,nodiratime,inode64 0 0' | sudo tee -a /etc/fstab
sudo mount -a

Disable Transparent Huge Pages (THP)

THP can cause latency spikes for databases. Disable it permanently to keep memory allocation predictable.

# Temporary (until reboot)
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Persistent with GRUB
sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="transparent_hugepage=never /' /etc/default/grub
sudo update-grub && sudo reboot

NUMA and CPU Affinity

On multi-socket servers, Non-Uniform Memory Access (NUMA) can skew memory locality. Run mongod with interleaved memory or pin it appropriately.

# Systemd override to interleave memory across NUMA nodes
sudo systemctl edit mongod

# Insert:
[Service]
ExecStart=
ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf

sudo systemctl daemon-reload
sudo systemctl restart mongod

Kernel, Readahead, and I/O Scheduler

Modern NVMe prefers the “none” scheduler. Reduce readahead for random-access workloads to cut unnecessary I/O.

# Readahead (lower for random workloads)
sudo blockdev --setra 32 /dev/nvme0n1

# Verify current scheduler
cat /sys/block/nvme0n1/queue/scheduler
# For NVMe it is often 'none' by default on newer kernels

ulimit and File Descriptors

MongoDB needs many file handles for connections and journal/data files. Increase limits via systemd.

sudo systemctl edit mongod

# Insert:
[Service]
LimitNOFILE=100000
LimitNPROC=64000

sudo systemctl daemon-reload
sudo systemctl restart mongod

sysctl Network and Memory Tuning

Keep swapping minimal and increase network backlog to handle bursts.

sudo tee /etc/sysctl.d/99-mongodb.conf >/dev/null <<'EOF'
vm.swappiness=1
vm.dirty_background_ratio=5
vm.dirty_ratio=15
net.core.somaxconn=1024
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_keepalive_time=120
EOF

sudo sysctl --system

MongoDB Configuration (mongod.conf) Best Practices

WiredTiger Cache and Compression

By default, WiredTiger uses about 50% of RAM minus a safety margin. If MongoDB contends with other services, set cacheSizeGB explicitly. Use zstd for balanced compression ratio and speed; snappy is faster with lower compression.

# /etc/mongod.conf
storage:
  dbPath: /var/lib/mongo
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 32        # Example for a 64–96 GB RAM server; adjust to your box
    collectionConfig:
      blockCompressor: zstd  # Alternatives: snappy, zlib

net:
  bindIp: 127.0.0.1,10.0.0.10
  port: 27017

security:
  authorization: enabled

setParameter:
  ttlMonitorSleepSecs: 60
  failIndexKeyTooLong: true
  diagnosticDataCollectionEnabled: true

Journaling, Write Concern, and Read Concern

Keep journaling enabled for durability. Use writeConcern and readConcern appropriate to your SLA: w:1 for speed, w:majority for strong durability across a replica set. For read-mostly apps, local or available read concerns can reduce latency; for critical reads, use majority.

Replica Set Oplog Sizing

Ensure your oplog holds several hours (often 24+ hours) of traffic to tolerate maintenance and lag. Resize during maintenance windows to avoid rollover during peak load.

# Resize oplog (run on primary, MongoDB Shell)
use local
db.adminCommand({ replSetResizeOplog: 1, size: 51200 })  // ~50 GB example

Profiling and Slow Query Threshold

Enable the profiler at level 1 in non-peak windows or set slowOpThresholdMs to capture problematic operations without high overhead.

# In mongosh
db.setProfilingLevel(1, { slowms: 100 })  // Log ops slower than 100 ms

Schema Design and Query Optimization

Design for Access Patterns

MongoDB performs best when documents model how your app reads data. Embed data that is read together and updated atomically; reference when subdocuments grow unbounded or are shared across many parents. Keep documents well below the 16 MB limit.

Indexing Strategy That Scales

• Create selective, compound indexes that match your most common query predicates and sort orders (prefix rule applies).
• Avoid over-indexing: each index costs RAM and write amplification.
• Use TTL indexes for time-based data to auto-expire old documents.
• Ensure unique constraints (e.g., on emails) with unique indexes.

// Examples
db.users.createIndex({ email: 1 }, { unique: true })
db.orders.createIndex({ customerId: 1, createdAt: -1 })  // filter + sort
db.sessions.createIndex({ expiresAt: 1 }, { expireAfterSeconds: 0 })  // TTL

Use explain() and Covered Queries

Always inspect execution plans to confirm index usage, cardinality, and scanned vs. returned docs. Covered queries (when all fields come from the index) avoid document fetches and reduce I/O.

// Check plan and stats
db.orders.find(
  { customerId: ObjectId("..."), status: "PAID" },
  { _id: 0, orderId: 1, total: 1 }
).sort({ createdAt: -1 }).explain("executionStats")

Pagination Without skip()

Deep skip/limit is expensive. Use range-based pagination with an indexed field (e.g., createdAt or _id).

// Page 1
db.posts.find().sort({ _id: 1 }).limit(50)

// Subsequent pages
db.posts.find({ _id: { $gt: ObjectId("last_seen_id") } })
        .sort({ _id: 1 }).limit(50)

Aggregation Pipeline Tips

• Push $match and $project to the earliest stages to shrink data quickly.
• Align $sort with an index; consider compound indexes to support $match + $sort.
• Use $facet carefully; it can materialize large intermediates.

Monitoring and Troubleshooting

MongoDB Built-in Tools

• mongostat: High-level throughput and queue metrics.
• mongotop: Collection-level read/write time distribution.
• ServerStatus: In-depth metrics (wiredTiger cache, queues, connections).

mongostat --discover 1
mongotop 5
mongosh --eval 'db.serverStatus().wiredTiger.cache'

Linux Observability Stack

• iostat, pidstat, vmstat, sar: Spot CPU steal, I/O waits, run queues.
• perf and eBPF tools: Pinpoint kernel-level bottlenecks and allocator stalls.
• Cloud metrics: Verify disk IOPS/throughput throttling and burst credits.

Query Profiling and Logs

Use the profiler and logs to find slow collections and outlier queries. Combine with explain() to decide whether to add or adjust indexes, rewrite filters, or refactor the schema.

Scaling and High Availability

Vertical Scale vs. Sharding

• Scale up first: more RAM reduces page faults and boosts cache hit rate.
• Shard when a single node’s working set exceeds memory or you need horizontal write scale.
• Use hashed sharding for uniform distribution; range sharding for range queries (with zone sharding for data locality).

Replica Set Tuning

• Priorities: Keep primary on the strongest node/storage.
• Hidden secondaries: Offload analytics without impacting primary.
• Read preferences: Use nearest for geo-distributed reads when consistency allows.

Backups and Consistency

• Use filesystem snapshots (LVM, cloud snapshots) with fsyncLock/fsyncUnlock for consistency.
• Regularly test restores; stale backups give false confidence.
• Consider point-in-time recovery via oplog backups for mission-critical data.

Step-by-Step Linux Hardening Script (Starter)

Test in staging first. Values below are sane defaults for NVMe-backed servers and general OLTP workloads.

#!/usr/bin/env bash
set -euo pipefail

# 1) Disable THP (runtime)
for f in /sys/kernel/mm/transparent_hugepage/enabled /sys/kernel/mm/transparent_hugepage/defrag; do
  [[ -f "$f" ]] && echo never | sudo tee "$f"
done

# 2) Kernel params
sudo tee /etc/sysctl.d/99-mongodb.conf >/dev/null <<'EOF'
vm.swappiness=1
vm.dirty_background_ratio=5
vm.dirty_ratio=15
net.core.somaxconn=1024
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_keepalive_time=120
EOF
sudo sysctl --system

# 3) Systemd limits and NUMA interleave (if using system mongod service)
sudo systemctl edit mongod <<'EOF'
[Service]
LimitNOFILE=100000
LimitNPROC=64000
ExecStart=
ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf
EOF
sudo systemctl daemon-reload
sudo systemctl restart mongod

# 4) Reduce readahead on data device
sudo blockdev --setra 32 /dev/nvme0n1 || true

echo "Baseline tuning applied. Verify with: mongostat, mongotop, iostat -x, vmstat 1"

Common Pitfalls to Avoid

• Relying on ext4 on busy OLTP workloads where XFS would perform better.
• Leaving THP enabled and NUMA unmanaged, causing latency spikes.
• Over-indexing collections, wasting RAM and slowing writes.
• Using skip/limit for deep pagination; switch to range-based pagination.
• Running with undersized oplog leading to frequent rollovers and replication lag.
• Choosing low-IOPS cloud disks or RAID5 for write-heavy workloads (prefer NVMe or RAID10).
• Ignoring slow query logs and not validating plans with explain().

Why Host MongoDB with YouStable

As a hosting provider focused on databases and performance, YouStable deploys MongoDB on tuned Linux stacks: NVMe storage, XFS, THP disabled, right-sized WiredTiger cache, and proactive monitoring. Our engineers handle replica sets, backups, and security hardening so your workloads stay fast and resilient. Need a smooth migration or 24/7 support? We’re ready to help.

FAQs: How to Optimize MongoDB on Linux Server