![内存使用量是 Google App Engine 实例流失的主要原因吗?](https://linux22.com/image/802744/%E5%86%85%E5%AD%98%E4%BD%BF%E7%94%A8%E9%87%8F%E6%98%AF%20Google%20App%20Engine%20%E5%AE%9E%E4%BE%8B%E6%B5%81%E5%A4%B1%E7%9A%84%E4%B8%BB%E8%A6%81%E5%8E%9F%E5%9B%A0%E5%90%97%EF%BC%9F.png)
尽管请求率在 2 小时内一直稳定在 2.4k RPS,但每 30 分钟我都会经历实例数的急剧下降和激增。许多实例同时关闭后,周期性地会出现大量预热请求。由于大量空闲实例,这也增加了我们的运营成本。
- App Engine 版本:1.8.1
- 实例总数:共 235 个(15 个常驻)
- 平均 QPS:9.143
- 平均延迟:135.5 毫秒
- 平均内存:157.9 MB
应用程序的性能设置仍为默认设置(F1 实例、最小/最大待处理延迟和最小/最大空闲实例仍为自动)。
我很快会在 F2 实例上重新运行相同的测试。与此同时:
- 这是 GAE 上的已知问题吗?
- 这是因为 F1s 的内存消耗太高导致的吗?
- 除了去 F2s 我还能做什么来解决这个问题?
- 使用F1实例如何使平均内存超过128MB?
实例计数 [F1]
远程控制 [F1]
总内存使用量(MB)[F1]
在 F2 实例上运行测试后更新
在测试的前 2 小时内,实例流失率显著降低。实例数量明显更加稳定。在测试的最后 2 小时内,尽管请求率稳定在 2.4k RPS,但实例数量从 250 增加到 600。
实例计数 [F1 与 F2]
RPS [F1 与 F2]
总内存使用量(MB)[F1 与 F2]
每个请求的毫秒数 [F1 与 F2]
答案1
这些信息部分来自与 Google 的交谈以及我自己的经验,我不是 Google 员工。
我发现 Google 的前端内存要求是模糊的目标,通常不是硬性限制,这会导致大多数用户不断进行 GC,因为大多数应用程序可能会超过该限制。我发现他们的实际限制大约是 170MB,超过这个限制,实例通常会面临被悄悄关闭的风险(我注意到这个限制有时会高达 200MB,所以我假设他们有一个定期的后台实例收割线程来执行这项工作 - 这是假设的,我没有证据表明他们正在这样做)。如果一个实例看起来内存耗尽,而我拥有该服务器,我知道我会考虑终止该进程。
我会检查大多数实例实际使用了多少内存,因为这可能是导致实例被大规模终止的原因。
当使用 F2 时,您的服务器能够以比 F1 快两倍的速度启动和处理请求,从而减少实例数量,并且由于内存上限更高,被杀死的可能性也更小(再次强调,我的观点似乎与我运行许多企业级应用程序的经验相符)。
还请注意,Google 目前正在推出(或 RC 测试?!!)其服务器从 GAE 1.8.1 到 1.8.2 的更新,这可能会影响我们的应用程序,这也是我找到您的帖子的原因,我们发现随机 memcache 和响应延迟为 5-20 秒,返回完全前端 memcached 响应,而这通常会在不到 10 毫秒内完成(网络延迟不到 80 毫秒)。在此推出期间,请不要忘记运行实例的每个 VM/机器也需要进行升级以及为其他应用程序提供服务。
如果这种情况持续几个小时以上,我们将收集证据并索回费用——我建议其他人也这样做,记住……谷歌以系统可靠性为荣这是当务之急。