記憶體使用是 Google App Engine 上實例流失的主要原因嗎？
儘管請求速率在 2.4k RPS 下穩定了 2 小時，但我每 30 分鐘經歷一次實例計數的急劇下降和峰值。在多個實例同時關閉後，週期性地會有很多預熱請求。由於大量的空閒實例，這也增加了我們的運營成本。
- App Engine 版本：1.8.1
- 實例總數：總共 235 個（15 個居民）
- 平均 QPS：9.143
- 平均延遲：135.5 毫秒
- 平均記憶體：157.9 MB
應用程序的性能設置仍為預設值（F1 實例、最小/最大掛起延遲和最小/最大空閒實例仍為自動）。
我將很快在 F2 實例上重新執行相同的測試。同時：
- 這是 GAE 上的一個已知問題嗎？
- 這是由於F1的記憶體消耗太高造成的嗎？
- 除了去 F2s，我還能做些什麼來解決這個問題？
- 使用 F1 實例的平均記憶體如何超過 128 MB？
實例數$$ F1 $$
RPS$$ F1 $$
以 MB 為單位的總記憶體使用量$$ F1 $$
在 F2 實例上執行測試後更新
在測試實例的前 2 小時內，客戶流失顯著減少。實例計數明顯更加穩定。在測試的最後 2 小時，儘管請求速率穩定在 2.4k RPS，但實例數從 250 增加到 600。
實例數$$ F1 vs F2 $$
RPS$$ F1 vs F2 $$
以 MB 為單位的總記憶體使用量$$ F1 vs F2 $$
每個請求的毫秒數$$ F1 vs F2 $$
這些資訊部分來自與 Google 的交談以及我自己的經驗，我不是 Google 員工。
我發現Google的前端記憶體要求是模糊的目標，通常不是硬限制，因為大多數應用程序可能會超過它，這會導致大多數使用者不斷的 GC。我發現他們的實際限制大約是 170MB，然後實例通常會面臨被悄悄關閉的風險（我注意到這偶爾會達到 200MB 左右，所以我假設他們有一個週期性的後台實例收割執行緒來完成這項工作 - 這是假設的我沒有證據表明正在這樣做）。如果一個實例看起來記憶體不足並且我擁有伺服器，我知道我會考慮終止該程序。
我會檢查您的大多數實例實際使用了多少記憶體，因為這可能是導致實例被集體殺死的原因。
使用 F2 時，您的伺服器能夠以兩倍於 F1 的速度啟動和處理請求，從而導致實例更少，並且由於記憶體上限更高，被殺死的機會更少（我再次認為這似乎與我執行多個企業級應用程序）。
另請注意，Google 目前正在推出（或 RC 測試？！！）從 GAE 1.8.1 到 1.8.2 的伺服器更新，這可能會影響像我們這樣的應用程序，這就是我找到您的文章的原因，我們’看到隨機的 memcache 和 5-20 秒的響應延遲返回完全前端 memcached 響應，通常會在 <10 毫秒內完成（網路延遲<80ms）。在此推出期間，不要忘記每個 VM/機器執行實例也需要進行升級以及為其他應用程序提供服務。
如果這種情況持續超過幾個小時，我們將收集證據並收回成本 - 我建議其他人也這樣做，請記住…… Google 以系統可靠性為榮，這是重中之重。