Garage Monitor Memory Leak: Part 3

Note: this is part 3 of a series. You can see all of the articles I have written on my Garage Monitor here.

A Possible Solution

OK, so after going down the route of debugging and tracing, I realized I had no idea what I was looking for. So I started thinking about what I should be doing to cleanup. I realized that I wasn’t freeing the memory of the objects that I was using in the functions. So, I started trying to figure out how to do that.

Memory Readings

So after making some modifications, I have been randomly taking readings by running the free command. Over the last 2-3 hours the free memory is staying quite stable. In fact for a couple of the readings the free memory actually goes up: 349816, 349824, 349576, 349700, 349584, 349576, 349584! 🙂

Attempting To Releasing The Objects

I tried using the del command to release objects created in some of the functions. For example, in ‘sendUpdate()‘ I added the following to the end of the function.

# Free the objects from memory.
del response
del conn
del params
del headers
del data

In addition to trying to free the objects (response, conn, params, headers), I thought I might as well try to cleanup the local variables (like data) as well.

Final Thoughts

I am not sure if I am going about this in the best way, but the results are spectacular so far. If anyone has any other recommendations, or even wants to tell me how what I did was technically wrong, let me know. I am new to Python and honestly haven’t done serious programming in 6 years, so I know I have a lot to learn.

Abbreviated “free” Terminal Output

total       used       free     shared    buffers     cached
448996      99180     349816          0      13328      40892
448996      99172     349824          0      13328      40900
448996      99420     349576          0      13388      40912
448996      99296     349700          0      13396      40912
448996      99412     349584          0      13424      40916
448996      99420     349576          0      13464      40916
448996      99412     349584          0      13472      40916

2 thoughts on “Garage Monitor Memory Leak: Part 3”

  1. I thought I had a similar issue so I added the Del commands to my URLLIB2 code. It didn’t help. In the end I ran my code redirecting the standard output and errors to a text file. What I found was that I had some bugs in my script logic. Once I eliminated those and correctly handled the odd URLLIB2 timeout my crashes disappeared. My free memory still drops to about 50MB but the system is stable. So my crashes were due to bugs … and the dropping memory was a bit of a red herring. I think it is simply the system managing memory. If anything needed the memory it would probably be freed up by the OS. Fingers crossed by my system has stayed up for 10+ days now!

Leave a Reply