How does hardware memory throttling behave under thermal pressure?
In the world of mission-critical databases, we often monitor "CPU throttling," but Hardware Memory Throttling is the silent killer of predictable performance. When a server’s interior temperature spikes—due to high ambient heat, fan failure, or simply the extreme density of a high-performance database rack—the memory controllers take drastic action to prevent physical damage.
Here is how memory throttling behaves under thermal pressure and why it turns your database’s "predictable latency" into "random chaos."
Modern DDR4 and DDR5 DIMMs are equipped with TSOD (Thermal Sensor on DIMM) devices. When the DRAM chips cross specific thresholds (usually starting around 85°C), the BIOS/Firmware and the Memory Controller (iMC) enter a protective state.
There are two primary ways the hardware throttles memory to cool it down:
As DRAM gets hotter, the electrical charge in its capacitors leaks faster. To prevent data corruption, the memory controller must refresh the data more frequently.
The Action: The hardware doubles the refresh rate (e.g., from 7.8µs to 3.9µs).
The Database Impact: During a refresh cycle, the memory bank is unavailable for reads or writes. By doubling the refresh frequency, you are essentially doubling the "downtime" of your RAM. You’ll see a spike in "Read Latency" even if the workload hasn't changed.
If doubling the refresh rate isn't enough, the memory controller implements Bandwidth Throttling (often called "Clock Stretching" or "Duty Cycling").
The Action: The iMC intentionally inserts "delay cycles" between memory commands. It might only allow the memory to be active 50% of the time.
The Database Impact: This effectively slashes your memory bandwidth. If your Oracle instance is performing a Parallel Query or a full table scan, the throughput will drop linearly with the throttle percentage. This is often misdiagnosed as "Disk I/O" slowness, but the bottleneck is actually the RAM’s inability to accept data from the bus.
In a multi-socket database server, thermal pressure is rarely uniform.
The Scenario: Socket 0 is near the intake fans and stays cool. Socket 1 is behind the first CPU, soaking up "pre-heated" air, and begins to thermally throttle.
The Result: You now have a Performance Imbalance. Processes running on Socket 0 fetch memory at full speed, while threads on Socket 1 are throttled. For a database like RAC or SQL Server, this creates inter-thread skew, where one process holds a latch far longer than usual because its memory access is being delayed, causing a backlog for every other CPU in the system.
Since this happens at the hardware/firmware layer, it doesn't always show up in OS logs like dmesg. You have to look at the hardware counters:
| Tool | Indicator / Counter | What it means |
ipmitool | Memory_Throttling or Temp | Check if any DIMM is above 85°C. |
| Intel PCM | Memory_Throttling_Status | Direct hardware bit indicating if throttling is active. |
Linux perf | uncore_imc/data_reads | Sudden, unexplained drops in bandwidth while CPU is at 100%. |
If your database is hitting thermal memory limits, "tuning" the SQL won't help. You need hardware-level changes:
Memory Interleaving: As discussed in previous blogs, proper interleaving spreads the heat across all DIMMs. If you only populate a few channels, those DIMMs get "hotter" faster.
Fan Profiles: In the BIOS, switch the Thermal Profile from "Acoustic/Standard" to "Performance." This ramps the fans up earlier to keep DIMMs below the 85°C threshold.
LV (Low Voltage) DIMMs: If you are in a high-density environment, using DDR4L or DDR5 with lower voltage profiles reduces the TDP (Thermal Design Power) of the memory itself.
Hardware memory throttling is a protection mechanism, not a performance feature. When a database server gets too hot, the hardware sacrifices your $p99$ latency to save the physical silicon. If you see erratic performance during the hottest part of the day, stop looking at your execution plans and start looking at your DIMM temperatures.