麒麟os中查找虚实比（vsz/rss）大于50的进程，需用ps与awk组合命令筛选rss非零且比值超阈值的进程，再通过/proc/pid/maps和lsof分析大内存映射未触发缺页的原因。
麒麟OS中查找占用大量虚拟内存（VSZ）但物理内存（RSS）占比极低的进程，需绕过%MEM和RES排序逻辑，直接提取并比值筛选——这类进程常见于预分配大堆但未实际使用的Java服务、调试中的大型编译器或内存映射文件未触发缺页的程序。
用ps命令提取VSZ与RSS并计算虚实比
执行以下命令一次性列出虚实比（VSZ/RSS）大于50的进程：
ps -eo pid,vsz,rss,comm,user --sort=-vsz | awk '$3>0 && $2/$3>50 {printf "%-8d %-10d %-10d %-8.2f %-12s %s\n", $1, $2, $3, $2/$3, $5, $6}' | head -n 10
该命令先按VSZ降序排列所有进程，再用awk过滤出RSS非零且虚实比超50的条目；【若RSS为0，说明该进程尚未触发任何物理页分配，纯属地址空间占位】。输出字段依次为PID、VSZ(KB)、RSS(KB)、比值、用户、命令名。
注意：VSZ单位是KB，数值达数GB很常见，但关键看比值而非绝对值——一个VSZ=4GB、RSS=64MB的进程，比值为64，远高于正常应用（通常
用top交互式定位高VSZ低RSS进程
打开终端输入top→按f键进入字段管理界面→按空格选中VSZ和RSS两列→按q返回主界面→按Shift+F将排序依据设为VSZ→按Enter确认。
此时列表按虚拟内存从高到低排列，手动扫视RSS列：若某进程VSZ显示为“2.1g”而RSS仅“124m”，即为典型目标。不要依赖%MEM列，它只反映RSS占比，对虚存无感。
找到后记下PID，立即执行cat /proc/[PID]/status | grep -E "^(VmSize|VmRSS|VmData):"验证——VmSize对应VSZ，VmRSS对应RSS，数据更权威。
排查Java进程的特殊虚存行为
方法一：用jps -l列出所有Java进程全限定类名，再逐个匹配ps结果中的comm字段，确认是否为JVM进程。
方法二：对疑似Java PID，执行jstat -gc [PID]，观察S0C/S1C/EC/OC等容量字段是否远大于U0/U1/EU/OU（已使用量）。若OC=2G但OU=32M，说明老年代堆已预分配但几乎未填充，属于典型的高VSZ低RSS场景。
【JVM启动参数中-Xms与-Xmx差异过大时（如-Xms256m -Xmx4g），会直接导致VSZ飙升而RSS缓慢增长】。此时调整-Xms至合理值可立竿见影降低虚存压力。
检查mmap大文件映射残留
第一步：执行ls -l /proc/*/maps 2>/dev/null | awk '{if($5>100000000) print $0}' | head -5，快速找出映射区域超过100MB的进程maps文件路径。
第二步：取其中一个路径，例如/proc/7890/maps，执行sudo grep -E "^[0-9a-f]+-[0-9a-f]+.*r.*p.*\[.*\]$" /proc/7890/maps | head -3，筛选出只读私有映射段（常见于大资源文件预加载）。
第三步：用readlink /proc/7890/exe确认进程身份，再结合lsof -p 7890查看其打开的文件——若发现映射了/var/lib/myapp/data.bin（2.3GB）但RSS仅18MB，即可断定是mmap未触发缺页所致。
