直接用numactl --membind启动数据库大概率无效；真正起效的关键是让线程、内存、网卡、存储同属一个numa节点，须先用numactl --hardware确认拓扑，再配对使用--cpunodebind与--membind，预分配大页，并用numastat和taskset验证生效。
直接用 numactl --membind 启动数据库，大概率没效果，甚至引发 OOM 或延迟飙升。真正起效的关键不是“绑内存”，而是让数据库的线程、内存、网卡、存储设备尽可能落在同一个 NUMA 节点上。
第一步：确认 NUMA 是否真实启用并看清拓扑
别跳过这步——90% 的绑定失败源于这里。
- 运行
numactl --hardware，输出必须含available: N nodes (N>1)；若只显示1 nodes或No NUMA configuration found，说明 BIOS 关了 NUMA 模式，或内核启动参数缺numa=on - 执行
lscpu | grep -i "numa node"，确认节点数与numactl --hardware一致 - 查关键外设归属：
cat /sys/class/net/eth0/device/numa_node（网卡）、lspci -vv | grep -A 5 -B 5 "NUMA node"（NVMe/RAID卡），避免网络收包或磁盘 I/O 触发跨节点访存
第二步：绑定 CPU 与内存必须配对，且同节点
--cpunodebind 和 --membind 是一对“搭档”，单独用任一个都等于白忙活。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 错误示例：
numactl --membind=0 ./postgres→ 进程可能在 Node 1 的 CPU 上跑，却从 Node 0 malloc 内存，跨节点访问立即发生 - 正确写法：
numactl --cpunodebind=0 --membind=0 --physcpubind=0-15 ./postgres（假设 Node 0 含物理核 0–15） - 若数据库多进程（如 PostgreSQL 的 backend worker），父进程绑定后，子进程不继承策略，需在代码中调用
numa_set_localalloc()，或启动子进程时再次用numactl
第三步：大页内存和预分配是硬前提
数据库普遍依赖大页（hugepage），但 --membind 对大页无效，除非目标节点已预留。
- 先查当前节点大页容量：
cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages - 在 Node 0 预留 1024 个 2MB 大页：
echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages（注意：不能只写/proc/sys/vm/nr_hugepages） - PostgreSQL 需开启
huge_pages = on并设置shared_buffers大于单个大页；MySQL 8.0+ 需配置large_pages = ON
第四步：验证是否真生效，别信启动命令
启动成功 ≠ 绑定成功。必须用运行时指标交叉验证。
- 获取数据库主进程 PID：
pgrep -f "postgres -D" | head -1（PostgreSQL）或pgrep mysqld - 查内存实际分布：
numastat -p $PID，重点看 Heap 列：Node 0 数值应远高于其他节点（比如 Node 0 占 95%+，Node 1 接近 0） - 查跨节点访问比例：
numastat -c $PID，计算numa_foreign / (numa_hit + numa_foreign)，超过 5% 就要重新检查绑定逻辑 - 同步验证 CPU 亲和性：
taskset -p $PID输出的 hex mask，应与numactl --hardware中 Node 0 的 CPU 列表完全匹配
