Als ik de uitvoer van je top correct lees, wordt deze niet genomen op een moment dat je geen geheugen meer hebt.
De eigenlijke fout lijkt in orde - het vraagt niet om een enorme hoeveelheid geheugen, dus vermoedelijk had de machine op dat moment onvoldoende geheugen.
Laten we even naar je instellingen kijken:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Dus - u bent van mening dat u 1000 gelijktijdige query's kunt ondersteunen, elk met bijvoorbeeld 10 + 40 MB (sommige gebruiken misschien veelvouden van 40 MB, maar laten we redelijk zijn). Dus - dit suggereert voor mij dat uw machine> 500 kernen heeft en 100 GB RAM heeft. Dat is niet het geval.
Dus - neem je aantal cores en verdubbel het - dat is een redelijke waarde voor het maximale aantal verbindingen. Dat zal u één vraag op elke kern toestaan terwijl een andere op I/O wacht. Plaats dan indien nodig een verbindingspooler voor de DB (pgbouncer / Java's verbindingspooling).
Dan zou je zelfs kunnen overwegen om work_mem te verhogen als dat nodig is.
Oh - volkomen redelijk om te draaien zonder swap ingeschakeld. Als je eenmaal begint met swappen, zit je sowieso in een wereld van pijn wat betreft databasegebruik.
Bewerken:uitbreiden op work_mem vs shared
Raadpleeg bij twijfel altijd de documentatie .
De shared_buffers waarde wordt, zoals de naam al doet vermoeden, gedeeld tussen backends. De work_mem is niet alleen per backend, het is eigenlijk per soort. Dus - één zoekopdracht kan drie of vier keer zoveel gebruiken als het sorteert op drie subquery's.