内存泄漏导致服务器卡顿的核心表现是内存占用持续攀升、可用内存不断减少，最终触发频繁swap、响应延迟甚至服务中断；处理关键在于快速定位泄漏源、判断用户态或内核态泄漏层级，并采取匹配干预手段。
内存泄漏导致的服务器卡顿，核心表现是内存占用持续攀升、可用内存不断减少，最终触发频繁 swap、响应延迟甚至服务中断。处理关键不在于“立刻杀进程”，而在于快速定位泄漏源、判断泄漏层级（用户态 or 内核态）、采取匹配的干预手段。
一、确认是否真是内存泄漏
先排除误判：运行 free -h 查看 available 值是否长期低于 500MB；再用 top -c 观察 %MEM 列，看是否有单个进程内存占用随时间稳定上升（非偶发高峰）；同时注意 wa（I/O 等待）是否超过 25%，若高 wa + 低 available + kswapd0 占用高 CPU，基本可锁定为内存压力引发的连锁卡顿。
二、快速定位泄漏进程（用户态为主）
对 Linux 服务器，优先使用轻量级组合命令：
- ps aux --sort=-%mem | head -10：列出内存占用 Top 10 进程，重点关注非系统进程（如 java、node、zabbix_server、custom_app）
- pmap -x [PID] | sort -k3 -n -r | head -5：分析该进程内存分布，若 [anon] 匿名映射区远超其他段（如占 RSS 80%+），高度提示 C 层或 JVM 堆外内存泄漏
- cat /proc/[PID]/status | grep VmRSS：验证实际物理内存占用是否与 top 一致，排除缓存干扰
三、区分泄漏层级并处置
根据现象选择路径：
- 用户进程泄漏（如 Java、Zabbix、自研服务）：检查其日志是否有 “OutOfMemoryError”、“queue growing”、“GC overhead limit exceeded” 等线索；启用对应诊断工具（如 Zabbix 用 valgrind，Java 用 jstat -gc 或 MAT 分析 heap dump）；临时缓解可重启服务或限制其内存上限（cgroup 或 ulimit）
- 内核级泄漏（如 auditd、显卡驱动、文件系统模块）：运行 cat /proc/meminfo | grep -i "nonpag\|slab"，若 NonPagedPool 或 SReclaimable 异常高且不回落，需检查内核模块（lsmod）、回退驱动、禁用可疑服务（如 auditd、SysMain）
四、避免二次恶化的小动作
在定位过程中防止系统彻底僵死：
- 手动释放页缓存（仅限测试/紧急）：echo 1 > /proc/sys/vm/drop_caches（不会影响应用数据，但会清空 file cache）
- 临时关闭 swap 减少 IO 拖累：swapoff -a（需确保 available 内存足够，否则可能 OOM）
- 限制新进程内存分配：echo 'vm.overcommit_memory=2' >> /etc/sysctl.conf && sysctl -p，防止系统因过度承诺内存而崩溃
