别再只用free和top了！openEuler上这5个内存监控命令，运维老手都在用
在openEuler服务器运维中，内存问题往往是最难啃的硬骨头之一。当系统出现响应迟缓、服务异常时，大多数工程师的第一反应是打开top或free扫一眼内存占用率——这就像用体温计诊断疑难杂症，只能告诉你"发烧了"，却无法定位感染源。真正资深的运维专家，工具箱里永远备着更精密的内存分析仪器。
1. 为什么常规命令不够用？
free -m和top的输出看似直观，却隐藏着三个致命盲区：
- 缓存误导：Linux会主动利用空闲内存作磁盘缓存，
free显示的"used"包含这部分可回收资源。我曾见过一台显示内存占用98%的服务器实际可用内存超过40% - 粒度粗糙：
top的%MEM只显示进程物理内存占比，但现代应用常混合使用共享内存、mmap映射等复杂机制 - 维度单一：缺乏交换空间使用明细、缺页中断统计等关键指标，难以预判内存瓶颈
# 典型free输出陷阱示例（单位MB） $ free -m total used free shared buff/cache available Mem: 7982 7123 152 183 706 587 Swap: 2048 127 1921关键提示：
available才是真正可立即分配的内存，不是free列
2. 深度内存分析五件套
2.1 pmap - 进程内存解剖镜
当某个Java进程内存异常增长时，用pmap -X可以像CT扫描一样分层查看内存分配：
$ pmap -X 12345 Address Kbytes RSS Dirty Mode Mapping 000055f66e9b0000 1024 768 0 r-x-- java 00007f3d4fdf0000 2048 2048 2048 rw--- [anon] ...重点关注：
[anon]段：可能是堆内存泄漏点- 共享内存段(
s标志)：多个进程共享的库文件 - 脏页比例：过高可能预示IO压力
实战技巧：结合sort快速定位内存大户
pmap -x 12345 | sort -nk3 | tail -52.2 /proc/meminfo - 内存全景雷达
这个虚拟文件提供了200+个内存指标，以下是关键参数对照表：
| 指标 | 含义 | 危险阈值参考 |
|---|---|---|
| MemAvailable | 真正可用内存 | <10%总内存 |
| SwapCached | 被换出但未释放的内存 | >500MB |
| PageTables | 页表占用内存 | >1%总内存 |
| Slab | 内核对象缓存 | >5%总内存 |
| CommitLimit | 系统允许提交的内存上限 | 接近100% |
# 动态监控关键指标变化 watch -n 2 'grep -e MemAvailable -e SwapCached /proc/meminfo'2.3 smem - 智能内存报告器
需要安装smem包，它能自动计算USS/PSS等更真实的内存占用指标：
$ smem -t -k -P nginx PID User Command Swap USS PSS RSS 1234 www-data nginx: worker process 24.3M 56.1M 58.3M 89.2M- USS：进程独占物理内存（最真实成本）
- PSS：按比例计算的共享内存（推荐值）
- RSS：传统报告值（含共享部分）
对比实验：启动两个相同的Python进程观察共享内存：
python -c "import numpy; a=numpy.zeros(10000000)" & python -c "import numpy; a=numpy.zeros(10000000)" & smem -t -k -P python2.4 slabtop - 内核内存侦探
当free显示内存消失却找不到占用者时，可能是内核对象在"偷"内存：
$ slabtop -o Active / Total Objects (% used) : 234567 / 345678 (67.8%) Active / Total Slabs (% used) : 12345 / 13456 (91.7%) Active / Total Caches (% used) : 89 / 100 (89.0%) Active / Total Size (% used) : 1234.56K / 1456.78K (84.7%) Minimum / Average / Maximum Object : 0.01K / 0.08K / 2.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 12000 11900 99% 0.10K 300 40 120K buffer_head 8000 7800 97% 0.06K 200 40 80K kmalloc-64常见问题：
dentry缓存暴涨：文件句柄未关闭kmalloc-*过高：内核模块内存泄漏
2.5 vmstat - 动态趋势分析仪
vmstat 2 5输出中的内存相关列解读：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 51200 123456 78900 456789 0 0 12 23 345 678 10 5 85 0 0- si/so：交换区换入/换出速度（>10/s告警）
- cache：随时间持续增长可能预示内存泄漏
- wa：IO等待高时可能触发内存回收风暴
组合技：配合pidstat定位问题进程
vmstat 1 | tee memory.log & pidstat -r -p ALL 13. 经典故障排查流程
3.1 内存泄漏定位四步法
- 初步筛查：
smem -t -k找出USS持续增长的进程 - 详细分析：对可疑进程用
pmap -XX查看内存段变化 - 内核检查：
slabtop观察内核对象异常 - 趋势验证：
vmstat -S m 5监控交换活动
3.2 性能调优实战案例
某数据库服务器频繁OOM，但free显示充足内存。通过组合命令发现：
grep HugePages /proc/meminfo显示大页未启用pmap -x $PID发现大量64KB小内存块sysctl vm.nr_hugepages=1024配置大页后- 性能提升40%，OOM消失
4. 自动化监控方案
手工命令适合临时排查，生产环境推荐配置告警规则：
# 监控可用内存低于10% cat <<EOF > /etc/telegraf/telegraf.conf [[inputs.mem]] fielddrop = ["active", "inactive"] [[inputs.procstat]] pattern = ".*" metric_prefix = "process_" fieldpass = ["memory_rss"] EOF关键监控项建议：
- 进程PSS超过1GB
- Swap使用率持续>30%
- Slab内存每周增长>5%
- 缺页中断数突增10倍
