MongoDB在启动阶段抛出故障码1090，通常伴随着一段明确的警告信息，提示用户当前系统运行在NUMA（Non-Uniform Memory Access）架构下，而MongoDB的内存管理机制与这种架构存在天然冲突。如果不通过numactl进行正确的内存交错分配干预，数据库的性能将会受到严重影响，甚至导致进程直接拒绝启动。这种问题在多物理CPU插槽的服务器环境中极为常见，因为这类硬件普遍采用了NUMA设计来优化多处理器的内存访问延迟。
故障码1090的底层成因与NUMA架构原理
要理解这个故障，首先需要弄清楚NUMA架构是什么。在传统的对称多处理（SMP）架构中，所有CPU共享同一个集中式内存池，访问任何内存地址的延迟都是相同的。但随着CPU核心数增加，这种架构遇到了总线带宽瓶颈。NUMA架构应运而生，它将系统划分为多个节点，每个节点包含一部分CPU和专属的本地内存。当CPU访问自己节点的本地内存时速度极快，但如果需要访问其他节点的远端内存，就必须经过互联总线，导致延迟显著增加。
MongoDB的存储引擎WiredTiger在内存分配上采用了假设内存访问延迟均匀的策略。它会在启动时向操作系统申请大块连续的内存用于缓存。如果此时操作系统默认的NUMA策略是将内存优先分配在当前运行CPU的本地节点上，那么当MongoDB进程在多个CPU核心间切换时，就会频繁触发跨节点内存访问，导致性能断崖式下跌。为了防止这种灾难性的性能损耗，MongoDB在检测到系统处于NUMA模式且未进行numactl配置优化时，会主动抛出1090错误并中止启动，这是一种自我保护机制。
使用numactl命令行直接启动MongoDB实例
解决这个故障最直接的方法是使用numactl命令包装MongoDB的启动指令。numactl是一个Linux系统工具，可以控制进程的内存分配策略。通过指定interleave=all参数，我们强制操作系统将MongoDB申请的内存均匀地交错分布到所有的NUMA节点上，从而抹平跨节点访问的延迟差异，让MongoDB回到它喜欢的均匀内存访问模式上。
在实际操作中，我们需要先确认系统中是否安装了numactl工具包。通常可以通过包管理器进行安装。安装完成后，修改MongoDB的启动脚本或直接在终端执行命令。下面是一个典型的启动命令示例，它将mongod进程的内存分配策略设置为交错模式。
# 检查numactl是否安装 which numactl # 如果未安装，在基于RedHat的系统上执行 yum install -y numactl # 在基于Debian的系统上执行 apt-get install -y numactl # 使用numactl以交错模式启动mongod numactl --interleave=all /usr/bin/mongod -f /etc/mongod.conf
虽然这种方式能够立即解决1090错误，但它存在一个明显的缺点：如果服务器重启或者MongoDB进程意外退出，再次启动时必须手动加上numactl前缀。对于生产环境来说，这种依赖手动操作的方式不够健壮，容易因为运维人员的疏忽而导致服务启动失败。因此，我们需要更持久化的管理方案。
结合Systemd服务实现持久化NUMA配置
现代Linux发行版普遍采用systemd作为系统和服务管理器。如果MongoDB是通过rpm或deb包安装的，系统通常会自动生成一个systemd服务文件。为了确保每次启动都自动应用numactl策略，我们需要修改这个服务文件，将numactl命令集成到服务的启动指令中。这样无论服务器重启还是服务自动拉起，都能保证正确的内存分配策略。
首先需要找到MongoDB的systemd服务文件，通常位于/etc/systemd/system/目录或/lib/systemd/system/目录下。找到文件后，我们需要编辑其中的ExecStart指令。注意，在修改系统服务文件前，建议先备份原始文件。
# 备份原始服务文件 cp /usr/lib/systemd/system/mongod.service /usr/lib/systemd/system/mongod.service.bak # 编辑服务文件 vi /usr/lib/systemd/system/mongod.service # 找到 ExecStart 行，将其修改为如下形式 # ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod -f /etc/mongod.conf # 重新加载systemd配置 systemctl daemon-reload # 重启MongoDB服务 systemctl restart mongod # 检查服务状态 systemctl status mongod
修改完成后，务必执行daemon-reload命令让systemd重新读取配置文件。然后重启mongod服务，此时查看系统日志，应该不会再出现1090错误。这种方案是生产环境中最推荐的做法，因为它将底层系统配置与上层服务管理解耦，运维人员只需维护systemd的配置，无需关心底层的命令细节，大大降低了运维风险。
彻底关闭系统NUMA机制的权衡与操作
除了使用numactl进行内存交错分配外，另一种思路是直接在操作系统层面关闭NUMA机制。这种方法通常通过修改系统的GRUB引导参数来实现。通过在内核启动参数中添加numa=off，可以强制操作系统将所有内存视为统一的SMP内存池，从根本上消除NUMA架构的影响。
修改GRUB配置需要谨慎操作，因为配置错误可能导致系统无法启动。我们需要编辑/etc/default/grub文件，在GRUB_CMDLINE_LINUX参数的值中追加numa=off。修改完成后，需要重新生成GRUB配置文件并重启系统。
# 编辑GRUB配置文件 vi /etc/default/grub # 在 GRUB_CMDLINE_LINUX 行添加 numa=off，例如： # GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rhgb quiet numa=off" # 重新生成GRUB配置（CentOS/RedHat） grub2-mkconfig -o /boot/grub2/grub.cfg # 重新生成GRUB配置（Ubuntu/Debian） update-grub # 重启系统使参数生效 reboot
虽然关闭NUMA可以一劳永逸地解决MongoDB的1090报错，但这种方法并不总是最优解。如果服务器上还运行着其他对NUMA架构有良好支持且依赖本地内存访问性能的应用（例如某些特定的高性能计算任务），全局关闭NUMA会导致这些应用性能下降。因此，在多用途服务器上，推荐使用前两种基于numactl的局部干预方案；而在专门为MongoDB准备的独立物理机上，关闭系统NUMA则是一个简单有效的选择。