跟踪未出现在内存分析器中的python内存泄漏

Question

背景：我有一个使用aiortc库发送和接收音频的python，它通常运行良好(考虑到我不是一个软件开发人员，这是令人印象深刻的)。但是，我注意到，经过几天的时间，这个脚本的内存使用量会慢慢膨胀，以填充主机服务器上的所有可用内存。只有在音频RTC流运行时才会发生这种情况，这排除了代码的其他部分，并导致我只关注aiortc库本身。

有趣的是，通常推荐的python内存工具tracemalloc & muppy在任何地方都不会显示这么大的内存使用量--当通过htop查看的脚本使用超过7GB时，它们可以找到的内存中最大的项通常只有几MB。来自muppy的示例输出

                       types |   # objects |   total size
============================ | =========== | ============
                         str |       40749 |      6.00 MB
                        dict |       13615 |      4.83 MB
                        code |       12379 |      2.15 MB
                       tuple |       30681 |      1.91 MB
                        type |        2014 |      1.77 MB
                         set |         895 |    570.29 KB
                        list |        2457 |    526.35 KB
                 abc.ABCMeta |         363 |    392.88 KB
                     weakref |        4387 |    308.46 KB
  builtin_function_or_method |        4252 |    298.97 KB
                         int |        6281 |    174.71 KB
          wrapper_descriptor |        2461 |    173.04 KB
           getset_descriptor |        2432 |    152.00 KB
       tracemalloc.Statistic |        2337 |    127.80 KB
                   frozenset |         419 |    124.13 KB

这使我相信泄漏的来源是aiortc库调用的非python库中较低级别的东西。我不是唯一一个向图书馆报告内存泄漏问题的人，但到目前为止，还没有人想出任何冒烟的武器。

我很好奇，当正常的python内存分析工具不起作用时，建议采取什么行动来进一步挖掘我所看到的内存使用问题。是否有较低级别的python内存分析技巧，还是需要深入研究外部内存分析工具？

Answer 1

也许jemalloc值得一试？