AWS Lambda 函数需要超过 CloudWatch 中报告的最大内存

Question

我有一个 Lambda 函数，它从 SQS 队列中读取消息并将项目插入 Dynamo。起初，我有 512MB 的内存。在 cloud watch 中，它报告使用的最大内存约为 58MB。我假设我可以将内存降低到 128MB，并看到处理 SQS 消息的相同速率。然而，事实并非如此。事情明显放缓。谁能解释一下？

这是显示 512MB Lambda 的最大内存的云手表：

这是显示 128MB Lambda 的最大内存的云手表：

在这里你可以看到 Dynamo 表的容量真的下降了

在这里，您可以看到正在处理的消息数量确实变慢了，较低的斜率可以证明这一点

Answer 1

这似乎违反直觉，但有一个合乎逻辑的解释：

减少内存也会减少可用的 CPU 周期。您需要为 EC2 实例的固定部分资源的短期使用付费，该实例具有固定的 CPU 与内存比率。

问：如何将计算资源分配给 AWS Lambda 函数？

在 AWS Lambda 资源模型中，您可以为函数选择所需的内存量，并按比例分配 CPU 功率和其他资源。例如，选择 256MB 内存为您的 Lambda 函数分配的 CPU 功率大约是请求 128MB 内存的两倍，是选择 512MB 内存的一半。您可以从 128MB 到 1.5GB 以 64MB 为增量设置内存。

https://aws.amazon.com/lambda/faqs/

那么，我们所说的 CPU 容量是多少？

AWS Lambda 使用与通用 Amazon EC2 实例类型（例如 M3 类型）相同的比率分配与内存成比例的 CPU 功率。

http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction-function.html

我们可以推断。

在 M3 类中，无论实例大小如何，供应因素如下所示：

CPU = Xeon E5-2670 v2 (Ivy Bridge) × 8 cores
Relative Compute Performance = 26 ECU
Memory = 30 GiB

ECU 是一个 EC2（或可能是“弹性”或“等效”）计算单元，其中 1.0 ECU 大约相当于 1GHz Opteron 的计算能力。它是一个无量纲量，用于简化不同实例类型的相对 CPU 容量的比较。

所以供应比率如下所示：

8/30 Cores/GiB
26/30 ECU/GiB

所以在 512 MiB 内存时，您的 Lambda 函数的容器在这台机器上的份额将是...

8 ÷ 30 ÷ (1024/512) = 0.133 of 1 core (~13.3% CPU)
26 ÷ 30 ÷ (1024/512) = 0.433 ECU (~433 MHz equivalent)

在 128 MiB 时，只有大约 1/4。

这些数字看起来非常小，但它们并不适合典型的 Lambda 用例——非 CPU 密集型的单线程异步操作。