Configuring Static HugePages for Oracle Database 19c/23ai on Linux (OL8/OL9): Math, Calculation & Troubleshooting Runbook

Production guide to configuring static 2MB/1GB HugePages for Oracle Database SGA on Oracle Linux 8 and 9—including mathematical calculation scripts, memlock limits, ORA-27102/ORA-27125 troubleshooting, and USE_LARGE_PAGES initialization.

⚡ BLUF (Bottom Line Up Front) Summary

⚠️ Advisory Scope & Terms

Configuring static HugePages (2MB or 1GB) for Oracle Database SGA on Linux eliminates page table RAM bloat, prevents OS swap thrashing, and reduces CPU kernel overhead. DBAs must disable Transparent HugePages (THP=never), calculate exact HugePages using kernel scripts, set memlock in /etc/security/limits.conf, and set USE_LARGE_PAGES=ONLY in init.ora.

Environment & Prerequisites

ComponentVersion / Specification
OSOracle Linux 8.x / 9.x (UEK R6/R7/R8) & RHEL
DatabaseOracle Database 19c / 23ai (Single Instance & RAC)
Memory Parametersvm.nr_hugepages, memlock, USE_LARGE_PAGES
Page Sizes2MB (Default HugePages) & 1GB (Gigabyte HugePages)

Executive Summary: The 4KB Linux Page Table Bottleneck

y default, Linux manages memory using standard 4KB memory pages. For small web servers, 4KB pages work well. However, for enterprise Oracle Database hosts running large System Global Areas (SGA) ranging from 32GB to 512GB+, 4KB pages create severe performance degradation.

The Math Behind Page Table Bloat:

  • A 64GB SGA using standard 4KB pages requires 16,777,216 individual page table entries.
  • Every single database foreground process (e.g. 500 active user sessions) maintains its own copy of these page table mappings.
  • Result: The Linux kernel consumes 10GB to 25GB+ of RAM strictly to maintain page tables, starving physical memory, causing high CPU kernel overhead (system %), and triggering latch: shared pool contention.

By configuring static 2MB HugePages (or 1GB HugePages for VLDBs), the number of page table entries for a 64GB SGA drops from 16.7 million down to 32,768, eliminating page table RAM bloat and boosting database performance by 15% to 30%.


Technical Architecture & Memory Allocation Flow

<div class="process-flow">
  <div class="process-step">
    <div class="step-number">Step 1</div>
    <div class="step-title">Disable Dynamic THP (transparent_hugepage=never)</div>
  </div>
  <div class="process-arrow">➔</div>
  <div class="process-step">
    <div class="step-number">Step 2</div>
    <div class="step-title">Calculate & Allocate Static vm.nr_hugepages & memlock</div>
  </div>
  <div class="process-arrow">➔</div>
  <div class="process-step">
    <div class="step-number">Step 3</div>
    <div class="step-title">Enforce USE_LARGE_PAGES=ONLY in Oracle init.ora</div>
  </div>
</div>

🔍 Diagnostic Checklist: Audit HugePages on Your Host

Execute these terminal commands on your database server host to inspect your current HugePages configuration:

Diagnostic 1: Check Current Page Table RAM Usage & HugePages Allocation

grep -E "PageTables|HugePages_|Hugepagesize" /proc/meminfo

How to Interpret Results:

  • 🚨 PageTables: 18452100 kB (~18GB): High page table overhead! The host is running standard 4KB pages without HugePages.
  • 🚨 HugePages_Total: 0: Static HugePages are NOT configured on the system.
  • transparent_hugepage = always: Dynamic Transparent HugePages (THP) is enabled, causing dynamic allocation freezes under high OLTP load.

Step-by-Step Production Runbook

Step 1: Disable Transparent HugePages (THP)

Transparent HugePages (THP) attempts to allocate 2MB pages dynamically at runtime, causing dynamic memory defragmentation locks (khugepaged). Oracle strictly mandates disabling THP.

Add transparent_hugepage=never to your GRUB boot configuration:

# Modify GRUB boot arguments on Oracle Linux 8 / 9
grubby --update-kernel=ALL --args="transparent_hugepage=never"

# Verify immediate runtime status
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

Step 2: Calculate Exact Static HugePages Required

The number of 2MB HugePages required must cover the total SGA size of all database instances running on the host, plus a small buffer (~5%).

Calculation Formula:

  • Base 2MB HugePages = 64 GB SGA (67,108,864 KB) / 2,048 KB = 32,768 Pages
  • Buffer Allocation (+100 Pages) = 32,768 + 100 = 32,868 Pages

Official Calculation Script (hugepages_settings.sh):

#!/bin/bash
# Calculate nr_hugepages for running Oracle instances (MOS Doc 401749.1)
SGA_TOTAL_KB=0
for sga_kb in $(ps -ef | grep pmon | grep -v grep | awk '{print $8}' | while read pmon; do
    ORACLE_SID=${pmon#*pmon_}
    echo "SELECT SUM(bytes)/1024 FROM v\$sgastat;" | sqlplus -s "/ as sysdba" | grep -E "^[0-9]"
done); do
    SGA_TOTAL_KB=$((SGA_TOTAL_KB + ${sga_kb%.*}))
done
echo "Recommended vm.nr_hugepages = $(( (SGA_TOTAL_KB / 2048) + 100 ))"

Step 3: Configure /etc/sysctl.conf & /etc/security/limits.conf

Once you determine the required HugePages count (e.g. 32868 HugePages for a 64GB SGA):

1. Persist HugePages Count in /etc/sysctl.conf:

# Add to /etc/sysctl.conf (for 64GB SGA)
vm.nr_hugepages = 32868

Apply sysctl settings:

sysctl -p

2. Configure memlock Limits in /etc/security/limits.conf:

memlock defines the maximum locked memory in KB that the oracle user can allocate. It MUST be slightly larger than the total HugePages allocation size (e.g., for 64GB SGA, set memlock to at least 68000000 KB):

# Add to /etc/security/limits.conf
oracle   soft   memlock   68000000
oracle   hard   memlock   68000000

Step 4: Enforce USE_LARGE_PAGES = ONLY in Database init.ora

By default, Oracle uses USE_LARGE_PAGES = TRUE, which means if static HugePages are undersized, Oracle will silently fall back to slow 4KB pages without warning!

To guarantee that your database allocates HugePages and refuses to start if HugePages are misconfigured, set USE_LARGE_PAGES = ONLY:

-- Enforce mandatory HugePages allocation
ALTER SYSTEM SET USE_LARGE_PAGES = 'ONLY' SCOPE = SPFILE;

-- Shutdown and restart database to allocate HugePages
SHUTDOWN IMMEDIATE;
STARTUP;

💥 Common Troubleshooting & Errors

1. ORA-27102: out of memory / ORA-27125: unable to create shared memory segment

  • Root Cause: memlock in /etc/security/limits.conf is smaller than the requested SGA size, or vm.nr_hugepages is undersized.
  • Resolution: Increase memlock to match total physical SGA requirements and re-run sysctl -p.

2. ORA-27137: unable to allocate large pages

  • Root Cause: USE_LARGE_PAGES is set to ONLY, but vm.nr_hugepages is smaller than SGA_TARGET.
  • Resolution: Increase vm.nr_hugepages in /etc/sysctl.conf or decrease SGA_TARGET.

📚 Official Documentation & Technical References

Execute Oracle’s official calculation logic (MOS Doc ID 401749.1) to compute vm.nr_hugepages across active instances:


Need assistance optimizing your Oracle Linux host memory, kernel parameters, or SGA sizing? Contact our Infrastructure Specialists or explore our Enterprise Health Audits.

⚠️INFORMATIONAL & TECHNICAL ADVISORY DISCLAIMER

The diagnostic methodologies, commands, and runbooks provided on DBPros.Net are published for informational and educational purposes only. They do not constitute customized professional consulting advice. Operating engineers and DBAs are solely responsible for securing pre-flight backups (RMAN, VM snapshots, LVM clones), validating changes in non-production staging environments, and adhering to organizational change-control policies. All content, scripts, and runbooks are provided "AS IS" without warranty of any kind, and DBPros.Net assumes no liability for system downtime, database corruption, data loss, or operational disruption. For complete advisory limitations and legal terms, view our full Terms of Service & Advisory Disclaimer.