Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Best way to automate tracking of a memory leak

Options
  • 07-04-2016 8:36pm
    #1
    guylikeme
    Registered Users Posts: 262 ✭✭


    So we have this resource usage data that is in charts. Spikes of usage are fine so long as we return to something approaching normal. So a simple view of the chart by the human eye will spot a resource leak.

    Is there a mathematical way of checking where we have a sustained leak (with a view to automating check).


Comments

  • Options
    #2
    Giblet
    Registered Users Posts: 11,977 ✭✭✭✭Giblet


    Performance counters? what OS are you running on, there are tools for automatically doing a memory dump when certain criteria are met.

    You need to track samples over time and make a call as to the nature of the graph over time. You can't "prove" a memory leak without context, you could be undergoing a large data operation for several hours which uses a lot of memory, but if the minimum memory commit over time is not reducing, you likely have a leak.


  • Options
    #3
    Colonel Panic
    Registered Users Posts: 2,019 ✭✭✭Colonel Panic


    Valgrind or something like it.


  • Options
    #4
    14ned
    Registered Users Posts: 768 ✭✭✭14ned


    The cheap on dev time way is to buy in one of the big memory debugging tools like AQTime. Pricey on the cash though.

    The expensive on dev time way is to roll your own solution using valgrind, Dr. Memory or one of the other free tools. You get a far better selection of free tooling on POSIX than Windows.

    Finally, there is nothing like as great a test for how bad your software is than to expose it to OOM by iterating launching LXC containers with just too little RAM and watching your software die in so many unexpected ways. The number of employers who allow you the time to fix those sorts of bug are very few indeed.

    Niall


Advertisement