技术帮助 · 发布时间：
数据库进程在一个 NUMA 节点上运行，却频繁从另一个节点取内存，可能增加访问延迟；绑定得过严，又可能让单个节点先耗尽内存。裸金属服务器运行数据库时的NUMA与内存绑定设置，应先以实际拓扑和负载为依据，再决定是否限制进程的内存分配范围。
先确认拓扑，不要把插槽号当作节点号
NUMA 节点是处理器与本地内存的组织单元，节点编号不一定与 CPU 插槽编号一一对应。可在 Linux 上执行 numactl --hardware 查看节点、CPU 列表和各节点可用内存，再用 lscpu 核对 Socket、NUMA node 和 CPU 分布。BIOS 设置、处理器型号及虚拟化配置都可能影响呈现结果。
同时记录数据库进程的 CPU 使用情况、内存占用、峰值并发和缓存配置。PostgreSQL 的 shared_buffers、MySQL 的 InnoDB buffer pool 等主要内存区域会影响节点压力，但不能仅凭数据库配置值推断全部内存需求：连接、后台任务、操作系统缓存和其他服务也会占用内存。
理解绑定策略的取舍
绑定与优先分配
内存绑定把进程的内存分配限制在指定 NUMA 节点；本地访问通常更可预测，但节点空间不足时，严格策略可能导致分配失败或性能波动。优先分配则先尝试指定节点，无法满足时允许使用其他节点，灵活性更高，不过仍可能发生远端访问。
单节点与交错分配
数据库工作集适合集中在单节点且该节点有充足余量时，可评估单节点绑定。若工作集较大、跨节点并行访问明显，交错分配（interleave）可把内存分散到多个节点，增加可用带宽的机会，但不保证每次访问都是本地内存。两者没有通用赢家，应按延迟、吞吐和内存压力测试。
按步骤实施并保留回退路径
- 建立基线。记录正常与高峰时的查询延迟、吞吐、CPU、内存余量和数据库日志。先确认服务是否已受 systemd 的 CPU 或内存控制组限制，避免叠加规则造成误判。
- 小范围试配。选择维护窗口或可回退的实例，先验证单个节点是否容纳数据库及系统所需内存。numactl 可用于启动进程时指定策略，例如 numactl --cpunodebind=0 --membind=0 将 CPU 和内存分别限制在节点 0；节点编号必须按本机查询结果替换。生产服务不要未经容量评估直接照搬。
- 持久化配置。若采用 systemd 管理服务，可在对应服务覆盖配置中评估 NUMAPolicy 与 NUMAMask；具体可用策略及语法取决于 systemd 和内核版本。修改后检查配置并按维护流程重启服务。新策略通常不会自动把已驻留的全部内存页面搬到目标节点。
- 验证实际效果。用 numastat -p 查看进程在各节点的内存分布，并结合 /proc/<PID>/numa_maps 检查映射情况；持续观察节点剩余内存、换页、数据库延迟与错误日志。负载稳定后再逐步扩大应用范围。
- 明确回滚条件。出现节点余量持续过低、分配失败、延迟恶化或服务异常时，撤销绑定并恢复原启动方式，再复测。大页内存、容器限制及多个数据库实例并存时，还要单独核对节点级容量。
常见问题
只绑定内存、不绑定 CPU 可以吗？
可以，但线程可能在其他节点的 CPU 上运行，增加远端访问。应根据数据库线程调度和压测结果决定是否同时设置 CPU 亲和性，而非默认全绑。
所有数据库都适合绑在一个节点吗？
不适合。单节点容量不足或负载能利用多节点带宽时，集中绑定可能形成瓶颈，可比较优先分配或交错策略。
改完配置后是否必须重启？
启动时策略最容易验证；已有进程的策略调整及页面迁移受内核和工具支持影响。生产环境通常应安排重启窗口，并在重启后重新检查分布。
归根结底，裸金属服务器运行数据库时的NUMA与内存绑定设置不是固定模板：先识别节点，再按容量选择策略，最后用真实负载验证。若无法证明绑定带来稳定收益，保留系统默认策略往往比盲目收紧范围更稳妥。
