What is impact of redo log placement on NUMA topology?
When you run these workloads on large, multi-socket servers, the NUMA (Non-Uniform Memory Access) topology becomes a critical factor. If your redo log buffers and your LGWR process are on different "NUMA nodes," you are essentially forcing your most time-sensitive data to take a "slow bus" across the CPU interconnect.
A modern server consists of multiple CPU sockets, each with its own local memory controller.
Local Access: CPU 0 accessing RAM connected to CPU 0 (Latency: ~100ns).
Remote Access: CPU 0 accessing RAM connected to CPU 1 via the interconnect (Latency: ~200ns+).
In a 1M TPS system, the Redo Log Buffer (the memory area where changes are staged) is accessed constantly. If the Oracle Log Writer (LGWR) process is running on Node 0, but the memory allocated for the log buffer is on Node 1, every single write operation pays a 100% latency penalty just to cross the CPU socket.
At 1M TPS, the LGWR is one of the busiest processes in the system.
The Conflict: If the LGWR is scheduled on a CPU core that doesn't "own" the memory where the redo log buffers reside, the CPU must use the Intel UPI or AMD Infinity Fabric to fetch the data.
The 1M TPS Risk: These interconnects have finite bandwidth. If other processes (like background backups or heavy analytics) are also saturating the interconnect, the LGWR's "Commit" signal gets delayed. This manifests as erratic "Log File Sync" times, even if your underlying NVMe disks are lightning-fast.
To achieve deterministic 1M TPS, you must align your software processes with the physical silicon topology.
You should ensure that the SGA (System Global Area), which contains the Redo Log Buffer, is pinned to the same NUMA node where the LGWR process is likely to run.
Oracle Parameter: _enable_numa_support=TRUE (though often managed at the OS level now).
OS Level: Use numactl to bind the Oracle instance or specific high-priority background processes to specific cores and memory banks.
In 2026, we use CPU Pinning (Affinity) to ensure the LGWR has a "dedicated lane."
The Strategy: Reserve "Core 0" on "Node 0" exclusively for the LGWR and its helper processes (LGNN).
The Result: This prevents the OS from migrating the LGWR to a different NUMA node, which would suddenly double its memory access latency.
| Metric | Cross-NUMA Placement | NUMA-Aligned Placement |
| Log File Sync | High Jitter (1ms – 5ms) | Stable (<1ms) |
| CPU Interconnect Load | High (Redo data constantly crossing) | Low (Traffic stays local) |
| Transaction Throughput | Hits a "ceiling" at high concurrency | Scales Linearly |
| Context Switch Overhead | High (due to remote memory stalls) | Minimum |
In high-end 1M TPS setups, the Redo Log isn't on a standard SSD; it's on Persistent Memory (like Intel Optane or CXL-based PMEM).
The Catch: PMEM is physically plugged into a specific DIMM slot on a specific NUMA node.
The Rule: If your Redo Log resides on PMEM attached to Node 1, your LGWR must be pinned to Node 1. If it migrates to Node 0, you lose almost all the performance benefits of the expensive PMEM hardware.
At 1M TPS, Distance is Death. To keep your redo logs moving at the speed of the hardware:
Map your NUMA topology using lscpu or numactl -H.
Align your SGA so the Redo Log Buffer lives on the same node as your disk/NIC controllers.
Pin the LGWR process to the CPU cores physically closest to that memory.