我們正在針對存取 Postgres 資料庫的應用程式執行負載測試。
在測試過程中，我們突然發現錯誤率增加了。在分析平台和應用程式行為後，我們注意到：
- Postgres RDS的CPU為100%
- 同一台伺服器上的可用記憶體下降
在 postgres 日誌中，我們看到：
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: 伺服器程序 (PID XXXX) 被訊號 9 終止：已終止
經過調查和閱讀文件後，似乎一種可能性是 linux oomkiller 正在運行並殺死了該進程。
但由於我們使用的是 RDS，因此我們無法存取系統日誌 /var/log 訊息進行確認。
那麼有人可以：
- 確認 oom Killer 確實在適用於 Postgres 的 AWS RDS 上運行
- 給我們一個方法來檢查這個嗎？
- 給我們一種根據連接數計算 Postgres 使用的最大記憶體的方法嗎？
我在這裡沒有找到答案：
答案1
即使 OOM 殺手沒有採取行動（它可能採取了行動），持續 100% CPU 和非常低的可用記憶體也會對效能產生不利影響。
使用更大的實例大小並查看問題是否消失。在您控制的非 RDS Postgres 上測試較小的大小，看看 OOM 殺手是否會生氣。
連接數不一定是記憶體消耗的主導因素：共享記憶體用於其他用途，並且並非每個查詢都使用大塊記憶體。另請參閱這段對話：PostgreSql為每個連接分配內存。
額外的建議來自Amazon RDS 的最佳實踐
資料庫執行個體 RAM 建議
Amazon RDS 效能最佳實踐是分配足夠的 RAM，以便您的工作集幾乎完全駐留在記憶體中。若要判斷您的工作集是否幾乎全部位於記憶體中，請在資料庫執行個體處於負載狀態時檢查 ReadIOPS 指標（使用 Amazon CloudWatch）。 ReadIOPS 的值應該小且穩定。如果將資料庫執行個體類別擴展為具有更多 RAM 的類，會導致 ReadIOPS 急劇下降，則表示您的工作集幾乎沒有完全位於記憶體中。繼續擴展，直到擴展操作後 ReadIOPS 不再大幅下降，或者 ReadIOPS 減少到很小的量。
評估績效指標
可用記憶體 – 資料庫執行個體上有多少 RAM 可用（以兆位元組為單位）。 「監控」標籤指標中的紅線標示為 CPU、記憶體和儲存指標的 75%。如果實例記憶體消耗經常跨越該線，則表示您應該檢查您的工作負載或升級您的執行個體。
答案2
我對 Postgres 沒有太多經驗，但在同樣的情況下，我發現 RDS MySql 實例很容易完全重啟。即使您無法存取底層系統，您也應該能夠透過 Web 控制台取得 postgres 日誌。尋找重新啟動守護程序應表明它正在關閉並啟動。
無論如何，如果您在危險區域工作。你無能為力。您應該轉移到具有更多可用 RAM/CPU 的執行個體。