I narrowed down the location of the memory leak that was found last week (alog47903).
The decorator, mentioned in previous alogs, was instantiating a LIGOBlendManger (LBM) object with every loop of the run method. Not great practice, I know, but it was much easier to create and maintain this way. When initializing a LBM object, it will set up some ezcaPVs, set up attributes to be called later, and set an ezca.ramp Ramp object that can be called to start the transitioning of the blend filters. The last one is where the leak has been narrowed to (lines 105-109 in (userapps)/isi/common/isiguardianlib/blend/ligoblend.py).
My theory: Somehow ezca is keeping a new record for each one of these Ramps created on each initialization, instead of the usual reference cycling.
To test this I ran bits of code in different ipython shell environments and watched htop to look at my local machine's memory. (Thanks Jonathan!) If you want to know more about what exactly I did, or are me in the future trying to remember, I attached a .py file of what I did and you can read each test case.
For the record, there's nothing at all inherently wrong with initializing a class within every loop. Whether or not that's problematic depends entirely upon what happens during the initialization. If the initialization is creating objects that are not being properly cleaned up then that may be an issue.