Python 前端和后端之间的内存使用情况差异很大（奇怪的是）

我的应用程序引擎应用程序内存泄漏问题。 我在查找问题的过程中记录内存使用情况

from google.appengine.api.runtime import memory_usage
memory_usage().current()

超出“128 MB的软私有内存限制”的函数位于延迟任务内。它每次的行为都应该相同。 我从控制台任务队列（后端）和前端通过get请求重新运行它。两个都在第6个日志之后获得异常

结果不同的是，我无法将我的头绕过去：

<Frontend-run>
1: 40.3515625
2: 50.3515625
3: 59.71875
4: 63.5234375
5: 72.49609375
6: 75.48046875

<Backend-run>
1: 98.83203125
2: 98.83203125
3: 98.83203125
4: 98.83203125
5: 98.83203125
6: 98.83203125

1: 40.3515625
2: 50.3515625
3: 59.71875
4: 63.5234375
5: 72.49609375
6: 75.48046875
1: 98.83203125
2: 98.83203125
3: 98.83203125
4: 98.83203125
5: 98.83203125
6: 98.83203125

我对结果有三个问题：

• 在开始时分配总内存池的三分之一对三分之二
• 后端使用两倍的内存（运行相同的功能）
• 后端内存使用不会像前端那样随时间增加

---

有人能为我理解这一点吗？

除了基于与它们处理的请求相关的实际活动而预期的内存使用之外，实例还具有可变的跨请求内存使用偏移量，例如包括：

• 语言（python）沙箱本身
• 在处理之前收到的请求时加载的其他python库（例如，后端可能加载延迟的库，而前端可能不加载）
• 垃圾收集器尚未清理的剩余物（它们最终应该会消失，但偶尔的活动峰值可能会导致超出限制，甚至实例死亡（并重新启动）-您会注意到，当使用量明显超过限制时，就会发生死亡，例如，我看到128M限制大于150MB）

按需加载库是提高实例启动时间的典型方法。这种技术会导致可能出现的内存泄漏，但并不一定意味着它真的是内存泄漏

还有一种可能是，128M对于一个应用程序来说根本不够（你会惊讶于实际需要多少，而128M并不是很多！），升级实例类型是前进的唯一途径。实际上，您现在可以尝试并监控使用情况-6个请求不足以建立一个模式-如果您升级，并且您看到内存使用情况最终趋于稳定，那么您可能需要升级。如果它没有稳定下来，那么很可能是内存泄漏