How I Traced and Fixed a Python DICOM Server Memory Leak

After deploying a Python server to receive DICOM medical images, the author noticed severe memory consumption, with usage climbing to several gigabytes in production.

The process ID of the running server was identified (PID 21610) and memory profiling began.

Possible reasons for Python memory leaks were listed:

Objects referenced by long‑lived global variables.

Garbage collector disabled or set to debug mode, preventing memory release.

Self‑referencing objects with a custom __del__ method.

Several diagnostic tools were evaluated, including the built‑in gc module, objgraph, guppy, and pympler. Ultimately, two powerful utilities proved most effective: tracemalloc – a built‑in Python 3 module that shows which objects occupy the most memory and their allocation stack. pyrasite – a third‑party tool that can inject code into a running Python process and inspect its state.

Because tracemalloc required recompiling Python 2, the author chose pyrasite. After installing, the following command was used to view memory snapshots:

pyrasite-memory-viewer <pid>

The snapshot revealed thousands of DicomFileLike objects consuming the majority of memory.

Further investigation using gc.isenabled() confirmed the garbage collector was active, and gc.setdebug(gc.STATUS) plus gc.collect() showed no additional memory was freed, ruling out the second cause.

Inspecting gc.garbage displayed many DicomFileLike instances, indicating they were part of a reference cycle.

Using pyrasite-shell <pid> the author examined object references and discovered that the DicomFileLike class defined a custom __del__ method, preventing the cyclic garbage collector from reclaiming the objects. pyrasite-shell <pid> By monkey‑patching the class to remove the __del__ method, the memory leak was eliminated.

Additional handy tricks discovered during debugging included checking thread counts, dynamically locating objects by their id / address, and reviewing garbage collection logs.

In summary, the leak was caused by a self‑referencing DicomFileLike object with a custom destructor; removing the destructor resolved the issue, and tools like pyrasite and tracemalloc proved invaluable for diagnosing similar problems.