别再只用free和top了!openEuler上这5个内存监控命令,运维老手都在用

张开发
2026/4/22 11:13:23 15 分钟阅读

分享文章

别再只用free和top了!openEuler上这5个内存监控命令,运维老手都在用
别再只用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被换出但未释放的内存500MBPageTables页表占用内存1%总内存Slab内核对象缓存5%总内存CommitLimit系统允许提交的内存上限接近100%# 动态监控关键指标变化 watch -n 2 grep -e MemAvailable -e SwapCached /proc/meminfo2.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.2MUSS进程独占物理内存最真实成本PSS按比例计算的共享内存推荐值RSS传统报告值含共享部分对比实验启动两个相同的Python进程观察共享内存python -c import numpy; anumpy.zeros(10000000) python -c import numpy; anumpy.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 0si/so交换区换入/换出速度10/s告警cache随时间持续增长可能预示内存泄漏waIO等待高时可能触发内存回收风暴组合技配合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_hugepages1024配置大页后性能提升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超过1GBSwap使用率持续30%Slab内存每周增长5%缺页中断数突增10倍

更多文章