トップの出力を正しく読み取っている場合は、メモリが不足している時点では取得されません。
実際のエラーは問題ないようです。大量のメモリを要求していないため、おそらくその時点でマシンのメモリが不足していました。
設定を簡単に見てみましょう：
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
つまり、それぞれがたとえば10 + 40MBを使用して1000の同時クエリをサポートできるという意見です（40MBの倍数を使用する場合もありますが、合理的です）。つまり、これは、マシンに500コアを超え、100GBのRAMがあることを示唆しています。そうではありません。
つまり、コアの数を2倍にして、接続の最大数として妥当な値です。これにより、別のコアがI / Oを待機している間に、各コアで1つのクエリを実行できます。次に、必要に応じてDBの前に接続プールを配置します（pgbouncer / Javaの接続プール）。
次に、必要に応じてwork_memを増やすことを検討することもできます。
ああ-スワップを有効にせずに実行するのは完全に合理的です。交換を開始すると、データベースの使用に関してとにかく苦痛の世界にいます。
編集：work_memと共有を展開
疑わしい場合は、常にドキュメント 。
shared_buffers 名前が示すように、値はバックエンド間で共有されます。 work_mem バックエンドごとだけでなく、実際にはソートごとです。つまり、3つのサブクエリで並べ替えを行う場合、1つのクエリでその3倍または4倍の量が使用される可能性があります。