尽管请求率在 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/机器也需要进行升级以及为其他应用程序提供服务。
如果这种情况持续几个小时以上，我们将收集证据并索回费用——我建议其他人也这样做，记住……谷歌以系统可靠性为荣这是当务之急。