一、紧急救援：如何进入系统并释放内存

当CentOS服务器因内存耗尽无法通过SSH登录时，通常表现为以下现象：

• SSH连接长时间无响应或直接断开
• 控制台输出”Out of memory”错误
• 系统进入不可操作状态（键盘无响应）

1.1 通过救援模式进入系统

步骤1：物理服务器操作

• 联系机房管理员获取KVM或iLO/iDRAC远程控制权限
• 在启动时按F12（或Del键）进入BIOS，选择从Live CD/USB启动
• 推荐使用CentOS官方Live镜像或SystemRescueCD

步骤2：虚拟机环境操作

# 对于KVM虚拟机
virsh console <domain_name>  # 先尝试控制台连接
# 若无效，修改XML配置强制从ISO启动
virsh edit <domain_name>
# 在<os>段添加：
<boot dev='cdrom'/>

1.2 内存紧急释放方案

方案A：终止高内存进程

# 在救援模式下挂载原系统根分区
mkdir /mnt/root
mount /dev/sdXN /mnt/root  # XN为实际分区
chroot /mnt/root
# 查找内存占用TOP10进程
ps aux --sort=-%mem | head -10
# 安全终止进程（示例终止MySQL）
kill -9 $(pgrep mysqld)
# 或使用更安全的pkill
pkill -9 -f "mysqld"

方案B：清理缓存文件

# 清理临时文件（需先chroot）
rm -rf /tmp/*
rm -rf /var/tmp/*
# 清理日志文件（按时间排序删除旧日志）
find /var/log -type f -name "*.log" -mtime +30 -exec rm {} \;
# 清理包管理器缓存
yum clean all  # CentOS 7及之前
dnf clean all  # CentOS 8+

二、深度诊断：查明内存泄漏根源

2.1 系统级诊断工具

使用dmesg分析OOM事件

dmesg | grep -i "out of memory"
# 典型输出示例：
# [12345.678901] Out of memory: Killed process 1234 (mysqld)

分析内存使用历史

# 安装sysstat包（救援模式下需先挂载repo）
yum install sysstat -y
sar -r 1 10  # 查看最近10次内存采样

2.2 应用层诊断方法

Java应用诊断

# 查找Java进程并分析堆内存
jps -l
jmap -heap <pid>
jstat -gcutil <pid> 1000 5  # 每秒采样GC情况

数据库诊断（MySQL示例）

-- 在MySQL客户端执行
SHOW ENGINE INNODB STATUS\G
-- 查找"BUFFER POOL AND MEMORY"部分

三、长期解决方案：构建内存安全体系

3.1 内存监控告警系统

配置Prometheus+Node Exporter

# prometheus.yml配置示例
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
    metrics_path: /metrics
    params:
      format: ['prometheus']

设置Grafana告警规则

mem_available_percent = (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
# 当mem_available_percent < 10%时触发告警

3.2 资源限制策略

Cgroups配置示例

# 创建内存限制组
cgcreate -g memory:/limited_app
# 设置内存上限（1GB）
echo 1G > /sys/fs/cgroup/memory/limited_app/memory.limit_in_bytes
# 将应用进程加入cgroup
echo <pid> > /sys/fs/cgroup/memory/limited_app/tasks

系统级参数调优

# /etc/sysctl.conf 优化配置
vm.overcommit_memory = 2  # 严格内存分配检查
vm.panic_on_oom = 0       # OOM时不触发kernel panic
vm.swappiness = 10        # 更积极使用swap

3.3 应用架构优化

数据库优化方案

-- 优化大表查询
ALTER TABLE large_table ADD INDEX idx_query_col(query_col);
-- 配置慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;  # 记录超过2秒的查询

Java应用JVM调优

# 启动参数示例
JAVA_OPTS="-Xms512m -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

四、预防性维护计划

4.1 定期维护任务

Cron任务示例

# 每周清理日志
0 3 * * 1 find /var/log -type f -name "*.log" -mtime +7 -exec rm {} \;
# 每月更新系统
0 0 1 * * yum update -y && reboot

4.2 容量规划模型

内存需求计算公式

总内存需求 = 基础系统内存 
           + (应用实例数 × 单实例内存) 
           + (数据库缓存 × 1.2) 
           + 20%冗余

实例监控脚本

#!/bin/bash
# memory_monitor.sh
THRESHOLD=80
USED=$(free | awk '/Mem/{printf "%.0f", $3/$2*100}')
if [ $USED -gt $THRESHOLD ]; then
    echo "内存使用率 ${USED}% 超过阈值 ${THRESHOLD}%" | mail -s "内存告警" admin@example.com
fi

五、特殊场景处理

5.1 容器化环境处理

Docker内存限制

docker run -d --name mysql \
  --memory="1g" \
  --memory-swap="2g" \
  mysql:5.7

Kubernetes资源请求/限制

resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

5.2 云服务器特殊处理

AWS EC2内存增强实例

• 选择r6i系列（AMD EPYC处理器，更高内存带宽）
• 启用Enhanced Networking

阿里云ECS优化建议

• 使用SSD云盘替代普通云盘
• 开启内存型实例的智能内存管理

六、法律与合规注意事项

1. 数据保护：在清理内存前确保已备份关键数据
2. 服务协议：内存升级需符合云服务商的SLA条款
3. 审计追踪：记录所有内存释放操作的时间和执行人

七、典型案例分析

案例1：数据库查询导致内存耗尽

• 现象：每半小时出现OOM，伴随大量临时表创建
• 解决方案：优化SQL查询，增加tmp_table_size参数
• 效果：内存使用稳定在65%以下

案例2：Java应用内存泄漏

• 现象：每日凌晨内存使用线性增长
• 诊断：通过jmap发现大量未释放的HashMap对象
• 修复：修改代码添加对象清理逻辑

八、进阶工具推荐

1. 内存分析工具：

   • Valgrind（C/C++程序）
   • YourKit（Java应用）
   • pmap（系统级内存映射分析）

2. 自动化监控：

   • Zabbix内存模板
   • Telegraf的mem插件
   • Datadog内存监控集成

3. 压力测试工具：

   • stress-ng（系统级压力测试）
   • JMeter（应用层压力测试）
   • sysbench（数据库压力测试）

通过实施上述方案，可实现从紧急救援到长期预防的完整内存管理闭环。建议每季度进行内存使用复盘，结合业务发展动态调整资源配置策略。