Postgres データベースにアクセスするアプリケーションに対して負荷テストを実行しています。
テスト中に、突然エラー率が増加しました。プラットフォームとアプリケーションの動作を分析すると、次のことがわかります。
- Postgres RDS の CPU が 100% です
- 同じサーバー上で解放可能なメモリが減少
そして、postgres ログには次のように表示されます。
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: サーバープロセス (PID XXXX) がシグナル 9 によって終了しました: 強制終了
調査してドキュメントを読んだ結果、Linux oomkiller の実行によってプロセスが強制終了された可能性が 1 つあるようです。
しかし、RDS 上にあるため、システム ログ /var/log メッセージにアクセスして確認することはできません。
誰かがそうすることができます:
- oom killer が AWS RDS for Postgres 上で実際に動作することを確認する
- これを確認する方法はありますか？
- 接続数に基づいて Postgres が使用する最大メモリを計算する方法はありますか?
ここでは答えが見つかりませんでした:
答え1
OOM キラーが動作しなかったとしても (おそらく動作したでしょう)、CPU 使用率が 100% のままで空きメモリが非常に少ないと、パフォーマンスが低下します。
より大きなインスタンス サイズを使用して、問題が解決するかどうかを確認します。制御している非 RDS Postgres でより小さいサイズをテストし、OOM キラーが怒るかどうかを確認します。
接続数は必ずしもメモリ消費の主な要因ではありません。共有メモリは他の用途に使用され、すべてのクエリが大量のメモリを使用するわけではありません。次の会話も参照してください。PostgreSqlは接続ごとにメモリを割り当てます。
追加のアドバイスAmazon RDS のベストプラクティス
DBインスタンスのRAMの推奨事項
Amazon RDS のパフォーマンスのベストプラクティスは、ワーキングセットがほぼ完全にメモリ内に存在するように十分な RAM を割り当てることです。ワーキングセットがほぼすべてメモリ内にあるかどうかを確認するには、DB インスタンスに負荷がかかっているときに ReadIOPS メトリクス (Amazon CloudWatch を使用) を確認します。ReadIOPS の値は小さく安定している必要があります。DB インスタンスクラスをスケールアップして、より多くの RAM を持つクラスにすると、ReadIOPS が大幅に低下する場合、ワーキングセットはほぼ完全にメモリ内にあったわけではありません。スケーリング操作後に ReadIOPS が大幅に低下しなくなるまで、または ReadIOPS が非常に小さな量に減少するまで、スケールアップを続けます。
パフォーマンス指標の評価
解放可能なメモリ – DB インスタンスで使用可能な RAM の量 (メガバイト単位)。[モニタリング] タブのメトリクスの赤い線は、CPU、メモリ、ストレージ メトリクスの 75% でマークされています。インスタンスのメモリ消費量が頻繁にその線を超える場合は、ワークロードを確認するか、インスタンスをアップグレードする必要があることを示しています。
答え2
私は Postgres の経験があまりありませんが、同じ状況で、RDS MySql インスタンスが完全に再起動する傾向があることがわかりました。基盤となるシステムにアクセスできない場合でも、Web コンソールから Postgres ログを取得できるはずです。再起動を探すと、デーモンが終了して起動していることを示すはずです。
とにかく、危険ゾーンで作業している場合、できることはあまりありません。より多くの RAM / CPU が利用可能なインスタンスに移動する必要があります。