多くのメモリを消費するPostgresの子プロセス
かなり頑丈なマシン（96GのRAM/24コア）で実行されているpostgres9.0インスタンスがあります。ここ数週間、OOMkillerによってメモリ不足でpostgresの子プロセスが強制終了されるためにクラッシュが発生しました。接続プーリングを使用しているため、これらの子プロセスは長寿命であるようです（接続の開閉には時間がかかるため、これは理にかなっています）。問題は、メモリ消費量が徐々に増加し、9ギガ/プロセスに達することです。ご想像のとおり、これらを10個持つと、使用可能なRAMがいっぱいになり、oom-killerがキックインします。
質問は次のとおりです。
- デフォルトの設定パラメータを使用している場合、プロセスがこれほど多くのメモリを割り当てることができるのはなぜですか？
- これらのプロセスがメモリを解放しないのはなぜですか？
参考までに、メモリに影響を与える可能性のある設定：
max_connections = 950
shared_buffers = 32MB
他のすべての設定は上書きされません。つまり、デフォルトを使用しています。
最初に考慮すべきことは、shared_buffersを、少なくとも1GBまで、場合によってはそれ以上に、メインメモリの最大25％まで増やすことです。それは ドキュメントの内容 です。
わずか32MBで、そのうち〜18Mbはmax_connectionsから950に対処するためだけにすでに使用されており、子プロセスは何でも共有するのにかろうじて十分な共有メモリにアクセスできます。
これにより、特定のワークロードと状況でのメモリ消費の問題が軽減される場合と軽減されない場合がありますが、とにかくそれは正しい方向への一歩です。現在の値はめちゃくちゃ低いです。
特にOOMについては、ドキュメントの Linux Memory Overcommit セクションで提供されている回避策を検討することをお勧めします。ただし、これは複雑な問題の短い段落であることに注意してください。たとえば、 このブログ投稿 と、OOMの制限または無効化に関連するコンテキストとトレードオフを理解するためのポインタを含むコメントがあります。
それとは別に、Postgresでのメモリリークは常に発生する可能性があります。すでに修正されている場合に備えて、最新のマイナーバージョンを実行していることを確認する必要があります。各バグ修正リリースに付属するリリースノートには、メモリリークが時々記載されています。