Python函数计算内存配置需平衡OOM风险与资源浪费：512MB为阿里云FC性价比拐点，应依冷启动峰值内存上浮20%设定，并避免全局初始化、注意实例复用内存残留。
内存设置多少才不会触发 OOM 或浪费资源
Python 函数计算（如阿里云 FC、腾讯云 SCF）的内存配置不是越大越好，它直接绑定 CPU 配额和计费，且实际可用内存受 runtime 初始化开销挤压。设 1024MB 不等于你能用满 1024MB —— Python 启动后，import 大量包（比如 numpy、pandas）可能瞬间吃掉 300–500MB，留给业务逻辑的只剩一半。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 本地用
psutil.Process().memory_info().rss测冷启动峰值内存，再上浮 20% 作为函数内存配置下限 - 避免在全局作用域做 heavy 初始化：把
model = torch.load(...)移到 handler 内或加 lazy 加载锁 - 阿里云 FC 中，
512MB是性价比拐点——再小容易 OOM，再大单位成本上升快；2048MB以上对纯 Python 函数基本无性能增益（除非跑大模型推理） - 注意：内存调高会自动提升 CPU 配额，但 Python GIL 限制下，并发线程数不随内存线性增长，别指望靠堆内存解决 CPU 密集型瓶颈
超时时间设成 30 秒还是 300 秒？关键看阻塞类型
超时不是“越长越稳”，而是要匹配阻塞来源。函数卡住 29 秒后报 FunctionTimeoutError，和卡在 HTTP 请求里等 29 秒然后成功，完全是两回事。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 网络 I/O 类（HTTP、DB 查询）必须单独设客户端超时：
requests.get(url, timeout=8)，不能只依赖函数层超时 - 如果函数含
time.sleep(20)或同步文件读写，超时必须 > 实际耗时 + buffer（建议 +5 秒），否则一抖就失败 - 阿里云 FC 默认超时 60 秒，但很多用户误设为 300 秒——结果是失败请求拖满重试队列，下游服务被压垮
- 异步任务（如发消息到 MQ）建议用「快速返回 + 异步轮询」模式，函数本身超时控制在 15 秒内，避免长时占位
为什么增大内存后函数反而变慢了？
这不是错觉。当从 512MB 调到 2048MB，部分场景下冷启动时间可能增加 30%+，尤其用了 tensorflow 或 transformers 的函数——大内存触发更激进的预分配策略，runtime 初始化阶段 mmap 更多页，而 Python 解释器本身没并行初始化能力。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
FC_LOG_LEVEL=DEBUG开启日志，观察init duration和invoke duration分离定位：是 init 慢，还是 invoke 慢？ - init 慢 → 检查全局 import、模型加载、连接池创建；invoke 慢 → 看是否真需要更多 CPU（比如解压 1GB zip），否则降内存反而更快
- 腾讯云 SCF 的
memory_size和 CPU 是 1:1 绑定，但阿里云 FC 是非线性映射（1024MB≈ 0.5 核，3072MB≈ 1.5 核），别按比例硬换算
调优曲线不存在通用公式，只存在你代码的真实毛刺点
没有“1024MB + 90s”这种万能组合。你的 handler 里有没有 pd.read_csv() 读 GB 级 CSV？有没有 subprocess.run(['ffmpeg', ...])？有没有未关闭的 requests.Session() 导致连接堆积？这些细节决定曲线斜率。
最容易被忽略的是：函数实例复用时的内存残留。一次调用加载了缓存，下次调用以为“干净”，其实 dict 还在、sqlite3.Connection 没 close —— 看似内存够，实际越跑越卡，最后超时。这类问题不会报 OOM，只会默默变慢。
