Oracle HugePages not configured: page-table overhead and wasted SGA memory

When Oracle’s SGA runs on regular 4KB pages, the Linux kernel maintains a page table entry for every page the SGA touches. A 100GB SGA spans roughly 26 million 4KB pages. Every Oracle process that maps the SGA (dedicated servers, background processes, parallel slaves) carries page table structures tracking those mappings. This per-process page table overhead is invisible to Oracle’s own memory views: V$SGA, V$PGASTAT, and V$SGASTAT report the SGA as configured, not as the OS actually consumes it. You only see the overhead at the OS level in /proc/<oracle_pid>/status (the VmPTE field) or system-wide in /proc/meminfo (PageTables).

The practical consequence: a “100GB SGA” costs more than 100GB of physical RAM. On a system with hundreds of connected sessions, the combined page table footprint across all Oracle processes can reach several gigabytes. That is memory the database cannot use for buffer cache, PGA, or anything productive. It is pure kernel accounting overhead that silently shrinks the effective memory available for useful work.

The root cause is almost always one of three things: HugePages were never configured at the OS level, AMM (MEMORY_TARGET) is enabled and routes the SGA through /dev/shm (which bypasses HugePages entirely), or the database was started before HugePages were allocated and silently fell back to 4KB pages. The last case is the sneakiest: HugePages can be configured later, but the running instance will not pick them up until it is bounced.

What this means

Oracle on Linux uses 2MB HugePages by default. Each HugePage covers 512 regular 4KB pages. When the SGA is backed by HugePages, the kernel tracks the mapping with a single page table entry per 2MB chunk instead of per 4KB chunk. For a 100GB SGA, that reduces the entry count from roughly 26 million to roughly 50,000 per process. Per-process page table overhead drops from potentially hundreds of megabytes to a negligible amount.

Without HugePages, this overhead compounds with connection count. A system with 500 dedicated server processes, each carrying page table entries for a large shared SGA, can burn multiple gigabytes of RAM on page tables alone. That is RAM you paid for, RAM Oracle cannot see or report in any V$ view, and RAM that pushes the system toward the OOM killer.

The Linux OOM killer does not understand Oracle’s memory model. It sees large processes consuming lots of memory and kills them. When SGA page tables plus PGA plus OS needs exceed physical RAM, the OOM killer targets Oracle server processes. Sessions vanish without explanation. If a critical background process is killed, the instance may crash.

flowchart TD
    A[SGA on 4KB pages] --> B[Millions of PTEs per process]
    B --> C[VmPTE: hundreds of MB per process]
    C --> D[System PageTables: multiple GB]
    D --> E[Invisible to V$SGA and V$PGASTAT]
    E --> F[Effective free RAM shrinks]
    F --> G[OOM killer targets Oracle PIDs]

Common causes

Quick checks

All of these are read-only and safe to run on a production system.

# Check OS-level HugePages configuration
grep -i huge /proc/meminfo

# Check system-wide page table memory consumption
grep PageTables /proc/meminfo

# Find the pmon PID for your instance, then check its page table size
PMON_PID=$(pgrep -f "ora_pmon_${ORACLE_SID}" | head -1)
grep -E "Vm(PTE|Size)" /proc/${PMON_PID}/status

# Verify whether this instance is actually using HugePages.
# A non-zero "huge" count means the instance uses HugePages.
grep huge /proc/${PMON_PID}/numa_maps

# Check if AMM is creating shared memory files in /dev/shm
ls -lh /dev/shm/ | grep -i oracle

-- Check USE_LARGE_PAGES setting (should not be FALSE)
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'use_large_pages';

-- Check memory management mode (MEMORY_TARGET must be unset for HugePages)
SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME IN ('memory_target', 'memory_max_target', 'sga_target', 'sga_max_size');

-- Check actual SGA size
SELECT NAME, VALUE/1024/1024/1024 AS gb FROM V$SGA;

How to diagnose it

1. Confirm HugePages are configured at the OS level. Run grep -i huge /proc/meminfo. If HugePages_Total is 0, HugePages were never configured. If HugePages_Total is non-zero but HugePages_Free equals HugePages_Total, the pages are reserved but not consumed by any process.

2. Verify the database is actually using them. Find the pmon PID for the instance and check /proc/<pmon_pid>/numa_maps. If there are no lines containing “huge” with a non-zero count, the instance is running entirely on 4KB pages. This is the definitive check.

3. Rule out AMM. Query V$PARAMETER for memory_target and memory_max_target. If either is non-zero, the database is using Automatic Memory Management, which allocates the SGA through POSIX shared memory files in /dev/shm. This mechanism is fundamentally incompatible with HugePages. You will see files under /dev/shm owned by the oracle user.

4. Check the alert log for HugePages-related messages. When USE_LARGE_PAGES is set to ONLY and insufficient HugePages exist, the database fails to start. When set to TRUE (the non-Exadata default) and HugePages are insufficient or absent, the database starts on regular pages and logs a recommendation. Search the alert log for “HugePages” entries.

5. Measure the actual page table overhead. Pick a representative dedicated server process (not just pmon). Run grep VmPTE /proc/<oracle_pid>/status. The reported value is in KB. Multiply it by your typical connection count to estimate the aggregate overhead. Compare to /proc/meminfo PageTables for the system-wide figure.

6. Check for OOM killer activity. Run dmesg | grep -i "out of memory\|oom" and check /var/log/messages. If the OOM killer has targeted Oracle PIDs, page table overhead may be contributing to memory pressure alongside SGA and PGA.

Metrics and signals to monitor

Fixes

If AMM is enabled: switch to ASMM

AMM (MEMORY_TARGET / MEMORY_MAX_TARGET) manages SGA and PGA together through /dev/shm memory-mapped files. This is incompatible with HugePages. Oracle documentation explicitly states that AMM is not recommended on Linux for this reason.

To switch to ASMM (Automatic Shared Memory Management), which uses System V shared memory and is compatible with HugePages:

-- Requires a database restart to take effect
ALTER SYSTEM SET memory_target = 0 SCOPE = SPFILE;
ALTER SYSTEM SET memory_max_target = 0 SCOPE = SPFILE;
ALTER SYSTEM SET sga_target = <desired_sga_size> SCOPE = SPFILE;
ALTER SYSTEM SET pga_aggregate_target = <desired_pga_size> SCOPE = SPFILE;

This is disruptive: the database must be bounced.

Allocate HugePages at the OS level

Calculate the number of HugePages needed. Oracle provides the hugepages_settings.sh script (MOS Doc ID 401749.1) for this purpose. Prerequisites: all databases must be running, and AMM must be disabled. Running the script with AMM enabled or with databases stopped produces incorrect values.

A rough manual calculation: nr_hugepages = ceil(SGA_SIZE_BYTES / Hugepagesize). Leave a small buffer. Oracle recommends reserving no more than 70% of total RAM for HugePages, keeping at least 30% available for regular pages used by PGA and the OS.

# Set at runtime (may fail if memory is fragmented; reboot is more reliable)
sysctl -w vm.nr_hugepages=<calculated_value>

# Make persistent across reboots
echo "vm.nr_hugepages = <calculated_value>" >> /etc/sysctl.d/99-oracle-hugepages.conf

Setting vm.nr_hugepages at runtime may fail if the kernel cannot find enough contiguous memory. A reboot guarantees allocation.

Set memlock limits

The oracle OS user needs permission to lock HugePages in memory. Set the memlock limit in /etc/security/limits.conf (or the equivalent in your PAM configuration) to at least the size of the HugePages pool in KB.

oracle soft memlock <value_in_kb>
oracle hard memlock <value_in_kb>

The minimum value is the SGA size (or the total HugePages allocation) in KB. A common approach is to set memlock to at least 90% of total physical RAM in KB, which leaves headroom for future SGA growth. Verify the limit takes effect by logging in as the oracle user and running ulimit -l.

Configure USE_LARGE_PAGES

Set USE_LARGE_PAGES to control Oracle’s HugePages behavior:

Exact defaults differ by deployment automation and cloud platform; verify the installed database’s value in V$PARAMETER rather than assuming all Exadata hosts are identical.

ALTER SYSTEM SET use_large_pages = ONLY SCOPE = SPFILE;

ONLY is the safest choice for catching misconfiguration early: the database refuses to start without HugePages rather than silently degrading.

Handle Transparent HugePages

Transparent HugePages (THP) is a separate kernel feature from explicit HugePages. Oracle’s guidance differs by version:

• On UEK7 and later kernels with 23ai: Oracle recommends setting THP to madvise rather than disabling it.
• On earlier releases or kernels that lack the UEK7 guidance: follow the version-specific installation guidance; older guidance commonly recommends never.
• Check the active policy after boot and after kernel or tuned changes.

On RHEL7/OL7 and later, the tuned profile may re-enable THP after boot even if grub is configured. Create a custom tuned profile that sets the THP value persistently.

Before using 1GB HugePages, validate support and sizing guidance for the exact kernel and Oracle release; standard 2MB HugePages are the common supported configuration for Oracle SGA deployment.

Bounce the database to activate HugePages

A running instance will not switch to HugePages dynamically. Even if you allocate HugePages at the OS level while the database is running, the SGA remains on 4KB pages until the instance restarts. This is the single most common cause of “HugePages configured but not used.”

After configuring HugePages, memlock, and USE_LARGE_PAGES, schedule a maintenance window and restart the database. After restart, re-run the numa_maps check on the pmon process to confirm HugePages are in use.

RAC: account for GIMR

On RAC clusters, the Grid Infrastructure Management Repository (GIMR) consumes HugePages before database instances start. If the total HugePages pool is insufficient to cover GIMR plus all database SGAs, database instances may silently fall back to regular pages. Size the HugePages pool to cover GIMR requirements (up to approximately 1GB) plus all database SGAs.

Prevention

• Bake HugePages configuration into provisioning templates. The vm.nr_hugepages sysctl, memlock limits, THP settings, and USE_LARGE_PAGES should all be part of your AMI, kickstart, or Terraform configuration for Oracle hosts. Do not leave HugePages as a post-install manual step.

• Use USE_LARGE_PAGES = ONLY or AUTO_ONLY. These values make misconfiguration fail loudly at startup instead of silently degrading. A database that refuses to start because HugePages are insufficient is a better outcome than a database that starts on 4KB pages and slowly drives the system toward OOM.

• Verify after every bounce. After any database restart, check /proc/<pmon_pid>/numa_maps for “huge” entries. This catches cases where HugePages were accidentally reduced or AMM was inadvertently enabled.

• Monitor HugePages utilization. Track HugePages_Total, HugePages_Free, and system-wide PageTables from /proc/meminfo. A sudden increase in PageTables or HugePages_Free after a restart indicates the instance fell back to 4KB pages.

• Avoid AMM on Linux. Use ASMM (SGA_TARGET + PGA_AGGREGATE_TARGET) instead. This is an explicit Oracle recommendation for Linux deployments.

How Netdata helps

• OS-level memory visibility that Oracle views lack. Netdata collects /proc/meminfo at per-second granularity, including PageTables, HugePages_Total, and HugePages_Free. This exposes the page table overhead that V$SGA and V$PGASTAT cannot see.

• Correlation between connection count and page table growth. When page table memory scales with session count, Netdata’s per-second charts let you see the relationship between connection spikes and PageTables growth in the same time window.

• HugePages consumption tracking. A drop in HugePages_Free to zero (or HugePages_Total going to zero after a reboot) signals that the instance lost its HugePages backing. Without monitoring, this is discovered only when OOM kills start.

• OOM killer detection. Netdata surfaces kernel OOM events. Correlating these with memory utilization charts and Oracle process counts pinpoints whether page table overhead contributed to the kill.

• Memory pressure before it bites. Tracking MemAvailable alongside SGA and PGA trends gives early warning when effective free RAM is shrinking due to invisible page table consumption.

Netdata’s Oracle Database monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

Related guides

• How Oracle Database actually works in production: a mental model for operators
• Oracle archive log destination full: V$ARCHIVE_DEST_STATUS, the ERROR state, and space
• Oracle autoextend hit MAXSIZE: the space gotcha with a half-empty filesystem
• Oracle blocking sessions: finding the blocker at the head of the chain
• Oracle ‘buffer busy waits’: hot blocks, sequence headers, and index leaf splits
• Oracle ‘Thread N cannot allocate new log’: the archive hang that masquerades as up
• Oracle ‘Checkpoint not complete’: redo log sizing, DBWn, and log-switch stalls
• Oracle ‘cursor: pin S wait on X’: mutex contention on hot cursors
• Oracle ‘db file scattered read’: multiblock reads, full scans, and plan regressions
• Oracle ‘db file sequential read’: single-block index reads and buffer cache misses
• Oracle ’enq: TM - contention’: unindexed foreign keys and table-level locks
• Oracle ’enq: TX - row lock contention’: blocking sessions and uncommitted DML