Oracle在KVM上延迟高主因是vCPU与内存跨NUMA节点访问，须显式绑定：用numactl -H确认物理拓扑，XML中配置numatune（strict模式）、cputune（vcpupin+emulatorpin）和cpu/numa（cell定义），启动前预分配对应节点大页，并通过numastat、ps及V$OSSTAT验证运行时本地性。
Oracle数据库在KVM上跑得慢、延迟高，大概率不是SQL或存储问题，而是vCPU和内存跨NUMA节点访问导致的——必须显式绑定NUMA，否则默认调度会让Oracle进程在多个节点间跳来跳去。
确认宿主机NUMA拓扑是否清晰
Oracle对本地内存延迟极其敏感，第一步不是改XML，而是看清楚物理布局。别信lscpu里“NUMA node(s): 2”这种模糊输出，要精确到每个核和每块内存的归属：
- 运行
numactl -H，重点看node 0 cpus和node 0 size是否匹配（比如 node 0 有 16 个逻辑核，内存也接近一半） - 对比
lscpu | grep "NUMA node"和cat /sys/devices/system/node/node*/meminfo，确保没有“某个节点显示有CPU但内存为0”的异常 - 如果
numactl -H显示 only one node，但物理是双路CPU，说明 BIOS 中关闭了 NUMA 或者内核启动参数加了numa=off—— 这种情况必须先修复底层，否则所有绑定都无效
virsh edit 中必须设置的三个关键XML段
Oracle实例启动后会密集分配大页内存、绑定大量线程，只靠 vcpupin 不够，必须三处协同：
-
<numatune><memory mode="strict" nodeset="0"></memory></numatune>：强制所有Guest内存从 node 0 分配；用preferred模式会导致 fallback 到远端节点，Oracle会卡在ksfd: waiting for async I/O -
<cputune><vcpupin vcpu="0" cpuset="0-7"></vcpupin><vcpupin vcpu="1" cpuset="8-15"></vcpupin><emulatorpin cpuset="0-3"></emulatorpin></cputune>：vCPU按组绑定（避免单核争抢），QEMU emulator 进程单独钉在低编号核上，防止它自己跨节点调度干扰Oracle后台进程 -
<cpu mode="host-passthrough"><numa><cell id="0" cpus="0-7" memory="16384" unit="MiB"></cell></numa></cpu>：即使Oracle只用16G内存，也要在<cell></cell>里写明，让Guest OS看到一个“干净”的单NUMA节点视图，否则 Linux Guest 内核可能启用 vNUMA 导致 Oracle RAC 的 interconnect 异常
验证绑定是否真正生效
改完XML、重启虚拟机后，不能只看 virsh numatune <vm_name></vm_name> 返回的 nodeset，那只是配置项。要确认运行时行为：
- 进Guest执行
numastat -p $(pgrep -f 'ora_pmon')，观察numa_hit是否占总访问的 95%+，numa_foreign接近 0；若后者持续增长，说明仍有线程被调度到远端节点 - 在Host上执行
ps -eLo pid,lwp,psr,args | grep qemu | grep -v grep，检查每个线程的psr（实际运行核）是否全落在你指定的cpuset范围内；注意：QEMU主线程和 I/O 线程可能分属不同psr，必须全部覆盖 - Oracle启动后查
ALTER SYSTEM SET "_enable_NUMA_optimization"=TRUE SCOPE=SPFILE;（仅19c+），再查V$OSSTAT中NUMA_POLICY字段是否为bind，这是Oracle自身感知到绑定的证据
最容易被忽略的是：Oracle的SGA大页分配发生在实例启动初期，如果此时 numatune 配置未生效或 hugepages 在宿主机未预分配在对应NUMA节点，绑定就形同虚设——务必在启动前用 numactl --membind=0 --cpunodebind=0 /bin/bash 测试大页申请是否成功。
