利用S_MEMORY_INSPECTOR分析内存泄漏问题
【摘要】 我在批量生成service order时，report运行几个小时后，遇到out of memory exception:SM04里发现我的report随着时间的推移，消耗的内存越来越多：如何找到出现memory leak的代码的准确位置？我的report里有个package size，类似于OPEN CURSOR和FETCH的design，比如package size是1000，那么每10...
我在批量生成service order时，report运行几个小时后，遇到out of memory exception:
SM04里发现我的report随着时间的推移，消耗的内存越来越多：
如何找到出现memory leak的代码的准确位置？
我的report里有个package size，类似于OPEN CURSOR和FETCH的design，比如package size是1000，那么每1000个service order创建成功后，清一次buffer，然后创建第二批1000个order，再清第二次buffer.
所以我只需要在两次清buffer之后分别创建一个memory snapshot:
创建好之后tcode S_MEMORY_INSPECTOR, 比较两个snapshot里的delta部分，即为引起memory leak的变量。这个transaction列出了变量所在的program name，剩下的事情就是去找能清除这些变量对应的API.
修改完之后成效显著，修改之前一个user session跑一个小时内存consumtpion就超过了7GB，现在跑了一下午，每个session不超过2GB了。
我需要估一个在Sandbox system里创建10万个material大概需要花费多少时间。
我的做法就是把创建1个，10个，20个，。。。100个material的时间分别测出来：
Excel里做一个line regression analysis, 得出R2 = 0.9984 > 0.99, 得出时间和material数量在这有限的10组测试数据表现为线性相关，
所以10万个material的时间按照公式算出是 4.9个小时。当然实际时间可能会有出入。
最后的结果：
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）