Sourav, I apologize on behalf of the group for some of the “answers” (sic ...) that you have lately received here.   It is true that this is not a particularly well-designed program.   However, it may also be true that you did not write it and/or that there is no business justification for a rewrite, given that, as you say, it is doing a complex time-consuming thing and it works.   So, here are two specific tricks that I use in this kind of situation:

1. Spin off a subset of the work into a per-request child process, following more-or-less exactly the excellent example previously given.   The operating system will tear-down a process completely.   (Note that threads are not equivalent since all threads run in the context of a parent process.)   Each unit of work needs to be self-contained with basically no need to communicate or to maintain any kind of global-state betwixt them.
2. Parcel the primary unit or units of work into subroutines, and move as many variables as possible into local scope within those subroutines, parameterizing them as need be.   Studiously avoid globals.   The interpreter will clean-up the local variables of a subroutine, with a few caveats regarding memory-references and circular-references that I hope we will not need to get into here.

Both of these things – especially the first – are changes that can usually be wrapped-around “logic that works” with a reasonably small risk of de-stabilization.   Nevertheless, results should be aggressively (re-)tested.