#Python free memory code#

So how do we take snapshot of memory and track memory allocations between API calls, it’s stateless.įor love of monkey-patching and the lack of time on Friday evening, this was the best I could come up with: Pass a query parameter in HTTP request which would take a snapshot. Perfect! Since it’s a flask app, it’s supposed to be stateless and there should not be permanent memory allocations between API calls (which was not the case here).

#Python free memory code#

You can also take snapshots at random point in code path and compare memory difference between those two points. Tracemalloc tracks memory allocations and point it to line/module where object was allocated with size. But they need to be installed separately and since 3.4 python comes bundling tracemalloc 2. There are number of python modules available which helps you do that. There was no other way but to track memory allocations.

So what? Heap dump does tell what is there on heap but it does not tell who put it there. So there are lot of tuples and longs (int objects) on the heap. With the basic knowledge of how python does memory management, we triggered explicit GC with each response sent back. To give bit more context on application which was leaking memory, it was a flask app with traffic mostly on one API endpoint with different parameters. Attaching some reference links as well for more details on how is memory management actually done. This is just an idea on how does python does memory management. So it memory was not given back to OS until a GC was triggered. If we also trigger a GC, it goes from 3.2G -> 0.13G. Look that by deleting, we are going from 3.2G -> 2.5G so still a lots of stuff(mostly int objects) lying around heap. We will see mem usage with and without GC. Here we are allocating list of ints and then explicitly deleting it.

It is cleared only when garbage collection of highest generation happens. The now free objects would go to something called freelist and would still stay on heap. It generally is not needed to know how is it done internally but when your workers are dying, you gotta know.Īpparently, when certain primitive types of object goes out of scope or you delete it explicitly with del, the memory is not released back to OS and it would still be accounted for the python process. Python does memory management on its own and it’s completely abstracted from user. I gave a talk at P圜on 2019 on the same subject, if you prefer detailed explanation in video format, checkout P圜on19 India: Let’s Hunt a Memory Leak or just scroll down to the bottom of the page. Until we decided to implement cache warmer which would be generating significant traffic and there it goes, uWSGI processes getting killed by OOM Killer! Update: Although it had cgroup memory usage limit, it had some room to grow and the leak never appeared. It never had huge surge of traffic and there would be multiple deployments over week. The flask app we had to debug had same characteristics. And there could be multiple reasons behind it. In production, a memory leak will not always bubble up.