Question

我在Solaris上运行了一个进程（SunOS m1001 5.10 sun4v sparc），并且正在监视所使用的总虚拟内存。

定期运行ps表明VSZ随着时间的推移呈线性增长，跳跃为80千字节，并且它一直在增长，直到达到4GB的限制，此时它已经超出了地址空间，事情开始分崩离析。 / p>

var html = $( ".container" ).html();
// a set missing here to convert 'bind' events to 'on' events
$( ".container" ).html( html );

我怀疑内存泄漏，并决定使用pmap进一步调查。但是pmap显示VSZ根本没有增长，而是保持稳定。此外，所有文件映射，共享内存映射和堆都保持相同的大小。

while true; do ps -ef -o pid,vsz,rss|grep 27435 ; sleep 5; done > ps.txt

我的第一个问题是：为什么ps和pmap会为同一个流程生成不同的VSZ？

我可以想象堆大小的计算方式不同（例如堆使用率与最高堆指针），因此开始考虑堆碎片的方向。然后我使用libumem和mdb在不同的时间生成有关分配内存的详细报告，并注意到分配的内存完全没有区别。

while true; do pmap -x 27435 |grep total; sleep 5; done > pmap.txt

所以我的第二个问题是：找出ps导致VSZ增长的最佳方法是什么。

Answer 1

我注意到这个问题仍然悬而未决，想补充一下这个故事的结局。

经过更多的挖掘，我联系了Solari的客户支持，并向他们发送了重现此问题的方法。他们确认内核中存在一个导致此问题的错误。

不幸的是，由于我离开了当时的公司，我无法确认他们是否发布了补丁。

Thx，杰夫

Answer 2

如果您使用LD_PRELOAD=libumem.so运行可疑流程，那么在＆＃34;它们全部崩溃的地方＆＃34;你可以用它来 - 然后使用诸如::findleaks -dv之类的umem dcmd在它上面运行mdb。

如果您查看pmap（1）输出中列出的所有映射，而不仅仅是流程的总计，那么您可以更好地了解要查看的位置。我要寻找的第一件事是堆，anon和堆栈段。