Se sto leggendo correttamente l'output del tuo top, non viene preso in un momento in cui hai esaurito la memoria.
L'errore reale sembra corretto:non sta richiedendo un'enorme quantità di memoria, quindi presumibilmente la macchina aveva esaurito la memoria a quel punto.
Diamo una rapida occhiata alle tue impostazioni:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Quindi - sei dell'opinione che puoi supportare 1000 query simultanee ciascuna usando diciamo 10 + 40 MB (alcuni potrebbero utilizzare multipli di 40 MB ma siamo ragionevoli). Quindi, questo mi sta suggerendo che la tua macchina ha> 500 core e diciamo 100 GB di RAM. Non è così.
Quindi - prendi il tuo numero di core e raddoppialo - questo è un valore ragionevole per il numero massimo di connessioni. Ciò ti consentirà una query su ciascun core mentre un altro è in attesa di I/O. Quindi, se necessario, posiziona un pool di connessioni davanti al DB (pgbouncer / pool di connessioni di Java).
Quindi, potresti anche considerare di aumentare work_mem, se necessario.
Oh - perfettamente ragionevole da eseguire senza lo scambio abilitato. Una volta che inizi a scambiare, sei comunque in un mondo di dolore per quanto riguarda l'utilizzo del database.
Modifica:espandi work_mem vs shared
In caso di dubbio, fare sempre riferimento a documentazione .
I shared_buffers il valore è, come suggerisce il nome, condiviso tra i backend. Il work_mem non è solo per back-end, è in realtà per tipo. Quindi, una query potrebbe utilizzare tre o quattro volte tale importo se esegue ordinamenti su tre sottoquery.
