有同事报他的机器上 nginx 存在内存泄露，都吃了 4G 内存没法忍了，于是赶紧查一查。

问题定位

1、先 top -u work 查看进程内存占用情况，确认确实是占了 4G 没法忍了（下图只是整理文档时补的示例）。

2、ps -ef | grep nginx | grep -v grep | grep work
查看 nginx 进程确认是业务的 nginx 的某个 worker 子进程疑似存在内存泄露占了大量内存。

3、发现只有部分 worker 进程占用内容很大，并不是全部。cat error.log 定位为什么不是 worker 进程都内存增大，只是个别 worker 进程内存占用很大？

4、发现并不是那个子进程没有内存泄露，而是那个子进程频繁被 kill，然后 master 又重启新的子进程。
通过：dmesg | grep pid ，查看系统日志。确认那些内存占用低的 worker 进程是被 oom kill 了，然后被 master 又重启新的子进程。

5、确定是指定进程内存泄露后，查看该进程的内存分配，定位泄露信息。
①.通过 pmap -x pid dump 出该进程的内存分配，确认确实存在超大块内存分配。

②.通过 cat /proc/pid/smaps 查看内存段的具体起始位置。

③.通过 gdb dump 出那段内存存储内容。
gdb -p 42102
dump binary memory ./memory2.log 0x7fa1d0b57000 0x7FA1D0B70000

④.查看 dump 出的内容，发现是一个业务研发的 nginx 扩展存储的内容，确认是该扩展错在内容泄露。

6、问题明确后，具体修复问题就简单了，对应扩展修复问题后重新上线完成修复。

Linux 进程内存分析常用工具命令

top：查看机器整体内存使用情况和各进程内存使用情况
RES：常驻内存，一般比较关心这个
SHR：共享内存
VIRT：虚拟内存
DATA：数据占用内存
pmap：pmap -x pid dump 进程的内存分配情况
mtrace：可以跟踪记录进程的内存分配
gdb -p pid：连接到进程
cat /proc/pid/smaps：查看内存块具体开始结束位置
dump binary memory ./out.log 0x7fa1d0b57000 0x7FA1D0B70000 ：dump 出指定位置存储的内容

参考：https://javawind.net/p131
参考：https://www.jianshu.com/p/d9e12b66096a