Google App Engine F1实例内存超限求助（无需升级F2）

这问题我维护GAE Python应用时也碰到过——F1的128MB内存限制确实苛刻，而且实例复用机制会让内存缓慢累积，单个请求看不出问题，但跑久了就会触发软限制。给你几个不用升级到F2的可行方案：

1. 强制清理NDB上下文缓存（最见效的第一步） #

NDB默认会把获取的实体存在上下文缓存里，哪怕请求结束，只要实例被复用，这些缓存就会留在内存里，gc.collect()根本管不到它。你需要在每个请求处理完成后主动清理NDB缓存：

from google.cloud import ndb

# 在请求处理的最后（比如Flask的after_request钩子，或WSGI的收尾逻辑）
ndb.get_context().clear_cache()

这个操作会直接清空NDB的实体缓存，比单纯gc有效得多——毕竟你单次get_multi的3MB实体，累积几次就够喝一壶了。

2. 拆分批量请求，降低内存峰值 #

虽然400个实体总大小才3MB，但如果你的请求逻辑里还有其他内存开销，叠加起来可能让实例内存持续走高。可以把ndb.get_multi()拆成多个小批量（比如每次100个），处理完一批就清理一次缓存，或者让每批实体的引用更快被回收：

# 原代码：一次拿400个
entities = ndb.get_multi(keys)

# 修改为分批处理
batch_size = 100
for i in range(0, len(keys), batch_size):
    batch_keys = keys[i:i+batch_size]
    batch_entities = ndb.get_multi(batch_keys)
    # 处理当前批次的实体
    process_batch(batch_entities)
    # 手动解除引用，帮助GC回收
    del batch_entities
# 最后再清一次全局缓存
ndb.get_context().clear_cache()

3. 调整实例复用策略，避免内存长期累积 #

低流量下，GAE可能会让一个实例长期存活（甚至几小时），内存慢慢泄漏。你可以在app.yaml里调整自动扩缩容参数，限制实例的存活时间或请求数：

runtime: python39
instance_class: F1
automatic_scaling:
  max_idle_instances: 0  # 空闲时立即回收实例，避免长期复用
  max_requests_per_instance: 50  # 每个实例处理50个请求后自动重启，重置内存

低流量下，50个请求可能要跑很久，重启实例不会影响用户体验，但能彻底解决内存累积问题。

4. 排查隐性内存泄漏 #

如果上面的方法都没用，那可能是代码里有隐性的内存泄漏：

• 检查全局变量：有没有在函数外定义的列表、字典，每次请求都往里面追加数据？比如全局的日志列表、缓存字典，实例复用后会越变越大。
• 用tracemalloc做内存快照分析：在请求前后记录内存状态，对比找出内存增长的来源：

import tracemalloc
import logging

def your_request_handler():
    tracemalloc.start()
    snapshot_before = tracemalloc.take_snapshot()
    
    # 你的业务逻辑代码
    # ...
    
    snapshot_after = tracemalloc.take_snapshot()
    top_stats = snapshot_after.compare_to(snapshot_before, 'lineno')
    logging.info("Top 5 memory growth sources:")
    for stat in top_stats[:5]:
        logging.info(stat)
    tracemalloc.stop()

查看GAE的日志，就能看到哪些代码行导致了内存增长，针对性修复。

5. 限制并发请求数（极端情况的应急方案） #

F1实例默认允许多个并发请求，如果你请求的内存开销叠加后容易超限，可以在app.yaml里设置单实例只处理一个请求：

automatic_scaling:
  max_concurrent_requests: 1

虽然会降低并发能力，但低流量下完全够用，能避免多个请求的内存开销叠加导致超限。

内容的提问来源于stack exchange，提问作者Federico Capello