none
PerfView finalization handles RRS feed

  • Question

  • I'm looking into a memory issue we have with a wcf application and I'm using perfview to dig into the memory. We got a base snapshot and then a snapshot of when the memory is high. I diffed them and looking at the data I see unreached memory at 2,921MB and the top item on the list is finalization handles on devarts oracle connection object. My understanding is that the unreached memory means it's ready to be GC'd. I know we invoke the oracle connections dispose method and we do a gc.suppressfinalizer.  

    What would cause the GC to not collect the unreached memory? 

    


    Dan



    • Edited by dhoenig Wednesday, February 15, 2017 8:05 PM
    Wednesday, February 15, 2017 7:55 PM

Answers

  • Hi Dan,

    Here is a good reply from Wyck.

    >>What would cause the GC to not collect the unreached memory? 

    unreachable is what happens to an object or memory block when there are no more references to it.  The garbage collector loves to collect unreachable memory.  But the garbage collector likes to be lazy though too, so consecutive dumps might reveal that the garbage collector didn't make an effort to collect some unreachable memory between your two dumps.

    So it's normal.  This is an intermediate state that memory has after you release all the references but before it is garbage collected and eventually doled out by the allocator again in the future.

    For more details, please refer to https://social.msdn.microsoft.com/Forums/vstudio/en-US/47c7df80-3d50-407c-b58c-be3278f9fda4/perfview-unreachable-memory?forum=clr

    You also will get more knowledge about Unreachable memory from wiki.

    Best regards,

    Kristin


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Proposed as answer by Kristin Xie Wednesday, February 22, 2017 1:37 AM
    • Marked as answer by dhoenig Wednesday, February 22, 2017 10:42 PM
    Thursday, February 16, 2017 7:05 AM

All replies

  • Hi Dan,

    Here is a good reply from Wyck.

    >>What would cause the GC to not collect the unreached memory? 

    unreachable is what happens to an object or memory block when there are no more references to it.  The garbage collector loves to collect unreachable memory.  But the garbage collector likes to be lazy though too, so consecutive dumps might reveal that the garbage collector didn't make an effort to collect some unreachable memory between your two dumps.

    So it's normal.  This is an intermediate state that memory has after you release all the references but before it is garbage collected and eventually doled out by the allocator again in the future.

    For more details, please refer to https://social.msdn.microsoft.com/Forums/vstudio/en-US/47c7df80-3d50-407c-b58c-be3278f9fda4/perfview-unreachable-memory?forum=clr

    You also will get more knowledge about Unreachable memory from wiki.

    Best regards,

    Kristin


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Proposed as answer by Kristin Xie Wednesday, February 22, 2017 1:37 AM
    • Marked as answer by dhoenig Wednesday, February 22, 2017 10:42 PM
    Thursday, February 16, 2017 7:05 AM
  • Kristin,

    Thanks for the reply. I have read that article so we removed the server from the load balancer so it doesn't take as much traffic and the unreachable memory continues to climb. I was hoping the GC would clean up the unreachable memory, but it's been 16 hours and that has not happened. So either we have coded something wrong, or the GC is lazier than anyone ever imagined. (I'm guessing we coded something wrong :) 

    Thanks,

    Dan



    Dan

    Thursday, February 16, 2017 2:00 PM
  • Kristin,

    Thanks for the reply. I have read that article so we removed the server from the load balancer so it doesn't take as much traffic and the unreachable memory continues to climb. I was hoping the GC would clean up the unreachable memory, but it's been 16 hours and that has not happened. So either we have coded something wrong, or the GC is lazier than anyone ever imagined. (I'm guessing we coded something wrong :) 

    Thanks,

    Dan



    Dan

    @Dan,

    I am afraid that based on your scenario, it is hard to say where the issue is.

    But I am agree with your guess :)

    Have a nice day!

    Kristin


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, February 17, 2017 6:39 AM
  • Kristen,

    I've been doing some more digging and the unreachable memory turns out to be object waiting to be finalized. I posted another question in this forum about why the finalizer thread isn't running. So, you did answer my question accurately for this post when it comes to the unreachable memory. Generally this memory would be cleaned up, but in our case the issue goes deeper.

    Here's my other question I posted

     


    Dan

    Wednesday, February 22, 2017 10:41 PM