悠悠楠杉
网站页面
深度解析CentOS内存监控：从基础命令到性能优化实战
07/20
一、为什么需要关注内存使用？
在服务器运维过程中，内存就像系统的"工作台"——当这个工作台被占满时，新任务要么等待（导致延迟），要么被迫使用缓慢的磁盘交换空间（导致性能断崖式下降）。上周我们生产环境就遇到Java应用未配置JVM参数，导致OOM崩溃的案例，这正是掌握内存监控的现实意义。
二、基础命令三板斧
1. free命令：内存快照速查
bash
free -h
total used free shared buff/cache available
Mem: 62G 12G 3.2G 1.1G 46G 48G
Swap: 4.0G 512M 3.5G
重点解读：
- available字段（红帽系特有）比free更有参考价值，包含可快速回收的缓存
- 当available低于总内存10%时需要警惕
- -w参数可分离buffers和cache（CentOS 7+）
2. top命令：动态监控
在交互界面按M按内存排序进程，关键指标：
- %MEM：进程物理内存占比
- VIRT：虚拟内存总量（含共享库等）
- RES：实际使用的物理内存（常驻内存集）
3. vmstat：时序变化追踪
bash
vmstat 3 5 # 每3秒采样，共5次
procs -----------memory---------- ---swap--
r b swpd free buff cache si so
2 0 524288 325004 102400 4822224 0 0
警示信号：
- si/so持续大于0，说明开始使用交换分区
- buff/cache异常增长可能预示内存泄漏
三、进阶诊断工具链
4. /proc/meminfo：原始数据源头
bash
grep -E 'MemTotal|MemFree|Buffers|Cached|SwapCached' /proc/meminfo
这里能看到内核统计的精确数据，比如：
- Slab：内核对象缓存（可能吞噬内存的隐藏杀手）
- PageTables：内存映射开销（虚拟化环境需特别关注）
5. slabtop：内核内存分析
类似top的交互式工具，专注分析slab分配器：
bash
slabtop -s c # 按缓存大小排序
6. pmap：进程内存解剖
bash
pmap -x 1234 # 1234为PID
输出示例：
Address Kbytes RSS Dirty Mode Mapping
0000555... 102400 20480 0 r-x-- java
特别关注RSS列，这是真实的物理内存占用。
四、实战故障排查案例
场景：某台数据库服务器出现周期性卡顿，但CPU使用率不高。
排查步骤：
1. 通过free -s 5发现cache持续增长且不释放
2. vmstat 1显示si/so有偶发波动
3. sar -r 1确认内存回收压力
4. 最终用echo 3 > /proc/sys/vm/drop_caches手动释放缓存后恢复正常
根本原因：旧内核版本（3.10.0-514）的透明大页(THP)缺陷导致缓存回收异常。
五、内存优化黄金法则
- 禁用Swap原则：对数据库等延迟敏感服务，建议：
bash sysctl vm.swappiness=0 - OOM策略调优：
bash sysctl vm.overcommit_memory=2 # 严格模式 - 监控脚本示例：
bash #!/bin/bash CRITICAL=90 CURRENT=$(free | awk '/Mem/{printf("%.0f"), $3/$2*100}') [ $CURRENT -ge $CRITICAL ] && \ echo "$(date) 内存告警: ${CURRENT}%" >> /var/log/mem_alert.log
六、延伸思考
现代Linux的内存压缩技术（zswap/zram）正在改变传统管理方式，在内存有限的边缘计算设备上，可以尝试：
bash
modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
通过持续监控与策略调整，才能让每GB内存都发挥最大价值。记住，良好的内存管理不是追求100%利用率，而是在性能与资源之间找到最佳平衡点。
