Jika saya membaca output top Anda dengan benar, itu tidak diambil pada saat Anda kehabisan memori.
Kesalahan sebenarnya tampak baik-baik saja - itu tidak meminta sejumlah besar memori jadi mungkin mesin kehabisan memori pada saat itu.
Mari kita lihat sekilas setelan Anda:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Jadi - Anda berpendapat bahwa Anda dapat mendukung 1000 kueri bersamaan masing-masing menggunakan katakanlah 10 + 40MB (beberapa mungkin menggunakan kelipatan 40MB tetapi mari kita masuk akal). Jadi - ini menunjukkan kepada saya bahwa mesin Anda memiliki> 500 core dan katakanlah 100GB RAM. Bukan itu masalahnya.
Jadi - ambil jumlah inti Anda dan gandakan - itu nilai yang masuk akal untuk jumlah koneksi maksimal. Itu akan memungkinkan Anda satu kueri pada setiap inti sementara yang lain menunggu I/O. Kemudian, tempatkan connection pooler di depan DB jika perlu (pgbouncer / connection pooling Java).
Kemudian, Anda bahkan dapat mempertimbangkan untuk menambah work_mem jika perlu.
Oh - sangat masuk akal untuk dijalankan tanpa mengaktifkan swap. Setelah Anda mulai bertukar, Anda tetap berada di dunia yang menyakitkan sehubungan dengan penggunaan basis data.
Sunting:perluas di work_mem vs dibagikan
Jika ragu, selalu lihat dokumentasi .
shared_buffers value adalah, seperti namanya, dibagikan di antara backend. work_mem tidak hanya per backend, itu sebenarnya per sort. Jadi - satu kueri mungkin menggunakan tiga atau empat kali jumlah itu jika melakukan pengurutan pada tiga subkueri.
