Pythonのメモリ解放について

ループごとにメモリが溜まっていくことがわかっているのならロジックにメモリが解放されない部分が残っているということなので,まずは動かしているコードを検証すべきだと思います.

言語処理系の GC の一般的な動作としては

• 最初にメモリ使用量の閾値が設定されている
• メモリを新たに使おうとしたときに閾値を越えてしまうなら GC が発動する (使われていないメモリを探して回収する)
• GC を使ってもメモリが足りないなら閾値を大きくする

ということを繰り返します。 (実際にはこんな単純なことではなく色々な工夫があるのですがここではものすごく単純化しています。)

メモリ使用の総量が伸び続けているときは GC を使った上で回収できないメモリがあることを意味します。 なので gc.collect() を使って GC を明示的に起動しても無意味です。

メモリを回収できないということは不必要に参照が残っている箇所があるということですし、ロジックを精査してそういう箇所を見つけるしか仕方ないです。 ループの外から参照されているオブジェクト (配列や辞書) に追記している箇所があれば (回収できないので) 際限なくメモリ使用量が増えることになるでしょう。 そうしないように書き換える必要があります。

コード（あるいは模擬した）を提示してもらわないと何とも言えません。

どんな言語でもそうですが、GCが実装されている言語はどこかのタイミングでプログラムを停止してメモリを整理しています。
gc.collect()はそのキッカケを作るだけで根本的な解決をしません。

• インスタンスを毎回生成しててそれをどこかに保存している
• Dictの多用と保持

それらを見つけて地道に改善（delなりNone代入する or そもそも使用しない）する以外無いと思います。

<frozen importlib._bootstrap_external>:729: size=46.4 MiB, count=345817, average=141 B

これは importlib._bootstrap_external の729行目で確保されたメモリ量の合計です。 Python 3.11 系なら、ちょうどその行で .pyc ファイルのデータのアンマーシャリングをしているようです。つまりは import 文や importlib.import_module() でインポートされたモジュールのバイトコードと定数が占めるメモリ量を表します。

このメモリ量は実行中に増えることはあっても、普通は使うモジュール数に限りがある以上どこかで頭打ちになるはずです。（一度インポートしたモジュールはインメモリでキャッシュされるので、もう一度インポートしてもメモリ量は変わりません。）本当にループごとに際限なく増えているなら、ループごとに新しいソースファイルをインポートするという相当特殊な処理をしていることになります。一度インポートしたモジュールのメモリは解放できないので、インポートしないように処理を変えるしかありません。