Hvis jeg læser outputtet fra din top korrekt, er det ikke taget på et tidspunkt, hvor du er løbet tør for hukommelse.
Den faktiske fejl ser ud til at være i orden - den kræver ikke en enorm mængde hukommelse, så formodentlig var maskinen løbet tør for hukommelse på det tidspunkt.
Lad os tage et hurtigt kig på dine indstillinger:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Så - du er af den opfattelse, at du kan understøtte 1000 samtidige forespørgsler hver ved at bruge f.eks. 10 + 40 MB (nogle bruger måske multipla af 40 MB, men lad os være fornuftige). Så - dette tyder på mig, at din maskine har> 500 kerner og sige 100 GB RAM. Det er ikke tilfældet.
Så - tag dit antal kerner og fordoble det - det er en rimelig værdi for det maksimale antal forbindelser. Det vil tillade dig én forespørgsel på hver kerne, mens en anden venter på I/O. Placer derefter en forbindelsespooler foran DB'en, hvis du har brug for det (pgbouncer / Javas forbindelsespooling).
Så kan du endda overveje at øge work_mem, hvis du har brug for det.
Åh - helt rimeligt at køre uden swap aktiveret. Når først du begynder at bytte, er du alligevel i en verden af smerte med hensyn til databasebrug.
Rediger:Udvid om work_mem vs shared
Hvis du er i tvivl, skal du altid henvise til dokumentation .
shared_buffers værdi er, som navnet antyder, delt mellem backends. work_mem er ikke kun pr. backend, det er faktisk pr. sort. Så - én forespørgsel kan bruge tre eller fire gange det beløb, hvis den sorterer på tre underforespørgsler.