我在批量生成service order時，report運行幾個小時后，遇到out of memory exception:

SM04里發(fā)現(xiàn)我的report隨著時間的推移，消耗的內(nèi)存越來越多：

如何找到出現(xiàn)memory leak的代碼的準(zhǔn)確位置？
我的report里有個package size，類似于OPEN CURSOR和FETCH的design，比如package size是1000，那么每1000個service order創(chuàng)建成功后，清一次buffer，然后創(chuàng)建第二批1000個order，再清第二次buffer.
所以我只需要在兩次清buffer之后分別創(chuàng)建一個memory snapshot:

創(chuàng)建好之后tcode S_MEMORY_INSPECTOR, 比較兩個snapshot里的delta部分，即為引起memory leak的變量。這個transaction列出了變量所在的program name，剩下的事情就是去找能清除這些變量對應(yīng)的API.

修改完之后成效顯著，修改之前一個user session跑一個小時內(nèi)存consumtpion就超過了7GB，現(xiàn)在跑了一下午，每個session不超過2GB了。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的利用S_MEMORY_INSPECTOR分析内存泄漏问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。