brkstack

Book

Syscalls

Shows brk()   calls with user stack traces

显示带有用户堆栈跟踪的brk()调用

shmsnoop

BCC

Syscalls

Traces shared   memory calls with details

跟踪共享内存调用的详细信息

faults

Book

Faults

Shows page   faults, by user stack trace

通过用户堆栈跟踪显示页面错误

ffaults

Book

Faults

Shows page   faults, by filename

通过文件名显示页面错误

vmscan

Book

VM

Measures VM   scanner shrink and reclaim times

测量vm scaner的收缩和回收时间

drsnoop

BCC

VM

Traces direct   reclaim events, showing latency

跟踪直接回收事件，显示延迟

swapin

Book

VM

Shows swap-ins   by process

按进程显示swap情况

hfaults

Book

Faults

Shows huge   page faults, by process

按进程显示巨页错误情况

此外，还有几个用于内存分析的BPF工具： kmem 、kpages 、 slabratetop 、 numamove

oomkill

oomkill是一个BCC和bpftrace工具，用于跟踪内存不足杀手事件并打印详细信息(例如平均负载)。平均负载为OOM时的系统状态提供了一些额外的上下文，显示了系统是否正在变得忙碌或稳定。

此输出表明PID 18601(perl)需要内存，这触发了PID 1165(java)的OOM终止。PID 1165的内存占用已达到18006224个pages；这些通常每页4 KB，具体取决于处理器和进程内存设置。loadavg平均负载表明，在OOM终止时，系统变得更加繁忙。

该工具通过使用kprobes跟踪oom_kill_process() 函数并打印各种细节来工作。在这种情况下，只需读取/proc/loadavg即可获取平均负载。调试OOM事件时，可以根据需要增强此工具以打印其他详细信息。此外，此工具尚未使用可以显示有关如何选择任务的更多详细信息的oom跟踪点。

memleak

memleak是一个BCC工具，可跟踪内存分配和空闲事件以及分配堆栈跟踪。随着时间的流逝，它可以显示长期幸存者-尚未释放的分配。

此示例显示了在bash shell进程上运行的memleak：

 

仅memleak不能告诉您这些分配是否是真正的内存泄漏(内存泄漏:指的是没有引用并且永远不会释放的已分配内存)，内存增长还是长期分配。为了区分它们，需要研究和理解代码路径。

当然，还有很多内存分析的小工具。这里就不一一列举了。具体可以看brendangregg大佬的新书。