pmap -d PID可查看进程内存映射的设备与文件信息，显示Device（主次设备号）和Offset，结合Mapping路径判断是否来自磁盘文件；Device为00:00且Mapping为[anon]表示纯匿名内存，与文件无关。
Linux 没有“系统的内存映射文件”这个概念，你真正想查的，是某个进程的内存映射（尤其是哪些文件被 mmap 到了内存里），或者系统级的内存使用构成（比如 cache、buffers、shared 等）。直接运行 pmap 或 cat /proc/meminfo 都不会输出“内存映射文件占用”这种汇总值——它根本不存在。
怎么用 pmap -d 查看进程映射了哪些文件及其设备信息
如果你怀疑某个进程把大文件（如数据库索引、日志、共享库）通过 mmap 加载进内存，pmap -d PID 是唯一能确认映射来源的命令。它会显示每段映射对应的 Device（主次设备号）和 Offset（文件内偏移），从而反推是否来自磁盘文件。
-
Device列显示08:01这类编号 → 对应/dev/sda1等块设备，基本可判定是普通文件映射 -
Mapping列显示路径（如/lib/x86_64-linux-gnu/libc-2.31.so）+Device非00:00→ 确认该共享库已加载且有物理文件 backing -
Mapping为[anon]且Device是00:00→ 纯匿名内存，和文件无关 - 注意：
pmap -d不显示文件大小或总占用，只告诉你“这段内存映射自哪”，需结合ls -lh /path/to/file手动估算
为什么 cat /proc/meminfo 里的 Cached 不等于“映射文件占用”
Cached 字段常被误读为“被 mmap 的文件缓存”，其实它包含 page cache 中所有可回收页：包括 read() 读取的文件、mmap 的私有/共享映射、甚至 tmpfs 内容。它和“映射文件”无直接对应关系。
-
Cached高 ≠ 有大量文件被 mmap；可能只是刚cp过一个大文件 -
mmap(MAP_SHARED)修改的内容会脏页计入Cached，但MAP_PRIVATE的写时复制页不会 - 真正和 mmap 强相关的指标在单个进程层面：用
pmap -x PID看[anon]和[heap]的RSS，而非全局Cached
如何判断某个文件是否正被 mmap 占用大量内存
没有一键命令能列出“所有被 mmap 的文件及其 RSS 占用”，但可通过组合操作定位可疑目标：
- 先用
lsof -p PID | grep memmap或grep -a "memmap" /proc/PID/maps粗筛含 mmap 路径的行 - 对每个疑似映射路径，执行
find /proc/PID/map_files/ -lname "/path/to/file*" 2>/dev/null→ 若有匹配，说明该文件确实在进程地址空间中 - 再回到
pmap -x PID输出，找到对应Mapping行的RSS值（单位 KB），这才是它实际吃掉的物理内存 - 注意：同一个文件可能被多个进程 mmap，
RSS不可简单累加；smem -P <name> -c "pid mapss name"</name>可看 PSS 分摊后值
真正容易被忽略的是：mmap 的内存不一定会出现在 ps 的 RSS 或 top 的 RES 里——如果映射是 MAP_POPULATE 但尚未访问，页表已建但物理页未分配，RSS 仍为 0。这时候 pmap -x 的 Kbytes 是虚的，RSS 才是实的。别光看大小，盯住 RSS。
