先问一个很现实的问题你手上那台用了七八年的旧电脑或者公司机房里那台跑着祖传服务的老服务器最近是不是经常卡顿、风扇狂转打开任务管理器一看内存占用已经顶到了百分之九十多大部分人的第一反应是加内存条或者直接找一台新机器把服务迁走。但很多时候真正的问题并不是物理内存不够而是有某个进程在悄悄吞掉内存或者因为内存泄漏越涨越高。如果不先定位到具体进程就算把内存加到 32G、64G也只是给问题续命而不是解决问题。这篇文章想聊的就是一个看起来基础、却特别容易被忽视的环节进程内存统计。我会从最底层的概念讲起再给出适合老电脑、低配服务器使用的轻量级内存统计方案包括命令、脚本和一个完整的定时提交实现。重点解决三件事第一搞懂 top 里的内存数字到底怎么读第二写出一份能看清每个进程真实内存占用的统计工具第三把统计结果提交到日志或监控平台方便长期排查。1. 这篇文章真正要解决的问题先说一个真实场景。我见过不少同学排查服务器内存问题时习惯性地敲一句free -h看到 available 只剩几百兆就得出结论“内存不够了要扩容”。这个结论大方向没错但它解决不了实际问题。因为加完内存之后过几天可能又满了。你会发现自己始终在被动地处理问题却不知道到底是什么进程把内存吃掉的。真正有效的排查路径是先确认整体内存水位再按进程维度统计找出哪个进程的 RSS 或者 PSS 最高持续观察一段时间判断它是稳定占用还是持续增长如果是持续增长基本可以判定存在内存泄漏再深入分析具体代码或配置。这套流程里进程内存统计工具是承上启下的关键一环。没有它你只能看到“内存满了”这个结果看不到“谁干的”这个原因。还有一类场景更容易被忽略老电脑、低配服务器。这类机器往往配置不高比如 4G 内存、机械硬盘、老款 CPU。它们跑不了那些重量级监控平台比如需要在目标机器上安装 Agent、占用几百兆内存的监控采集器。这个时候轻量级的命令行统计方案反而最有价值。所以这篇文章不是教你安装某个大型监控系统而是从 Linux 系统自带的基础能力出发做一套“轻量、可移植、看得懂”的进程内存统计工具。它适合以下几类人正在排查服务器内存问题的运维和开发手里有老机器、低配云主机想控制资源开销的开发者想深入理解/proc文件系统和进程内存模型的 Linux 学习者。2. 核心概念进程内存到底怎么衡量在看统计脚本之前必须先理解几个关键指标。很多人在内存统计上犯的错基本都是因为混淆了这些概念。2.1 RSS、VSZ、PSS、USS 的区别用一句话概括同一份内存从不同角度看算出的“大小”完全不同。指标全称含义通俗理解VSZVirtual Memory Size进程虚拟内存大小进程理论上可访问的地址空间可能包含未实际分配的部分RSSResident Set Size常驻物理内存大小进程实际占用的物理内存但包含共享库的重复计算PSSProportional Set Size按比例分摊后的内存把共享内存按共享进程数量分摊更接近真实占用USSUnique Set Size独占内存大小一个进程独有的内存不包含任何共享部分top命令里默认显示的RES对应的就是 RSS。它的问题在于会把共享内存重复计算。比如一个 Nginx 有 8 个 worker 进程都加载了同一份动态库那 8 个进程的 RSS 里都算了这份库的内存加起来甚至可能超过物理内存总量。PSS 解决了这个问题。它把共享内存平均分摊给所有正在使用它的进程。所以如果你想知道“系统里所有进程加起来到底用了多少内存”看 PSS 更合理。USS 则最适合用来判断某个进程是不是在泄漏。因为共享内存再大也不会因为单个进程的行为而无限增长反而是 USS 不断上涨通常说明进程自己私有分配的内存有问题。2.2 为什么不能只看 top 里的 REStop是日常排查最常用的命令但它展示的内存视角比较粗糙。举个实际例子一个 Java 程序启动后JVM 会预先申请一大块堆内存。从top看它的RES可能一直维持在高位但实际上 JVM 内部可能在自动管理内存并没有真正“吃满”。反过来一个 C 语言程序因为malloc之后没有free导致堆不断膨胀RES持续上涨这才是真问题。再比如你看到某个进程的 RES 是 1.2G很惊讶。但如果你用smem或者读取/proc/pid/smaps_rollup看 PSS可能只有 300M。原因就是这个进程加载了大量共享库那些库被几十个其他进程同时使用。所以我的建议是日常快速排查可以看top但要做内存统计和基线分析一定要用 PSS 或 USS至少要用 RSS 加共享库信息交叉判断。2.3 Linux 下内存统计的数据来源Linux 系统里几乎所有进程内存数据都来自/proc文件系统。几个关键文件文件路径内容/proc/meminfo系统整体内存信息/proc/pid/status单进程内存状态包含 VmRSS、VmSize 等/proc/pid/smaps进程详细内存映射包含每个段的 RSS、PSS 等/proc/pid/smaps_rollupsmaps 的汇总版本读取速度快很多/proc/pid/smaps内容非常详细但缺点是文件很大解析起来很慢在老机器上可能会造成额外负载。内核 4.14 之后提供了smaps_rollup它直接给出汇总值解析成本低很多。如果你的内核版本支持优先用它。读取方式很简单cat /proc/1/smaps_rollup输出里会包含类似这样的内容Rss: 12345 kB Pss: 9876 kB Pss_Anon: 8000 kB Pss_File: 1876 kB这里Rss对应进程总常驻内存Pss是分摊后的内存。数据单位默认是 kB。3. 环境准备与工具选型做进程内存统计不一定非得上 APM 或者监控平台。在老机器上我倾向于优先使用系统自带的工具。3.1 最小环境要求操作系统Linux本文示例以 CentOS 7/Ubuntu 18.04 及以上版本为准原则上大多数命令通用内核版本如果希望读取smaps_rollup建议内核 4.14版本较低时可以用/proc/pid/smaps解析权限普通用户能查看大部分进程的 RSS但查看其他用户进程的详细内存映射可能需要 root 权限命令工具ps、top、grep、awk、sort这些基本系统自带无需安装。在内存统计这个场景里额外安装工具反而容易引入新的资源开销。像htop、smem虽然方便但如果原本系统就没有我不建议为了一次排查去安装。直接用/proc加脚本就能完成大部分需求。3.2 推荐的工具组合使用场景推荐方案是否额外安装快速查看进程内存排名ps aux --sort-%mem否持续观察内存变化top或pidstat -rpidstat 可能需要安装 sysstat精确统计 PSS 内存读取/proc/pid/smaps_rollup否编写定时统计脚本Python psutil或纯 Shellpsutil 需要 pip 安装长期收集与告警Shell 脚本 crontab/systemd timer否这里强调一下工具不是越重越好。在老机器上做内存监控核心原则是采集过程本身不能成为内存杀手。如果采集脚本每秒钟全量扫描一遍/proc下所有进程的 smaps机器负载反而会升高这就本末倒置了。4. 核心流程拆解在写代码之前先把整个流程想清楚。一套完整的进程内存统计工具通常包括四个环节采集、计算、输出、提交。4.1 采集采集阶段要解决两个问题枚举进程、读取内存数据。枚举进程最常见的方式是遍历/proc下以数字命名的目录因为 Linux 中每个进程都会在/proc下生成一个以 PID 为名字的目录。通过读取这些目录里的status或smaps_rollup文件就能拿到每个进程的内存快照。这里有一个性能取舍status文件小读取快但只提供 VmRSS、VmSize不提供 PSSsmaps_rollup文件提供 PSS但读取比 status 慢smaps文件最详细但解析成本最高不推荐全量遍历时使用。在定时统计场景下建议优先status只统计 RSS。如果有精确需求再对部分可疑进程读取smaps_rollup。4.2 计算计算阶段主要做排序和汇总。排序很简单按 RSS 或者 PSS 降序排列即可。汇总则需要考虑是否包含内核线程、是否过滤掉自己这个统计脚本进程。这里很容易踩坑。比如ps aux会显示很多内核线程它们的 RSS 通常很小但数量很多如果不过滤输出会非常长。实际分析时更关心的是占用内存最多的前 20 个用户态进程。4.3 输出输出格式决定了这份统计结果能不能被后续处理。我推荐的格式有两种人类可读的表格适合直接查看JSON 或 CSV适合提交给监控平台、日志系统做二次处理。在下面的示例里我会同时给出两种输出方式。4.4 提交“提交”这个词听起来很玄其实就是把统计结果写到指定位置。可以是追加写到一个本地日志文件通过 HTTP POST 提交到内部监控系统写入系统日志/var/log/messages通过 crontab 定时执行形成时间序列。这一环节是很多自写脚本容易忽略的。如果不考虑提交每次都要手动跑脚本那这个工具的价值就少了一半。真正到排查内存问题时事故往往发生在凌晨你需要的是历史数据而不是一个“事后诸葛”。5. 完整示例与代码实现下面进入实操环节。我会给出三个从浅到深的示例最快的一条命令、轻量 Shell 脚本、Python 结构化统计脚本。5.1 示例一一条命令查看内存占用 Top 10如果只是想快速定位问题不需要写脚本直接用ps就能完成ps aux --sort-%mem | head -n 11这段命令的含义是列出所有进程按内存占用率降序排序取前 11 行其中第一行是表头。如果你觉得%MEM不够直观可以看 RSS 的绝对值ps -eo pid,ppid,user,rss,vsz,comm --sort-rss | head -n 11这里的rss单位是 KBcomm是进程名。看到输出后第一列 PID 就是你要找的“内存大户”。这个命令适合应急快速定位。拿到 PID 之后再用下面的命令看单个进程的详细信息cat /proc/PID/status | grep -E VmRSS|VmSize|VmSwap注意把PID替换成实际进程号。5.2 示例二Shell 脚本统计全部进程内存并输出 Top 20一条命令适合应急但如果想每次生成一份带时间戳的报告就需要脚本化。创建一个文件memstat.sh#!/bin/bash # 文件路径/usr/local/bin/memstat.sh # 功能统计系统进程内存占用输出 Top 20 # 适用轻量级内存统计无额外依赖 echo 内存统计报告 $(date %Y-%m-%d %H:%M:%S) echo ------ 系统总内存 ------ free -h echo echo ------ 进程内存 Top 20 (按 RSS 降序) ------ # 打印表头 printf %-8s %-10s %-12s %-12s %s\n PID USER RSS(KB) VSZ(KB) COMMAND # 遍历 /proc 下的进程目录读取 status 中的 VmRSS 和 VmSize for pid in $(ls /proc | grep -E ^[0-9]$); do if [ -r /proc/$pid/status ]; then rss$(grep VmRSS /proc/$pid/status | awk {print $2}) vsz$(grep VmSize /proc/$pid/status | awk {print $2}) user$(stat -c %U /proc/$pid 2/dev/null) comm$(cat /proc/$pid/comm 2/dev/null) if [ -n $rss ]; then printf %-8s %-10s %-12s %-12s %s\n $pid $user $rss $vsz $comm fi fi done | sort -k3 -n -r | head -n 20执行方式chmod x /usr/local/bin/memstat.sh /usr/local/bin/memstat.sh这个脚本有几个细节值得注意使用/proc/pid/comm获取进程名比用ps再解析输出更直接stat -c %U获取进程所属用户通过sort -k3 -n -r按第三列 RSS 数值倒序排列过滤掉不可读的进程目录避免权限报错。如果只需要得到内存最大的前几个进程这个脚本已经够用。但它有个局限RSS 会把共享内存重复计算。所以接下来看第三个示例。5.3 示例三Python 脚本统计 PSS 并输出 JSON在需要精确统计 PSS或者要把结果交给监控平台时推荐用 Python 读取smaps_rollup并输出结构化数据。#!/usr/bin/env python3 # 文件路径/usr/local/bin/memstat_pss.py # 功能按 PSS 统计进程内存使用支持 JSON 输出 # 用法python3 memstat_pss.py --top 20 --json import json import os import re import argparse def get_pid_list(): 获取系统当前所有进程 PID pids [] for entry in os.listdir(/proc): if entry.isdigit(): pids.append(int(entry)) return pids def get_process_info(pid): 读取单进程内存信息优先使用 smaps_rollup info {} try: # 读取进程名和用户 with open(f/proc/{pid}/comm, r) as f: info[comm] f.read().strip() stat os.stat(f/proc/{pid}) info[uid] stat.st_uid # 优先读取 smaps_rollup rollup_path f/proc/{pid}/smaps_rollup if os.access(rollup_path, os.R_OK): with open(rollup_path, r) as f: for line in f: if line.startswith(Rss:): info[rss_kb] int(line.split()[1]) elif line.startswith(Pss:): info[pss_kb] int(line.split()[1]) else: # 低版本内核退回到 smaps 解析 smaps_path f/proc/{pid}/smaps rss, pss 0, 0 with open(smaps_path, r) as f: for line in f: if line.startswith(Rss:): rss int(line.split()[1]) elif line.startswith(Pss:): pss int(line.split()[1]) info[rss_kb] rss info[pss_kb] pss return info except (ProcessLookupError, PermissionError, FileNotFoundError): # 进程可能已退出或无权限读取 return None def main(): parser argparse.ArgumentParser(description进程内存统计工具) parser.add_argument(--top, typeint, default20, help显示前 N 个进程) parser.add_argument(--json, actionstore_true, help输出 JSON 格式) args parser.parse_args() results [] for pid in get_pid_list(): info get_process_info(pid) if info is None: continue info[pid] pid results.append(info) # 过滤掉统计脚本自身减少干扰 results [r for r in results if memstat not in r.get(comm, )] # 按 PSS 降序排序PSS 为 0 的排后面 results.sort(keylambda x: x.get(pss_kb, 0), reverseTrue) top_results results[:args.top] if args.json: output { timestamp: __import__(time).strftime(%Y-%m-%d %H:%M:%S), total_processes: len(results), top_processes: top_results } print(json.dumps(output, ensure_asciiFalse, indent2)) else: print(f{PID:8}{COMMAND:25}{RSS(KB):12}{PSS(KB):12}) print(- * 60) for r in top_results: print(f{r[pid]:8}{r.get(comm,?):25}{r.get(rss_kb,0):12}{r.get(pss_kb,0):12}) if __name__ __main__: main()运行方式# 表格输出 python3 /usr/local/bin/memstat_pss.py --top 20 # JSON 输出便于提交给监控平台 python3 /usr/local/bin/memstat_pss.py --top 20 --json这段脚本的核心价值在于 PSS 计算。它优先读取内核 4.14 提供的smaps_rollup如果内核太老就降级解析smaps并累加所有段的 PSS。这样脚本在老系统和新系统上都能运行兼容性更好。如果系统中没有 Python 的额外依赖以上脚本可以原生运行。如果项目环境允许使用psutil会更简洁但本文优先考虑老机器的使用场景所以使用标准库实现。6. 运行结果与效果验证写完了脚本怎么确认它真的可用不能只看到输出就说成功还要验证数字是否准确、性能是否可接受。6.1 预期输出示例运行memstat.sh后预期输出类似 内存统计报告 2025-01-15 14:30:22 ------ 系统总内存 ------ total used free shared buff/cache available Mem: 3.7G 2.1G 300M 12M 1.3G 1.2G ------ 进程内存 Top 20 (按 RSS 降序) ------ PID USER RSS(KB) VSZ(KB) COMMAND 1823 zhangsan 856320 2345678 java 2044 zhangsan 430210 1203456 python3 1120 root 301240 892340 mysqld运行 Python 脚本的 JSON 输出会类似{ timestamp: 2025-01-15 14:30:30, total_processes: 156, top_processes: [ { pid: 1823, comm: java, rss_kb: 856320, pss_kb: 512380 } ] }这里的关键区别就体现出来了。同一个 Java 进程RSS 是 856MBPSS 只有 512MB说明它有一部分内存是和其他进程共享的。如果你只看 RSS可能会误判它的真实占用。6.2 怎么判断统计结果是否准确第一交叉验证。用一个已知占内存的进程来测试。比如启动一个 Python 脚本让它分配 200MB 内存python3 -c x bytearray(200 * 1024 * 1024); import time; time.sleep(60)运行期间再用上面的脚本查看这个 python3 进程的 RSS 和 PSS理论上 RSS 应该接近 200MB 左右204800KB。如果差距过大说明读取的数据源有问题。第二核对总数。把所有进程的 RSS 加起来再和free -h对比理论上两者基本处于同一量级。由于存在共享内存重复计算进程 RSS 总和通常会大于系统已用内存这不算异常如果小很多就要检查是否漏统计了某些进程。第三观察稳定性。连续运行三次脚本PID 列表和内存数字应该基本一致。如果每次结果差异巨大可能是采样时进程在大量创建或退出也可能是脚本本身性能太差导致采集时间过长进程状态已经变化。6.3 性能验证在老机器上脚本本身的性能很重要。我们可以粗略测试一下脚本运行耗时time /usr/local/bin/memstat.sh在包含 150 个左右进程的系统上这个脚本在 1 秒内完成属于正常表现。如果耗时超过 5 秒就要注意了。性能瓶颈通常出在遍历/proc的smaps解析上。smaps_rollup的内核支持不是所有版本都有老内核下如果觉得smaps太慢建议退回到只读status获取 RSS 的方案或者降低统计频率。这里给一个经验值定时统计任务间隔不要短于 60 秒如果你需要用秒级采样抓内存尖峰要尽量缩减进程遍历范围比如只监控指定的几个 PID而不是全部进程。7. 常见问题与排查方法自己写过内存统计脚本的同学一定遇到过下面这些问题。这里整理一份排查表。问题现象可能原因排查方式解决方案脚本提示 Permission denied当前用户无权读取其他用户进程的内存信息检查运行用户是否有 root 权限使用 root 运行或对特定目录配置 sudo 权限读取 smaps_rollup 文件不存在内核版本低于 4.14不支持该接口执行uname -r查看内核版本回退到解析/proc/pid/smaps字段累加PSS 为 0 或缺失读取时机不对进程刚退出或权限不足检查进程 PID 是否还在运行增加异常捕获跳过该进程RSS 总和远超物理内存部分共享库被多个进程重复统计对比 PSS 总和改用 PSS 指标做总量评估脚本执行太慢遍历了过多进程或解析了 smaps 大文件用time测量耗时使用 smaps_rollup或减少统计 PID 范围定期执行时有重复叠加crontab 里任务重复配置或脚本本身未加锁查看 crontab 配置使用 flock 或 PID 文件防止并发执行统计不到 Java 进程的真实堆内存JVM 内部分代管理RSS 与堆大小不等结合 jcmd/jstat 查看堆内信息区分“进程内存”和“应用堆内存”两个维度输出的数字和 top 不一致top 的 RES 与脚本读取的 VmRSS 存在时间差或单位差异同一秒内对比两者统一数据来源优先使用/proc/pid/status接下来挑两个最容易踩坑的展开了讲。第一个坑权限问题。如果你用普通用户执行脚本会发现能列出自己启动的进程但看不到 root 用户的进程内存。这是 Linux 的权限隔离机制。解决办法有两个一是脚本由 root 执行二是只监控当前用户自己的进程。在涉及到生产环境时建议创建专用的只读权限账号并配合 sudo 的最小权限配置不要直接用 root 跑定时任务跑一整年。第二个坑PSS 读取链路。smaps_rollup文件虽然快但如果进程正在频繁申请内存读取时可能出现字段缺失或数值抖动。更常见的情况是脚本先读取 comm 文件拿到进程名再去读 smaps_rollup 时进程已经退出了。所以代码里必须加异常捕获否则整个脚本会因为一个进程退出而崩溃。8. 最佳实践与工程建议把脚本跑通只是第一步真正能在生产环境中稳定使用的内存统计工具还需要考虑下面这些工程问题。8.1 采集频率要克制采集频率过高会带来两个问题一是/proc遍历本身消耗 CPU二是生成大量日志把磁盘写满。我的建议是常规采集每 5 分钟一次内存预警触发后临时改为每 30 秒一次人工排查手动运行脚本不需要定时。不同场景下对频率的要求差别很大。如果是排查内存泄漏隔几分钟一条记录就够了因为泄漏是渐进过程如果是抓瞬时尖峰才需要提高频率。8.2 日志要轮转避免磁盘写满内存统计脚本如果追加写日志时间久了文件会越来越大。推荐使用系统自带的logrotate做日志轮转。下面是一个 logrotate 配置示例# 文件路径/etc/logrotate.d/memstat /var/log/memstat.log { daily rotate 30 compress missingok notifempty copytruncate }这个配置的含义是每天轮转一次保留 30 天压缩旧日志如果日志文件为空则跳过使用 copytruncate 避免影响正在写入的进程。8.3 定时任务要防重入crontab 里配置的脚本如果上一次还没跑完下一次又开始了可能造成资源竞争和数据混乱。加一个 flock 锁是最简单的防重入方案。# 文件路径/etc/cron.d/memstat */5 * * * * root /usr/bin/flock -n /tmp/memstat.lock /usr/local/bin/memstat.sh /var/log/memstat.log 21这里flock -n表示拿不到锁就直接退出不等待。这样即使上一次执行卡住了也不会叠加执行。8.4 安全与权限最小权限原则在生产环境给采集脚本分配以下权限比直接给 root 更好脚本文件属主为 root权限为 750创建专用系统账号memmon只给它读取/proc和写日志的权限crontab 以memmon用户运行避免核心账号被滥用。如果对安全要求更高可以把脚本放到独立的目录使用 sudo 配置只允许执行特定命令。千万不要在脚本里写死后门或把统计结果发到不受控的外部服务这是很危险的。8.5 统计结果要与业务信息关联很多时候光看进程名无法判断问题归属。比如你看到java进程占内存很大但你不知道它是哪个业务、哪个部署单元。因此在统计输出中加入业务标签会很有价值。建议在脚本中维护一张 PID 到业务名的映射表或者通过环境变量、启动参数来识别进程。比如 Java 程序通常会带-Dapp.namedemo-service参数可以在启动命令中抓取这个信息。Shell 解析起来麻烦一些Python 脚本则可以通过读取/proc/pid/cmdline来处理。8.6 老机器上的特殊注意事项老机器或者低配云主机做内存监控要额外注意以下三点第一别装重量级 Agent。有些监控客户端本身就要占用上百兆内存在 4G 内存的机器上不值得。系统自带工具加脚本是最佳选择。第二别同时开太多监控脚本。我见过一台低配机器上同时跑了多个监控脚本每个脚本每 1 分钟全量扫一次/proc结果监控本身把 CPU 打满了。统一用一个脚本把多个指标合并采集。第三注意 swap 空间。如果内存报告显示进程的VmSwap很大说明进程的内存已经被交换到磁盘上了。这种情况通常意味着物理内存真的不够但具体是哪个进程导致的还是要通过 RSS/PSS 历史趋势来判断。8.7 结合 systemd timer 替代 crontab如果你的系统使用 systemd建议优先用 systemd timer而不是 crontab。因为 systemd timer 自带日志、失败重试、资源限制等能力排错更方便。创建一个 service 单元# 文件路径/etc/systemd/system/memstat.service [Unit] DescriptionProcess Memory Statistics Collection [Service] Typeoneshot ExecStart/usr/local/bin/memstat_pss.py --top 30 --json StandardOutputappend:/var/log/memstat.log再创建对应的 timer# 文件路径/etc/systemd/system/memstat.timer [Unit] DescriptionRun memstat every 5 minutes [Timer] OnCalendar*:0/5 Persistenttrue [Install] WantedBytimers.target启用方式systemctl daemon-reload systemctl enable memstat.timer systemctl start memstat.timer这种方式的好处是可以清楚地查到上一次采集是什么时候、是否失败、失败原因是什么。journalctl -u memstat.service直接看日志比在 crontab 里排查方便得多。9. 总结与后续学习方向从一条ps命令开始到读/proc/pid/smaps_rollup再到写一个带 JSON 输出的 Python 统计脚本我们把进程内存统计这条链路完整走了一遍。现在再回头看“沧桑电脑系统提交内存统计工具”这个话题其实它真正表达的是一个很朴素的需求在资源受限的机器上用一种轻量、可靠、可长期运行的方式搞清楚每个进程到底吃掉了多少内存并把结果记录下来供后续分析。这件事不一定要用商业监控软件也不一定要引入大数据组件系统自带的/proc加几十行脚本就足够了。如果你想继续深入有四个方向可以选第一研究/proc/pid/smaps里的每个字段理解Anon、File、Shared、Swap这些细分项对应的内存类型。这是打好内存分析基础的关键。第二学习如何做内存泄漏的趋势分析。定期采集 PSS 并绘制趋势线观察哪些进程的内存持续增长再横向对比同类型进程往往能更快定位异常。第三把统计结果接入现有的告警系统。本文已经给出了 JSON 输出你只需要在脚本里加一段 HTTP POST 代码就能把数据提交给监控平台。第四对 Windows 系统做类似的内存统计。Windows 没有/proc但可以使用Get-Process或者typeperf实现相似效果思路是共通的。最后提醒一句内存统计工具只是排查工作的起点。真正解决内存问题还需要结合应用日志、代码分析、GC 日志等手段做综合判断。先把统计做实后面分析才有依据。建议把这篇文章里的脚本保存下来在你自己的机器上先跑一遍试试。遇到数字对不上的时候多思考一下 RSS 和 PSS 的区别多对比几次 top 的输出很快就能建立起属于你自己的内存监控手感。 轻量级进程内存统计：基于/proc的RSS与PSS监控脚本实践
先问一个很现实的问题你手上那台用了七八年的旧电脑或者公司机房里那台跑着祖传服务的老服务器最近是不是经常卡顿、风扇狂转打开任务管理器一看内存占用已经顶到了百分之九十多大部分人的第一反应是加内存条或者直接找一台新机器把服务迁走。但很多时候真正的问题并不是物理内存不够而是有某个进程在悄悄吞掉内存或者因为内存泄漏越涨越高。如果不先定位到具体进程就算把内存加到 32G、64G也只是给问题续命而不是解决问题。这篇文章想聊的就是一个看起来基础、却特别容易被忽视的环节进程内存统计。我会从最底层的概念讲起再给出适合老电脑、低配服务器使用的轻量级内存统计方案包括命令、脚本和一个完整的定时提交实现。重点解决三件事第一搞懂 top 里的内存数字到底怎么读第二写出一份能看清每个进程真实内存占用的统计工具第三把统计结果提交到日志或监控平台方便长期排查。1. 这篇文章真正要解决的问题先说一个真实场景。我见过不少同学排查服务器内存问题时习惯性地敲一句free -h看到 available 只剩几百兆就得出结论“内存不够了要扩容”。这个结论大方向没错但它解决不了实际问题。因为加完内存之后过几天可能又满了。你会发现自己始终在被动地处理问题却不知道到底是什么进程把内存吃掉的。真正有效的排查路径是先确认整体内存水位再按进程维度统计找出哪个进程的 RSS 或者 PSS 最高持续观察一段时间判断它是稳定占用还是持续增长如果是持续增长基本可以判定存在内存泄漏再深入分析具体代码或配置。这套流程里进程内存统计工具是承上启下的关键一环。没有它你只能看到“内存满了”这个结果看不到“谁干的”这个原因。还有一类场景更容易被忽略老电脑、低配服务器。这类机器往往配置不高比如 4G 内存、机械硬盘、老款 CPU。它们跑不了那些重量级监控平台比如需要在目标机器上安装 Agent、占用几百兆内存的监控采集器。这个时候轻量级的命令行统计方案反而最有价值。所以这篇文章不是教你安装某个大型监控系统而是从 Linux 系统自带的基础能力出发做一套“轻量、可移植、看得懂”的进程内存统计工具。它适合以下几类人正在排查服务器内存问题的运维和开发手里有老机器、低配云主机想控制资源开销的开发者想深入理解/proc文件系统和进程内存模型的 Linux 学习者。2. 核心概念进程内存到底怎么衡量在看统计脚本之前必须先理解几个关键指标。很多人在内存统计上犯的错基本都是因为混淆了这些概念。2.1 RSS、VSZ、PSS、USS 的区别用一句话概括同一份内存从不同角度看算出的“大小”完全不同。指标全称含义通俗理解VSZVirtual Memory Size进程虚拟内存大小进程理论上可访问的地址空间可能包含未实际分配的部分RSSResident Set Size常驻物理内存大小进程实际占用的物理内存但包含共享库的重复计算PSSProportional Set Size按比例分摊后的内存把共享内存按共享进程数量分摊更接近真实占用USSUnique Set Size独占内存大小一个进程独有的内存不包含任何共享部分top命令里默认显示的RES对应的就是 RSS。它的问题在于会把共享内存重复计算。比如一个 Nginx 有 8 个 worker 进程都加载了同一份动态库那 8 个进程的 RSS 里都算了这份库的内存加起来甚至可能超过物理内存总量。PSS 解决了这个问题。它把共享内存平均分摊给所有正在使用它的进程。所以如果你想知道“系统里所有进程加起来到底用了多少内存”看 PSS 更合理。USS 则最适合用来判断某个进程是不是在泄漏。因为共享内存再大也不会因为单个进程的行为而无限增长反而是 USS 不断上涨通常说明进程自己私有分配的内存有问题。2.2 为什么不能只看 top 里的 REStop是日常排查最常用的命令但它展示的内存视角比较粗糙。举个实际例子一个 Java 程序启动后JVM 会预先申请一大块堆内存。从top看它的RES可能一直维持在高位但实际上 JVM 内部可能在自动管理内存并没有真正“吃满”。反过来一个 C 语言程序因为malloc之后没有free导致堆不断膨胀RES持续上涨这才是真问题。再比如你看到某个进程的 RES 是 1.2G很惊讶。但如果你用smem或者读取/proc/pid/smaps_rollup看 PSS可能只有 300M。原因就是这个进程加载了大量共享库那些库被几十个其他进程同时使用。所以我的建议是日常快速排查可以看top但要做内存统计和基线分析一定要用 PSS 或 USS至少要用 RSS 加共享库信息交叉判断。2.3 Linux 下内存统计的数据来源Linux 系统里几乎所有进程内存数据都来自/proc文件系统。几个关键文件文件路径内容/proc/meminfo系统整体内存信息/proc/pid/status单进程内存状态包含 VmRSS、VmSize 等/proc/pid/smaps进程详细内存映射包含每个段的 RSS、PSS 等/proc/pid/smaps_rollupsmaps 的汇总版本读取速度快很多/proc/pid/smaps内容非常详细但缺点是文件很大解析起来很慢在老机器上可能会造成额外负载。内核 4.14 之后提供了smaps_rollup它直接给出汇总值解析成本低很多。如果你的内核版本支持优先用它。读取方式很简单cat /proc/1/smaps_rollup输出里会包含类似这样的内容Rss: 12345 kB Pss: 9876 kB Pss_Anon: 8000 kB Pss_File: 1876 kB这里Rss对应进程总常驻内存Pss是分摊后的内存。数据单位默认是 kB。3. 环境准备与工具选型做进程内存统计不一定非得上 APM 或者监控平台。在老机器上我倾向于优先使用系统自带的工具。3.1 最小环境要求操作系统Linux本文示例以 CentOS 7/Ubuntu 18.04 及以上版本为准原则上大多数命令通用内核版本如果希望读取smaps_rollup建议内核 4.14版本较低时可以用/proc/pid/smaps解析权限普通用户能查看大部分进程的 RSS但查看其他用户进程的详细内存映射可能需要 root 权限命令工具ps、top、grep、awk、sort这些基本系统自带无需安装。在内存统计这个场景里额外安装工具反而容易引入新的资源开销。像htop、smem虽然方便但如果原本系统就没有我不建议为了一次排查去安装。直接用/proc加脚本就能完成大部分需求。3.2 推荐的工具组合使用场景推荐方案是否额外安装快速查看进程内存排名ps aux --sort-%mem否持续观察内存变化top或pidstat -rpidstat 可能需要安装 sysstat精确统计 PSS 内存读取/proc/pid/smaps_rollup否编写定时统计脚本Python psutil或纯 Shellpsutil 需要 pip 安装长期收集与告警Shell 脚本 crontab/systemd timer否这里强调一下工具不是越重越好。在老机器上做内存监控核心原则是采集过程本身不能成为内存杀手。如果采集脚本每秒钟全量扫描一遍/proc下所有进程的 smaps机器负载反而会升高这就本末倒置了。4. 核心流程拆解在写代码之前先把整个流程想清楚。一套完整的进程内存统计工具通常包括四个环节采集、计算、输出、提交。4.1 采集采集阶段要解决两个问题枚举进程、读取内存数据。枚举进程最常见的方式是遍历/proc下以数字命名的目录因为 Linux 中每个进程都会在/proc下生成一个以 PID 为名字的目录。通过读取这些目录里的status或smaps_rollup文件就能拿到每个进程的内存快照。这里有一个性能取舍status文件小读取快但只提供 VmRSS、VmSize不提供 PSSsmaps_rollup文件提供 PSS但读取比 status 慢smaps文件最详细但解析成本最高不推荐全量遍历时使用。在定时统计场景下建议优先status只统计 RSS。如果有精确需求再对部分可疑进程读取smaps_rollup。4.2 计算计算阶段主要做排序和汇总。排序很简单按 RSS 或者 PSS 降序排列即可。汇总则需要考虑是否包含内核线程、是否过滤掉自己这个统计脚本进程。这里很容易踩坑。比如ps aux会显示很多内核线程它们的 RSS 通常很小但数量很多如果不过滤输出会非常长。实际分析时更关心的是占用内存最多的前 20 个用户态进程。4.3 输出输出格式决定了这份统计结果能不能被后续处理。我推荐的格式有两种人类可读的表格适合直接查看JSON 或 CSV适合提交给监控平台、日志系统做二次处理。在下面的示例里我会同时给出两种输出方式。4.4 提交“提交”这个词听起来很玄其实就是把统计结果写到指定位置。可以是追加写到一个本地日志文件通过 HTTP POST 提交到内部监控系统写入系统日志/var/log/messages通过 crontab 定时执行形成时间序列。这一环节是很多自写脚本容易忽略的。如果不考虑提交每次都要手动跑脚本那这个工具的价值就少了一半。真正到排查内存问题时事故往往发生在凌晨你需要的是历史数据而不是一个“事后诸葛”。5. 完整示例与代码实现下面进入实操环节。我会给出三个从浅到深的示例最快的一条命令、轻量 Shell 脚本、Python 结构化统计脚本。5.1 示例一一条命令查看内存占用 Top 10如果只是想快速定位问题不需要写脚本直接用ps就能完成ps aux --sort-%mem | head -n 11这段命令的含义是列出所有进程按内存占用率降序排序取前 11 行其中第一行是表头。如果你觉得%MEM不够直观可以看 RSS 的绝对值ps -eo pid,ppid,user,rss,vsz,comm --sort-rss | head -n 11这里的rss单位是 KBcomm是进程名。看到输出后第一列 PID 就是你要找的“内存大户”。这个命令适合应急快速定位。拿到 PID 之后再用下面的命令看单个进程的详细信息cat /proc/PID/status | grep -E VmRSS|VmSize|VmSwap注意把PID替换成实际进程号。5.2 示例二Shell 脚本统计全部进程内存并输出 Top 20一条命令适合应急但如果想每次生成一份带时间戳的报告就需要脚本化。创建一个文件memstat.sh#!/bin/bash # 文件路径/usr/local/bin/memstat.sh # 功能统计系统进程内存占用输出 Top 20 # 适用轻量级内存统计无额外依赖 echo 内存统计报告 $(date %Y-%m-%d %H:%M:%S) echo ------ 系统总内存 ------ free -h echo echo ------ 进程内存 Top 20 (按 RSS 降序) ------ # 打印表头 printf %-8s %-10s %-12s %-12s %s\n PID USER RSS(KB) VSZ(KB) COMMAND # 遍历 /proc 下的进程目录读取 status 中的 VmRSS 和 VmSize for pid in $(ls /proc | grep -E ^[0-9]$); do if [ -r /proc/$pid/status ]; then rss$(grep VmRSS /proc/$pid/status | awk {print $2}) vsz$(grep VmSize /proc/$pid/status | awk {print $2}) user$(stat -c %U /proc/$pid 2/dev/null) comm$(cat /proc/$pid/comm 2/dev/null) if [ -n $rss ]; then printf %-8s %-10s %-12s %-12s %s\n $pid $user $rss $vsz $comm fi fi done | sort -k3 -n -r | head -n 20执行方式chmod x /usr/local/bin/memstat.sh /usr/local/bin/memstat.sh这个脚本有几个细节值得注意使用/proc/pid/comm获取进程名比用ps再解析输出更直接stat -c %U获取进程所属用户通过sort -k3 -n -r按第三列 RSS 数值倒序排列过滤掉不可读的进程目录避免权限报错。如果只需要得到内存最大的前几个进程这个脚本已经够用。但它有个局限RSS 会把共享内存重复计算。所以接下来看第三个示例。5.3 示例三Python 脚本统计 PSS 并输出 JSON在需要精确统计 PSS或者要把结果交给监控平台时推荐用 Python 读取smaps_rollup并输出结构化数据。#!/usr/bin/env python3 # 文件路径/usr/local/bin/memstat_pss.py # 功能按 PSS 统计进程内存使用支持 JSON 输出 # 用法python3 memstat_pss.py --top 20 --json import json import os import re import argparse def get_pid_list(): 获取系统当前所有进程 PID pids [] for entry in os.listdir(/proc): if entry.isdigit(): pids.append(int(entry)) return pids def get_process_info(pid): 读取单进程内存信息优先使用 smaps_rollup info {} try: # 读取进程名和用户 with open(f/proc/{pid}/comm, r) as f: info[comm] f.read().strip() stat os.stat(f/proc/{pid}) info[uid] stat.st_uid # 优先读取 smaps_rollup rollup_path f/proc/{pid}/smaps_rollup if os.access(rollup_path, os.R_OK): with open(rollup_path, r) as f: for line in f: if line.startswith(Rss:): info[rss_kb] int(line.split()[1]) elif line.startswith(Pss:): info[pss_kb] int(line.split()[1]) else: # 低版本内核退回到 smaps 解析 smaps_path f/proc/{pid}/smaps rss, pss 0, 0 with open(smaps_path, r) as f: for line in f: if line.startswith(Rss:): rss int(line.split()[1]) elif line.startswith(Pss:): pss int(line.split()[1]) info[rss_kb] rss info[pss_kb] pss return info except (ProcessLookupError, PermissionError, FileNotFoundError): # 进程可能已退出或无权限读取 return None def main(): parser argparse.ArgumentParser(description进程内存统计工具) parser.add_argument(--top, typeint, default20, help显示前 N 个进程) parser.add_argument(--json, actionstore_true, help输出 JSON 格式) args parser.parse_args() results [] for pid in get_pid_list(): info get_process_info(pid) if info is None: continue info[pid] pid results.append(info) # 过滤掉统计脚本自身减少干扰 results [r for r in results if memstat not in r.get(comm, )] # 按 PSS 降序排序PSS 为 0 的排后面 results.sort(keylambda x: x.get(pss_kb, 0), reverseTrue) top_results results[:args.top] if args.json: output { timestamp: __import__(time).strftime(%Y-%m-%d %H:%M:%S), total_processes: len(results), top_processes: top_results } print(json.dumps(output, ensure_asciiFalse, indent2)) else: print(f{PID:8}{COMMAND:25}{RSS(KB):12}{PSS(KB):12}) print(- * 60) for r in top_results: print(f{r[pid]:8}{r.get(comm,?):25}{r.get(rss_kb,0):12}{r.get(pss_kb,0):12}) if __name__ __main__: main()运行方式# 表格输出 python3 /usr/local/bin/memstat_pss.py --top 20 # JSON 输出便于提交给监控平台 python3 /usr/local/bin/memstat_pss.py --top 20 --json这段脚本的核心价值在于 PSS 计算。它优先读取内核 4.14 提供的smaps_rollup如果内核太老就降级解析smaps并累加所有段的 PSS。这样脚本在老系统和新系统上都能运行兼容性更好。如果系统中没有 Python 的额外依赖以上脚本可以原生运行。如果项目环境允许使用psutil会更简洁但本文优先考虑老机器的使用场景所以使用标准库实现。6. 运行结果与效果验证写完了脚本怎么确认它真的可用不能只看到输出就说成功还要验证数字是否准确、性能是否可接受。6.1 预期输出示例运行memstat.sh后预期输出类似 内存统计报告 2025-01-15 14:30:22 ------ 系统总内存 ------ total used free shared buff/cache available Mem: 3.7G 2.1G 300M 12M 1.3G 1.2G ------ 进程内存 Top 20 (按 RSS 降序) ------ PID USER RSS(KB) VSZ(KB) COMMAND 1823 zhangsan 856320 2345678 java 2044 zhangsan 430210 1203456 python3 1120 root 301240 892340 mysqld运行 Python 脚本的 JSON 输出会类似{ timestamp: 2025-01-15 14:30:30, total_processes: 156, top_processes: [ { pid: 1823, comm: java, rss_kb: 856320, pss_kb: 512380 } ] }这里的关键区别就体现出来了。同一个 Java 进程RSS 是 856MBPSS 只有 512MB说明它有一部分内存是和其他进程共享的。如果你只看 RSS可能会误判它的真实占用。6.2 怎么判断统计结果是否准确第一交叉验证。用一个已知占内存的进程来测试。比如启动一个 Python 脚本让它分配 200MB 内存python3 -c x bytearray(200 * 1024 * 1024); import time; time.sleep(60)运行期间再用上面的脚本查看这个 python3 进程的 RSS 和 PSS理论上 RSS 应该接近 200MB 左右204800KB。如果差距过大说明读取的数据源有问题。第二核对总数。把所有进程的 RSS 加起来再和free -h对比理论上两者基本处于同一量级。由于存在共享内存重复计算进程 RSS 总和通常会大于系统已用内存这不算异常如果小很多就要检查是否漏统计了某些进程。第三观察稳定性。连续运行三次脚本PID 列表和内存数字应该基本一致。如果每次结果差异巨大可能是采样时进程在大量创建或退出也可能是脚本本身性能太差导致采集时间过长进程状态已经变化。6.3 性能验证在老机器上脚本本身的性能很重要。我们可以粗略测试一下脚本运行耗时time /usr/local/bin/memstat.sh在包含 150 个左右进程的系统上这个脚本在 1 秒内完成属于正常表现。如果耗时超过 5 秒就要注意了。性能瓶颈通常出在遍历/proc的smaps解析上。smaps_rollup的内核支持不是所有版本都有老内核下如果觉得smaps太慢建议退回到只读status获取 RSS 的方案或者降低统计频率。这里给一个经验值定时统计任务间隔不要短于 60 秒如果你需要用秒级采样抓内存尖峰要尽量缩减进程遍历范围比如只监控指定的几个 PID而不是全部进程。7. 常见问题与排查方法自己写过内存统计脚本的同学一定遇到过下面这些问题。这里整理一份排查表。问题现象可能原因排查方式解决方案脚本提示 Permission denied当前用户无权读取其他用户进程的内存信息检查运行用户是否有 root 权限使用 root 运行或对特定目录配置 sudo 权限读取 smaps_rollup 文件不存在内核版本低于 4.14不支持该接口执行uname -r查看内核版本回退到解析/proc/pid/smaps字段累加PSS 为 0 或缺失读取时机不对进程刚退出或权限不足检查进程 PID 是否还在运行增加异常捕获跳过该进程RSS 总和远超物理内存部分共享库被多个进程重复统计对比 PSS 总和改用 PSS 指标做总量评估脚本执行太慢遍历了过多进程或解析了 smaps 大文件用time测量耗时使用 smaps_rollup或减少统计 PID 范围定期执行时有重复叠加crontab 里任务重复配置或脚本本身未加锁查看 crontab 配置使用 flock 或 PID 文件防止并发执行统计不到 Java 进程的真实堆内存JVM 内部分代管理RSS 与堆大小不等结合 jcmd/jstat 查看堆内信息区分“进程内存”和“应用堆内存”两个维度输出的数字和 top 不一致top 的 RES 与脚本读取的 VmRSS 存在时间差或单位差异同一秒内对比两者统一数据来源优先使用/proc/pid/status接下来挑两个最容易踩坑的展开了讲。第一个坑权限问题。如果你用普通用户执行脚本会发现能列出自己启动的进程但看不到 root 用户的进程内存。这是 Linux 的权限隔离机制。解决办法有两个一是脚本由 root 执行二是只监控当前用户自己的进程。在涉及到生产环境时建议创建专用的只读权限账号并配合 sudo 的最小权限配置不要直接用 root 跑定时任务跑一整年。第二个坑PSS 读取链路。smaps_rollup文件虽然快但如果进程正在频繁申请内存读取时可能出现字段缺失或数值抖动。更常见的情况是脚本先读取 comm 文件拿到进程名再去读 smaps_rollup 时进程已经退出了。所以代码里必须加异常捕获否则整个脚本会因为一个进程退出而崩溃。8. 最佳实践与工程建议把脚本跑通只是第一步真正能在生产环境中稳定使用的内存统计工具还需要考虑下面这些工程问题。8.1 采集频率要克制采集频率过高会带来两个问题一是/proc遍历本身消耗 CPU二是生成大量日志把磁盘写满。我的建议是常规采集每 5 分钟一次内存预警触发后临时改为每 30 秒一次人工排查手动运行脚本不需要定时。不同场景下对频率的要求差别很大。如果是排查内存泄漏隔几分钟一条记录就够了因为泄漏是渐进过程如果是抓瞬时尖峰才需要提高频率。8.2 日志要轮转避免磁盘写满内存统计脚本如果追加写日志时间久了文件会越来越大。推荐使用系统自带的logrotate做日志轮转。下面是一个 logrotate 配置示例# 文件路径/etc/logrotate.d/memstat /var/log/memstat.log { daily rotate 30 compress missingok notifempty copytruncate }这个配置的含义是每天轮转一次保留 30 天压缩旧日志如果日志文件为空则跳过使用 copytruncate 避免影响正在写入的进程。8.3 定时任务要防重入crontab 里配置的脚本如果上一次还没跑完下一次又开始了可能造成资源竞争和数据混乱。加一个 flock 锁是最简单的防重入方案。# 文件路径/etc/cron.d/memstat */5 * * * * root /usr/bin/flock -n /tmp/memstat.lock /usr/local/bin/memstat.sh /var/log/memstat.log 21这里flock -n表示拿不到锁就直接退出不等待。这样即使上一次执行卡住了也不会叠加执行。8.4 安全与权限最小权限原则在生产环境给采集脚本分配以下权限比直接给 root 更好脚本文件属主为 root权限为 750创建专用系统账号memmon只给它读取/proc和写日志的权限crontab 以memmon用户运行避免核心账号被滥用。如果对安全要求更高可以把脚本放到独立的目录使用 sudo 配置只允许执行特定命令。千万不要在脚本里写死后门或把统计结果发到不受控的外部服务这是很危险的。8.5 统计结果要与业务信息关联很多时候光看进程名无法判断问题归属。比如你看到java进程占内存很大但你不知道它是哪个业务、哪个部署单元。因此在统计输出中加入业务标签会很有价值。建议在脚本中维护一张 PID 到业务名的映射表或者通过环境变量、启动参数来识别进程。比如 Java 程序通常会带-Dapp.namedemo-service参数可以在启动命令中抓取这个信息。Shell 解析起来麻烦一些Python 脚本则可以通过读取/proc/pid/cmdline来处理。8.6 老机器上的特殊注意事项老机器或者低配云主机做内存监控要额外注意以下三点第一别装重量级 Agent。有些监控客户端本身就要占用上百兆内存在 4G 内存的机器上不值得。系统自带工具加脚本是最佳选择。第二别同时开太多监控脚本。我见过一台低配机器上同时跑了多个监控脚本每个脚本每 1 分钟全量扫一次/proc结果监控本身把 CPU 打满了。统一用一个脚本把多个指标合并采集。第三注意 swap 空间。如果内存报告显示进程的VmSwap很大说明进程的内存已经被交换到磁盘上了。这种情况通常意味着物理内存真的不够但具体是哪个进程导致的还是要通过 RSS/PSS 历史趋势来判断。8.7 结合 systemd timer 替代 crontab如果你的系统使用 systemd建议优先用 systemd timer而不是 crontab。因为 systemd timer 自带日志、失败重试、资源限制等能力排错更方便。创建一个 service 单元# 文件路径/etc/systemd/system/memstat.service [Unit] DescriptionProcess Memory Statistics Collection [Service] Typeoneshot ExecStart/usr/local/bin/memstat_pss.py --top 30 --json StandardOutputappend:/var/log/memstat.log再创建对应的 timer# 文件路径/etc/systemd/system/memstat.timer [Unit] DescriptionRun memstat every 5 minutes [Timer] OnCalendar*:0/5 Persistenttrue [Install] WantedBytimers.target启用方式systemctl daemon-reload systemctl enable memstat.timer systemctl start memstat.timer这种方式的好处是可以清楚地查到上一次采集是什么时候、是否失败、失败原因是什么。journalctl -u memstat.service直接看日志比在 crontab 里排查方便得多。9. 总结与后续学习方向从一条ps命令开始到读/proc/pid/smaps_rollup再到写一个带 JSON 输出的 Python 统计脚本我们把进程内存统计这条链路完整走了一遍。现在再回头看“沧桑电脑系统提交内存统计工具”这个话题其实它真正表达的是一个很朴素的需求在资源受限的机器上用一种轻量、可靠、可长期运行的方式搞清楚每个进程到底吃掉了多少内存并把结果记录下来供后续分析。这件事不一定要用商业监控软件也不一定要引入大数据组件系统自带的/proc加几十行脚本就足够了。如果你想继续深入有四个方向可以选第一研究/proc/pid/smaps里的每个字段理解Anon、File、Shared、Swap这些细分项对应的内存类型。这是打好内存分析基础的关键。第二学习如何做内存泄漏的趋势分析。定期采集 PSS 并绘制趋势线观察哪些进程的内存持续增长再横向对比同类型进程往往能更快定位异常。第三把统计结果接入现有的告警系统。本文已经给出了 JSON 输出你只需要在脚本里加一段 HTTP POST 代码就能把数据提交给监控平台。第四对 Windows 系统做类似的内存统计。Windows 没有/proc但可以使用Get-Process或者typeperf实现相似效果思路是共通的。最后提醒一句内存统计工具只是排查工作的起点。真正解决内存问题还需要结合应用日志、代码分析、GC 日志等手段做综合判断。先把统计做实后面分析才有依据。建议把这篇文章里的脚本保存下来在你自己的机器上先跑一遍试试。遇到数字对不上的时候多思考一下 RSS 和 PSS 的区别多对比几次 top 的输出很快就能建立起属于你自己的内存监控手感。