CentOS服务器上应用突然崩溃，日志里赫然写着“Cannot allocate memory”（无法分配内存），或者系统变得异常缓慢，终端命令都无法响应。这通常是服务器在告诉你：内存资源已经耗尽，无法满足新的需求。别慌，内存分配失败虽然棘手，但通过系统性的方法，你完全可以找到根源并解决问题。

首先，我们要理解Linux（包括CentOS）内存管理的核心机制。当应用程序申请内存时，系统首先会从物理内存的空闲部分分配。如果物理内存不足，内核会尝试使用“交换空间”，将物理内存中不活跃的页面移到硬盘上的交换分区或交换文件，腾出空间。当物理内存和交换空间都几乎耗尽时，新的内存申请就会失败。此外，即使看似有可用内存，也可能因为内存碎片（尤其是连续内存需求）或内核参数的限制（如单个进程的内存上限、用户的内存限制）而导致特定申请失败。另一个关键角色是 “Out of Memory Killer” ，当系统内存严重枯竭、濒临僵死时，内核会主动选择并终止一个或多个进程（通常是消耗内存最多且“可牺牲”的），以释放内存，维持系统基本运行。你看到的进程突然消失，很可能就是它的“功劳”。

当问题发生时，第一步不是重启服务器，而是冷静地收集信息。如果你的终端还能响应，一套组合命令能快速勾勒出内存全景。首先，使用 `free -h` 命令查看内存和交换空间的整体使用情况。重点关注 `available` 列（CentOS 7及以后），它比 `free` 列更能反映系统可立即分配给新应用的内存。如果 `available` 和 `swap free` 都极低（例如只剩几十MB），说明系统已处于耗尽状态。接着，用 `top` 或更直观的 `htop`（需安装）命令，按内存占用排序（在`top`中按`Shift+M`），一眼就能看出是哪个或哪几个进程是“内存大户”。`top`输出的 `%MEM` 列显示了进程占用物理内存的百分比，`VIRT` 是虚拟内存大小（包含申请但未实际使用的部分），`RES` 是实际驻留物理内存的大小。通常，盯住 `%MEM` 和 `RES` 最高的进程。

但内存泄漏往往更隐蔽，一个进程可能开始时占用不多，但缓慢增长最终拖垮系统。此时，你需要追踪变化。你可以连续运行 `vmstat 2 5`，这表示每2秒采样一次，共5次。观察 `si` （Swap In，从磁盘交换到内存）和 `so` （Swap Out，从内存交换到磁盘）两列。如果它们持续有较高的非零值，说明内存已不足，系统在频繁使用交换，这会导致性能急剧下降（磁盘比内存慢几个数量级）。另一个强大的工具是 `sar`（`sysstat` 包的一部分），它可以提供历史内存压力数据，用 `sar -r` 查看。

如果上述常规检查未能定位，或者失败发生在特定操作或用户下，就需要更深入的排查。检查内核参数限制：使用 `ulimit -a` 查看当前用户的限制，其中 `max memory size`（`kbytes`）可能设置了单个进程或用户可用的内存上限。这个限制可能在 `/etc/security/limits.conf` 或 `/etc/systemd/system.conf`（对于systemd服务）中配置。分析内核日志：OOM Killer在动手前会留下“遗言”。立刻使用 `dmesg | tail -50` 或直接查看 `/var/log/messages` 日志，搜索 “`Out of memory`”, “`Killed process`” 等关键词。你会看到类似 “`Out of memory: Kill process 12345 (java) score XXX`” 的记录，这明确指出了“凶手”和“受害者”。

内存碎片化也是一个潜在原因，尤其是对于需要大块连续物理内存的应用（如某些数据库或科学计算软件）。这可以通过查看 `/proc/buddyinfo` 文件来诊断。这个文件展示了不同阶（order，即连续页面块的大小）的可用内存块数量。如果大阶（如order 3以上）的块数量极少，就表明存在严重的外部碎片。

在锁定了问题根源后，解决方案就具有针对性了。如果是某个特定进程异常占用，短期最直接的解决方法是终止或重启该进程（`kill PID` 或 `systemctl restart service_name`）。但务必先根据日志和业务判断它是否核心业务进程。如果是应用存在内存泄漏，则需要联系开发者，优化代码，或为应用设置重启策略。对于配置限制导致的问题，如果是 `ulimit` 限制过低，可以临时用 `ulimit -m unlimited` 或 `ulimit -v unlimited` 解除（仅对当前会话有效），永久修改则需要编辑 `/etc/security/limits.conf` 文件，为相应用户或组增加 `soft memlock` 和 `hard memlock` 限制。例如：

@developers soft memlock unlimited

@developers hard memlock unlimited

修改 `limits.conf` 后，新登录的会话会生效。对于已经运行的服务，可能需要重启服务或服务器。

更常见的情况是服务器整体内存容量不足。这时，长期解决方案是增加物理内存。但在硬件升级前，可以优化现有资源：1）适当增加交换空间。如果交换空间本身已满，可以创建一个新的交换文件：

sudo fallocate -l 2G /swapfile_ext

sudo chmod 600 /swapfile_ext

sudo mkswap /swapfile_ext

sudo swapon /swapfile_ext

若要永久生效，需将 `/swapfile_ext swap swap defaults 0 0` 添加到 `/etc/fstab`。2）调整内核的交换倾向。通过修改 `/proc/sys/vm/swappiness` 值（默认60，范围0-100），可以影响内核使用交换空间的积极程度。对于数据库等期望尽量少用交换的应用，可以临时设置为较低值（如10）：`sysctl vm.swappiness=10`。永久修改需在 `/etc/sysctl.conf` 中添加 `vm.swappiness=10`。3）清理页面缓存。在测试或紧急情况下，如果确定缓存数据不重要，可以释放页缓存和目录项缓存：`sync && echo 3 > /proc/sys/vm/drop_caches`。注意：这是临时的急救措施，内核会立刻重新开始缓存，主要用于测试内存不足是否由缓存占满引起。

最后，建立监控和预防体系至关重要。使用 `cron` 任务定期运行监控脚本，记录 `free`、`top` 输出，或配置Zabbix、Prometheus等专业监控工具，设置内存使用率超过90%的告警。对于关键应用，在其systemd服务单元文件（`.service`）中，可以使用 `MemoryMax`、`MemoryHigh` 等指令来限制其内存使用，防止单个服务拖垮整个系统。

面对CentOS内存分配失败，从紧急的进程终止，到中期的参数调整、交换空间扩展，再到长期的容量规划和应用优化，是一套由表及里的组合拳。理解内存耗尽背后的不同层次原因，并熟练运用系统工具进行诊断，你就能在下次“内存危机”来临时，从容应对，保障服务的稳定运行。