AMD Opteron: How Servers Opened the VIP Door for AMD

If you’ve ever stared at a dashboard where CPU looks “fine,” disks look “fine,” and yet the app is crawling like it’s hauling a refrigerator uphill,
you already understand why Opteron mattered. It wasn’t just “another CPU.” It was AMD walking into the server room—where budgets are real and
excuses are not—and handing admins a set of knobs that actually moved the needle.

Opteron didn’t win because it was cute. It won because it made the system behave: memory latency fell, multi-socket scaling stopped being a
science project, and 64-bit arrived without forcing the industry to torch its software stack.

The VIP door: why servers were the only room that mattered

Consumers buy CPUs on vibes and benchmarks. Enterprises buy them on outcomes: predictable latency, stable scaling, and the ability to upgrade
without rewriting a decade of software. That’s why the server market is the VIP door. Once you’re trusted in production, your logo migrates
from “interesting” to “approved vendor.” And “approved vendor” is where the money lives.

In the early 2000s, Intel owned the narrative in servers. “Xeon” meant safe. “Itanium” was positioned as the future. AMD was the scrappy
alternative—often excellent, sometimes ignored, rarely invited to the big table. Opteron changed the social geometry.

The key is that Opteron didn’t just try to beat Intel on raw CPU. It attacked system performance where real workloads suffer:
memory bandwidth, memory latency, multi-socket coherency, and upgrade compatibility. The result wasn’t merely “faster.” The result was fewer
ugly surprises at 2 a.m.

Historical facts that explain the shift (no mythology)

• Opteron launched in 2003, and it brought x86-64 (AMD64) to servers while keeping 32-bit software working.
• Intel originally bet on Itanium (EPIC/IA-64) for 64-bit enterprise computing, expecting x86 to fade out in high-end servers.
• AMD’s integrated memory controller moved memory access off the northbridge, cutting latency and boosting bandwidth in real workloads.
• HyperTransport replaced the old front-side bus model for CPU-to-CPU and CPU-to-chipset links, helping multi-socket scaling.
• Linux distributions adopted AMD64 early, and that mattered: ops teams could test and deploy without waiting for proprietary ecosystems.
• Major OEMs shipped Opteron servers—the procurement signal that “this isn’t a science fair project.”
• Virtualization got a practical runway: even before hardware virtualization extensions matured, AMD64 made address space and consolidation less painful.
• NUMA stopped being theoretical: multi-socket x86 servers became clearly NUMA, and software had to admit it.
• Intel later adopted essentially the same 64-bit model (Intel 64/EM64T), validating AMD’s strategy: evolve x86, don’t replace it.

What Opteron changed technically—and why operators cared

1) The integrated memory controller: fewer lies between you and RAM

In the old shared front-side bus (FSB) world, CPUs were like roommates sharing one narrow hallway to the kitchen. Everybody could cook.
Just not at the same time. Opteron put the kitchen inside each CPU package by integrating the memory controller. Each socket had its own
direct path to RAM.

For operators, this manifested as something you can feel:

• Lower memory latency under load—less tail-latency weirdness in database and JVM workloads.
• More predictable scaling when adding sockets, because memory bandwidth scaled more linearly (with caveats, because NUMA).
• Better “real” performance in workloads that look modest in CPU utilization but are secretly memory-bound.

The integrated memory controller also forced a cultural change: you can’t pretend memory is “uniform” anymore. If a thread on socket 0 is
hammering memory attached to socket 1, that’s not “just RAM.” That’s a remote access penalty, and it shows up as latency.

2) HyperTransport: scaling that didn’t require prayer

HyperTransport gave Opteron a high-speed point-to-point interconnect. Instead of all CPUs fighting over one shared bus, sockets could
communicate more directly, and coherency traffic had somewhere to go besides “shout louder on the FSB.”

This mattered for two classic enterprise problems:

• Multi-socket scaling without hitting a shared bus wall immediately.
• I/O paths that didn’t collapse under mixed workloads (network + storage + memory pressure) as quickly as earlier designs.

3) x86-64 as a compatibility strategy, not a purity test

AMD64 worked because it didn’t ask the world to throw away its software. That’s the quiet genius. 64-bit wasn’t sold as “a new religion.”
It was sold as “your existing stuff still runs, and now you can address more memory without losing your weekend.”

That’s not marketing fluff. That’s operational math. Enterprises don’t upgrade by flipping a switch. They upgrade by piloting, validating,
migrating, and keeping rollback plans. AMD64 fit that reality.

4) NUMA becomes the tax you must file

NUMA isn’t optional in multi-socket Opteron-era servers. You either understand it, or you pay interest later. Local memory access is faster.
Remote memory access is slower. Bandwidth isn’t infinite. Cache coherency isn’t free. And your database doesn’t care about your vendor slide deck.

If you learned one habit from Opteron, it should be this: always ask, “Where is the memory relative to the CPU doing the work?”

AMD64 vs Itanium: the fork in the road

Itanium was the “new architecture” path: a clean break, a big promise, and a big requirement—port your software. AMD64 was the “keep moving”
path: extend x86, keep compatibility, get to 64-bit without detonating your ecosystem.

If you run production systems, you know how this movie ends. The platform that asks for the least rewriting wins, assuming performance is good
enough and the tooling isn’t a catastrophe. AMD64 hit that sweet spot.

There’s a reliability angle here too. New architectures introduce new compiler behaviors, new library edge cases, new performance cliffs,
and new “this worked on the old platform” bugs. Some of that is inevitable. But multiplying it across an entire fleet is how you create
a career in incident response.

One joke, because we’ve earned it: Itanium was the kind of “future” that always arrived right after the next maintenance window.

NUMA: the feature that paid rent and caused fights

NUMA is a two-faced friend. When you align compute with local memory, performance is gorgeous. When you don’t, you get jitter that looks like
application bugs, but is really the hardware reminding you it exists.

Opteron made NUMA mainstream in x86 server rooms. It forced developers and operators to take affinity seriously: CPU pinning, memory policy,
IRQ placement, and interrupt distribution.

The trick is not to “tune everything.” The trick is to tune the one or two things that are actually limiting you: memory locality, I/O
interrupts, and scheduler behavior under contention.

One reliability paraphrased idea, because it’s still true: Paraphrased idea — John Ousterhout: measure first; most performance and reliability wins come from fixing the real bottleneck, not guessing.

Three corporate mini-stories from the trenches

Mini-story #1: The incident caused by a wrong assumption

A mid-sized enterprise ran a latency-sensitive billing system on dual-socket servers. The team migrated from an older Xeon platform to
Opteron-based machines because the price/performance looked fantastic and the vendor promised “easy drop-in.”

The migration went smoothly until month-end close. Suddenly, API latency doubled, and the database started logging intermittent stalls.
CPU utilization stayed around 40–50%. Storage graphs looked calm. Everyone blamed the application.

The wrong assumption: “Memory is memory; if there’s enough, it doesn’t matter where it lives.” On Opteron, it absolutely mattered.
The DB process had threads bouncing across sockets while its hottest memory pages were allocated mostly on one node. Remote memory traffic
went up, latency followed, and the workload fell into a bad feedback loop: slower queries held locks longer, increasing contention, increasing
cache-line ping-pong.

The fix wasn’t exotic. They pinned DB worker threads to cores, enforced NUMA-aware memory allocation (or at least interleaving for that workload),
and moved NIC IRQs off the busy node. Latency dropped back to normal, and the “application regression” vanished like it had never existed.

The lesson: On NUMA, “enough RAM” is not the same as “fast RAM.” Treat locality as a first-class metric.

Mini-story #2: The optimization that backfired

Another company ran a virtualization cluster with a mix of web and batch workloads. They discovered that disabling certain power management
features made benchmark numbers prettier. The team rolled the change across the fleet: performance mode everywhere, all the time.

Initially, the graphs looked great. Lower latency. Higher throughput. Victory laps were taken. Then summer arrived, along with a sequence
of thermal throttling events and fan failures. The datacenter cooling budget wasn’t infinite, and the racks were already dense.

Under sustained heat, some nodes started downclocking unpredictably. That unpredictability mattered more than the average performance gain.
The virtualization scheduler chased load around, VMs migrated at inopportune times, and the cluster developed a new personality: occasionally
fast, frequently cranky.

They rolled back to a balanced policy, used per-host performance settings only for specific latency tiers, and added thermal monitoring alerts
tied to actual throttling signals rather than “ambient temperature looks high.”

The lesson: an optimization that ignores power and thermals is just technical debt with a fan curve.

Mini-story #3: The boring but correct practice that saved the day

A financial services team ran Opteron servers for years. Nothing glamorous. Mostly databases and message queues. Their secret weapon was
not an exotic kernel patch or a heroic tuning session. It was disciplined baselining.

Every quarter, they captured a “known-good” snapshot of hardware and OS telemetry: NUMA layout, IRQ distribution, memory bandwidth under
a standard test, storage latency under a controlled load, and a performance profile of the top services. They stored it with the same
seriousness as backups.

One day, a firmware update quietly changed memory interleaving behavior. The system still booted. No alarms. But their baseline comparison
caught a significant increase in remote memory accesses and a measurable drop in memory bandwidth. Before users noticed, they paused rollout,
filed a vendor case, and pinned the firmware version for that hardware generation.

The fix was straightforward: adjust firmware settings to match the old behavior and validate with the same baseline tests. No incident.
No war room. Just a boring ticket and a clean change log.

The lesson: boring practices beat exciting heroics. Baselines turn “mystery regressions” into “known deltas.”

Fast diagnosis playbook: find the bottleneck quickly

This is the order I use when a server “feels slow” and the blame is being passed around like a hot potato. It’s tuned for Opteron-era
realities (NUMA, memory controllers per socket, multi-socket scaling), but it still applies to modern systems.

First: confirm what kind of slow you have

• Latency spike? Look for scheduling delays, remote memory, lock contention, IRQ storms.
• Throughput drop? Look for memory bandwidth saturation, I/O queue depth, throttling, or a single hot core.
• Only under concurrency? Suspect NUMA placement, cache-line bouncing, or shared resource contention.

Second: CPU vs memory vs I/O in 10 minutes

1. CPU scheduling pressure: run vmstat 1 and check run queue, context switches, and steal time.
2. Memory locality: check NUMA stats with numastat and CPU/node layout with lscpu.
3. I/O wait and latency: run iostat -x 1 and look at await, svctm (if present), and utilization.
4. Network: check drops and overruns with ip -s link and interrupt distribution.

Third: validate the “obvious” graph with a ground-truth tool

• Perf counters: perf stat and perf top for CPI, cache misses, and hot functions.
• Kernel view: pidstat, sar, dmesg for throttling and driver complaints.
• Placement: taskset, numactl, /proc/interrupts to see if you accidentally created a cross-socket tax.

Practical tasks: commands, output meaning, and the decision you make

These are the checks I actually run. Each task includes: a runnable command, an example output, what it means, and what decision follows.
Assume Linux on bare metal or a VM with enough visibility.

Task 1: Identify CPU model and core topology

cr0x@server:~$ lscpu
Architecture:        x86_64
CPU(s):              16
Thread(s) per core:  1
Core(s) per socket:  8
Socket(s):           2
NUMA node(s):        2
Vendor ID:           AuthenticAMD
Model name:          AMD Opteron(tm) Processor 285
NUMA node0 CPU(s):   0-7
NUMA node1 CPU(s):   8-15

Meaning: Two sockets, two NUMA nodes. Any “random” scheduling can create remote memory access.

Decision: For latency-sensitive services, plan CPU pinning or NUMA-aware deployment (one instance per socket, if feasible).

Task 2: Confirm NUMA distances (how expensive “remote” really is)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 16384 MB
node 0 free: 12210 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 16384 MB
node 1 free: 12044 MB
node distances:
node   0   1
  0   10  20
  1   20  10

Meaning: Remote node access costs ~2x relative distance. That’s not subtle.

Decision: If you see high remote traffic later, treat it as a first-class incident cause, not “noise.”

Task 3: Check if the kernel is using NUMA balancing (and whether you should care)

cr0x@server:~$ sysctl kernel.numa_balancing
kernel.numa_balancing = 1

Meaning: Automatic NUMA balancing is enabled. It can help, or it can create page migration churn.

Decision: For steady-state database workloads, test with it on/off in staging. If you see migrations and jitter, consider disabling and pinning.

Task 4: Spot run-queue pressure and swap activity fast

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 122100  81200 945000    0    0     1     5  310  540 18  4 76  2  0
 8  0      0 121880  81200 945120    0    0     0     0  900 1800 55 10 33  2  0
 9  0      0 121700  81200 945200    0    0     0    16  920 1900 58 12 28  2  0
 3  1      0 121500  81200 945210    0    0   120     0  600 1200 20  6 68  6  0
 2  0      0 121480  81200 945240    0    0     0     0  330  560 16  4 78  2  0

Meaning: The r column spiking (8–9) indicates runnable tasks exceeding CPU capacity. wa is low, swap is zero.

Decision: This is CPU scheduling pressure, not disk. Investigate hot threads, affinity, or lock contention.

Task 5: Identify whether you’re CPU-bound or memory-bound (quick and dirty)

cr0x@server:~$ perf stat -a -- sleep 5
 Performance counter stats for 'system wide':

       18,245.12 msec task-clock                #    3.649 CPUs utilized
   12,345,678,901      cycles                    #    0.677 GHz
    9,876,543,210      instructions              #    0.80  insn per cycle
    1,234,567,890      cache-references
      456,789,012      cache-misses              #   36.99% of all cache refs

       5.001234567 seconds time elapsed

Meaning: IPC around 0.8 and high cache miss rate suggests stalls—often memory latency/bandwidth, not pure compute.

Decision: Check NUMA locality and memory bandwidth pressure before buying “more CPU.”

Task 6: Check remote vs local memory allocations per process (NUMA reality check)

cr0x@server:~$ numastat -p 1234
Per-node process memory usage (in MBs) for PID 1234 (postgres)
         Node 0  Node 1   Total
Private    8200     900    9100
Heap        600    4200    4800
Stack        20      18      38
Huge         0       0       0
Total     8820    5118   13938

Meaning: Memory is spread unevenly; if the CPU threads are mostly on node 0 but heap is heavy on node 1, expect remote penalties.

Decision: Pin the process or use numactl policies; consider running one instance per socket for predictable locality.

Task 7: Inspect CPU affinity of a process (are you letting the scheduler freeload?)

cr0x@server:~$ taskset -pc 1234
pid 1234's current affinity list: 0-15

Meaning: The process can run anywhere, increasing the chance of cross-node bouncing.

Decision: For tail-latency services, restrict to a NUMA node (e.g., CPUs 0–7) and keep memory local.

Task 8: Check storage device latency and queue behavior

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              45.0    12.0   820.0   140.0   4.20   0.90  52.0
md0               0.0     0.0     0.0     0.0   0.00   0.00   0.0
nvme0n1         500.0   300.0 64000.0 32000.0   0.45   0.10  78.0

Meaning: await is the latency seen by requests. High %util with rising await points to saturation.

Decision: If await climbs under load, reduce random I/O, increase cache, or move hot data—don’t blame CPU.

Task 9: Verify filesystem-level latency symptoms (are you blocked on writes?)

cr0x@server:~$ pidstat -d 1 3 -p 1234
Linux 5.15.0 (server)  01/09/2026  _x86_64_  (16 CPU)

12:00:01 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
12:00:02 PM  1001      1234      0.00   4200.00      0.00      18  postgres
12:00:03 PM  1001      1234      0.00   3900.00      0.00      22  postgres
12:00:04 PM  1001      1234      0.00   4100.00      0.00      20  postgres

Meaning: iodelay rising indicates time blocked on I/O (kernel accounting). It’s a smoking gun when CPU looks idle.

Decision: Investigate write amplification, fsync frequency, RAID cache, or storage backend saturation.

Task 10: Check network drops and errors (because “CPU is fine” can still be network)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0     842       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0       9       0       0

Meaning: RX drops (842) are not “cosmetic.” They can trigger retransmits and latency spikes.

Decision: Check ring buffers, IRQ affinity, and congestion; consider enabling RSS tuning appropriate to the NIC.

Task 11: Inspect interrupt distribution (classic multi-socket failure mode)

cr0x@server:~$ cat /proc/interrupts | head -n 12
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  24:   9876543          0          0          0          0          0          0          0  IO-APIC   24-fasteoi   eth0
  25:      1200       1100       1150       1080       1120       1090       1110       1070  IO-APIC   25-fasteoi   nvme0q0
NMI:        120        118        121        119        117        120        122        118  Non-maskable interrupts

Meaning: eth0 interrupts pinned to CPU0 only. That can bottleneck networking and steal cycles from the wrong place.

Decision: Rebalance IRQs (irqbalance or manual smp_affinity) and keep NIC interrupts on the same NUMA node as the workload.

Task 12: Detect CPU frequency throttling / thermal issues

cr0x@server:~$ dmesg -T | egrep -i "thrott|thermal|clock"
[Thu Jan  9 11:58:12 2026] CPU0: Core temperature above threshold, cpu clock throttled
[Thu Jan  9 11:58:15 2026] CPU0: Core temperature/speed normal

Meaning: The CPU is self-protecting. Your “random latency spikes” might be physics, not software.

Decision: Fix airflow, fan curves, heatsinks, or power policy; don’t tune the app to compensate for a hot box.

Task 13: Confirm huge pages usage (good servant, bad master)

cr0x@server:~$ grep -i huge /proc/meminfo
AnonHugePages:    1048576 kB
HugePages_Total:     2048
HugePages_Free:       512
HugePages_Rsvd:       128
Hugepagesize:       2048 kB

Meaning: Huge pages are in play. That can improve TLB behavior but complicate memory allocation and NUMA placement.

Decision: If allocation failures or uneven node usage appear, adjust huge page reservation per NUMA node or revert for that workload.

Task 14: Check memory bandwidth pressure (practical proxy)

cr0x@server:~$ sar -B 1 3
Linux 5.15.0 (server)  01/09/2026  _x86_64_  (16 CPU)

12:01:01 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
12:01:02 PM      0.00    850.00  22000.00      0.00  48000.00      0.00      0.00      0.00      0.00
12:01:03 PM      0.00    920.00  24000.00      0.00  49000.00      0.00      0.00      0.00      0.00
12:01:04 PM      0.00    870.00  23000.00      0.00  47500.00      0.00      0.00      0.00      0.00

Meaning: Lots of page faults (minor) with no major faults suggests memory churn but not necessarily disk paging. It can correlate with memory bandwidth stress.

Decision: If latency correlates with spikes here, profile allocations, reduce churn, and validate NUMA locality—especially for JVMs and DB caches.

Second joke, because we all need one: NUMA is like office seating—put the team near the whiteboard, or enjoy long meetings about “communication latency.”

Common mistakes: symptoms → root cause → fix

1) Symptom: CPU is “not high,” but latency is awful

Root cause: Memory stalls (remote NUMA access, cache misses) or lock contention; CPU utilization lies by omission.

Fix: Use perf stat for IPC/misses, numastat for locality, then pin threads and enforce NUMA memory policies.

2) Symptom: Adding a second socket didn’t improve throughput

Root cause: Workload is single-threaded, serialized on a lock, or bottlenecked on one NUMA node’s memory bandwidth.

Fix: Profile hotspots; split into multiple independent processes pinned per socket; ensure memory allocations are local per instance.

3) Symptom: Network throughput caps below link speed and drops appear

Root cause: IRQs pinned to one core, poor RSS configuration, or driver defaults unsuitable for high PPS workloads.

Fix: Distribute IRQs across cores on the correct NUMA node; validate with /proc/interrupts and drop counters.

4) Symptom: Storage latency spikes during “CPU-heavy” jobs

Root cause: I/O completion interrupts and ksoftirqd contention; the storage path competes with compute on the same cores.

Fix: Separate IRQ cores; isolate CPUs for latency tiers; confirm with pidstat -d and iostat -x.

5) Symptom: Random slowdowns after firmware/BIOS changes

Root cause: Memory interleaving, C-states, or power policy changed; NUMA behavior shifted subtly.

Fix: Compare baselines (NUMA distances, memory bandwidth tests, perf counters). Roll back or standardize settings fleet-wide.

6) Symptom: Virtualization host is jittery, VMs migrate “too much”

Root cause: Overcommit + NUMA-unaware placement; VMs span nodes and incur remote memory penalties.

Fix: Keep VM vCPUs and memory within a node when possible; use per-NUMA-node pools; validate with host and guest metrics.

Checklists / step-by-step plan

Checklist A: When buying or inheriting Opteron-era servers (or any NUMA box)

1. Confirm sockets/NUMA nodes with lscpu and numactl --hardware.
2. Standardize BIOS settings: memory interleaving policy, power policy, virtualization settings, and any node interconnect options.
3. Establish a baseline: perf stat on idle and under a controlled load, plus iostat -x and ip -s link.
4. Document IRQ distribution on a known-good host (/proc/interrupts snapshot).
5. Pick a NUMA strategy per workload: “pin per socket,” “interleave memory,” or “let balancing do it” (only after testing).

Checklist B: When a service gets slow after migration to new hardware

1. Confirm clocks/throttling with dmesg and CPU frequency tools (if available).
2. Check run queue and I/O wait: vmstat 1, then iostat -x 1.
3. Validate NUMA locality: numastat -p for the process and CPU affinity with taskset -pc.
4. Check IRQ hotspots: cat /proc/interrupts, then correlate with network/storage drops.
5. Only then tune the application—because hardware misplacement can mimic software regressions perfectly.

Checklist C: A sane tuning plan (don’t tune yourself into a corner)

1. Measure: capture 10 minutes of vmstat, iostat, and perf stat around the issue.
2. Make one change at a time (pinning, IRQ affinity, memory policy), and re-measure.
3. Prefer reversible changes (systemd unit overrides, service wrappers) over “mystery sysctl soup.”
4. Write down the rationale. Future-you is a different person with less patience.

FAQ

1) Was Opteron’s main advantage just “64-bit”?

No. 64-bit mattered, but Opteron’s system-level design—integrated memory controller and better multi-socket interconnect—delivered tangible
performance and predictability for real workloads.

2) Why did integrated memory controllers change server performance so much?

They reduced memory latency and removed a shared bottleneck (northbridge/FSB). For databases, middleware, and virtualization hosts,
memory behavior often dominates perceived performance.

3) What’s the single most common Opteron-era ops failure mode?

NUMA ignorance: workloads running on one socket while memory is allocated on another, producing remote access penalties and jitter that look
like “random slowness.”

4) Should I always pin processes to a NUMA node?

Not always. Pinning can help latency-sensitive, stable workloads. It can hurt bursty or highly mixed workloads if you accidentally constrain
them. Test with production-like load and watch tail latency, not just averages.

5) How do I know if I’m memory-bound without fancy tooling?

Look for low IPC in perf stat, high cache miss rates, and symptoms where CPU utilization isn’t high but throughput won’t increase.
Then validate NUMA locality with numastat.

6) Why did AMD64 beat Itanium in the market?

Compatibility. AMD64 let enterprises move to 64-bit without rewriting everything. Itanium required ports and introduced ecosystem friction.
In enterprise, friction is a cost center.

7) Does any of this matter on modern CPUs?

Yes. Modern platforms still have NUMA, multiple memory channels, complex interconnects, and IRQ/CPU locality issues. The labels changed.
The physics did not.

8) What’s the fastest “is it CPU or I/O?” check?

vmstat 1 plus iostat -x 1. If wa and await rise, suspect storage. If run queue spikes and wa is low,
suspect CPU scheduling, locks, or memory stalls.

9) Can virtualization hide NUMA problems?

It can hide the cause while amplifying the symptoms. If a VM spans nodes, remote memory access becomes “mysterious jitter.” Prefer NUMA-aligned
VM sizing and placement.

Conclusion: next steps you can actually do

Opteron opened the VIP door for AMD by solving the problems operators were already paid to care about: scaling, memory behavior, compatibility,
and predictable performance under load. The lesson isn’t nostalgia. The lesson is architectural literacy: if you don’t understand where the
bottleneck lives, you will confidently optimize the wrong thing.

Next steps:

1. On one production-like host, capture a baseline: lscpu, numactl --hardware, vmstat, iostat -x, ip -s link, /proc/interrupts.
2. Pick one critical service and validate NUMA locality with numastat -p plus CPU affinity with taskset.
3. Fix the biggest mismatch first (usually IRQ distribution or memory locality), then re-measure. If the graphs don’t move, you didn’t fix the bottleneck.
4. Write down what “good” looks like for that hardware generation. The day you need it will be the day you don’t have time to recreate it.