postgresqlの接続ごとのメモリリークの原因を見つけるにはどうすればよいですか？
Rails 4.2 with "prepared_statements：false"からの永続的な接続が1300のAmazon RDSでpostgresql 9.5.4を使用しています。何時間も何日もかけて、「Freeable Memory」RDS statは無制限に下がり続けますが、再接続するたびに比較的小さなワーキングセットに戻ります（サーバーを再起動します）。長すぎるとゼロになり、データベースインスタンスは実際に動き始めますスワップし、最終的に失敗します。再起動時のピークから数日間の空きメモリを差し引くと、平均して接続あたり10 MBのMBがあることがわかります。
強化された監視からPIDごとのRSSを掘り下げてみると、接続PIDの例では同じゆっくりとした増加が見られますが、RSSの合計は、接続ごとの実際のメモリ使用量のプロキシにすぎないようです（ https：//www.depesz。 com/2012/06/09/how-much-ram-is-postgresql-using / ）。
どうすればよいですか：
- 以下のdefault.postgres9.5パラメータを変更して、接続ごとの無制限のメモリ増加を回避します
- この無限の成長を引き起こすクエリを特定し、それを防ぐように変更します。
- 上記のいずれかを行うためにそれを使用できるように、この無限の成長を引き起こしているバッファリング/キャッシングのタイプを特定します
コミュニティPostgreSQLを使用していた場合、Linuxのメモリがどこにあるかを把握するための 明確な回答 は、gdbを使用して肥大化したバックエンドに接続し、p MemoryContextStats(TopMemoryContext)を実行してから、サーバーログファイルからの出力。しかし、コミュニティPostgreSQLを使用していないので、最も確実な答えは、有償サポートに連絡して、それを理解するように依頼することでしょう。
この最も可能性の高い原因は、PostgreSQLが接続の存続期間中にアクセスしたすべてのデータベースオブジェクト（テーブル、インデックスなど）に関するメタデータの接続ごとのキャッシュを保持していることです。このキャッシュが取得できるサイズに上限はなく、キャッシュを期限切れにするメカニズムもありません。したがって、これらのものが数十万または数百万あり、長命の接続が最終的にそれらのそれぞれに触れる場合、それらのメモリ使用量は継続的に増加します。これに対する通常の解決策（データベース内のオブジェクトの数を減らすことができない場合）は、各接続がリサイクルされるのではなくクローズされるまでの最大存続時間を持つように接続プーラーを設定することです。