始终分配 CPU 的云运行比仅在请求处理期间分配更便宜。如何?

Posted

技术标签:

【中文标题】始终分配 CPU 的云运行比仅在请求处理期间分配更便宜。如何?【英文标题】:Cloud run with CPU always allocated is cheaper than only allocated during request processing. How? 【发布时间】:2022-01-16 22:10:06 【问题描述】:

我将 Cloud Run 用于我的应用,并尝试使用 GCP 定价计算器来预测成本。我不明白为什么总是分配 CPU 而不是在请求处理期间分配 CPU 更便宜,当它说“当您选择加入“始终分配 CPU”时,您需要为容器实例的整个生命周期付费。

有什么解释吗?

谢谢!

【问题讨论】:

请编辑问题以将其限制为具有足够详细信息的特定问题,以确定适当的答案。 【参考方案1】:

Cloud Run 默认情况下是无服务器的:按使用付费。当请求进来时,会创建一个实例(并启动它,这称为冷启动)并处理您的请求。计时器开始。当您的网络服务器发送答案时,计时器停止。

您为请求处理过程中使用的内存和 CPU 付费,四舍五入到上限 100 毫秒。实例继续存活大约 15 分钟(默认情况下,可以随时更改)以准备处理另一个请求,而无需启动另一个请求(并再次等待冷启动)。

如您所见,即使您不再付费,实例也会继续存在。因为只有在处理请求时您才需要付费。


当您将 CPU 设置为始终开启时,您需要为实例运行的全部时间付费。无论请求处理与否。 Google 不必为正在运行和未使用的实例付费,而是按照按使用付费模式等待请求。您为此付费,而且您支付的费用更少

这就像一个全职的 Compute Engine。作为 Compute Engine,您可以拥有类似于 sustained used discount 的内容。这就是它更便宜的原因。

【讨论】:

以上是关于始终分配 CPU 的云运行比仅在请求处理期间分配更便宜。如何?的主要内容,如果未能解决你的问题,请参考以下文章

linux单进程如何实现多核cpu多线程分配?

始终强制将内存分配到相同的虚拟地址[重复]

简单聊聊进程和线程

内存的分配方式

仅在分配的一部分上使用 cudaHostRegister 是不是安全?

在多处理中如何将 CPU 内核分配给 python 进程?