我在批量生成service order时,report运行几个小时后,遇到out of memory exception:
![](https://img.haomeiwen.com/i2085791/bb8eded7456425a7.png)
![](https://img.haomeiwen.com/i2085791/75d836f69b55cbb9.png)
SM04里发现我的report随着时间的推移,消耗的内存越来越多:
![](https://img.haomeiwen.com/i2085791/0e04c1612b6a7ffa.png)
![](https://img.haomeiwen.com/i2085791/d33e6453031999cb.png)
![](https://img.haomeiwen.com/i2085791/aa887d9462fe7758.png)
如何找到出现memory leak的代码的准确位置?
我的report里有个package size,类似于OPEN CURSOR和FETCH的design,比如package size是1000,那么每1000个service order创建成功后,清一次buffer,然后创建第二批1000个order,再清第二次buffer.
所以我只需要在两次清buffer之后分别创建一个memory snapshot:
![](https://img.haomeiwen.com/i2085791/a09fe79bf82b0142.png)
创建好之后tcode S_MEMORY_INSPECTOR, 比较两个snapshot里的delta部分,即为引起memory leak的变量。这个transaction列出了变量所在的program name,剩下的事情就是去找能清除这些变量对应的API.
![](https://img.haomeiwen.com/i2085791/429a5cf089f2d4e4.png)
修改完之后成效显著,修改之前一个user session跑一个小时内存consumtpion就超过了7GB,现在跑了一下午,每个session不超过2GB了。
要获取更多Jerry的原创文章,请关注公众号"汪子熙":
![](https://img.haomeiwen.com/i2085791/fc7ecd97deb67090.png)
网友评论