Jeśli poprawnie odczytuję dane wyjściowe twojego topu, nie są one pobierane w momencie, gdy zabraknie ci pamięci.
Rzeczywisty błąd wydaje się być w porządku - nie wymaga dużej ilości pamięci, więc prawdopodobnie w tym momencie w maszynie zabrakło pamięci.
Rzućmy okiem na Twoje ustawienia:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Tak więc - jesteś zdania, że możesz obsłużyć 1000 jednoczesnych zapytań, każde używając powiedzmy 10 + 40MB (niektórzy mogą używać wielokrotności 40MB, ale bądźmy rozsądni). Sugeruje mi to, że twoja maszyna ma> 500 rdzeni i powiedzmy 100 GB pamięci RAM. Tak nie jest.
Tak więc - weź liczbę rdzeni i podwój ją - to rozsądna wartość dla maksymalnej liczby połączeń. Umożliwi to jedno zapytanie na każdym rdzeniu, podczas gdy inne czeka na I/O. Następnie umieść pooler połączeń przed bazą danych, jeśli zajdzie taka potrzeba (pula połączeń pgbouncer / Java).
Wtedy możesz nawet rozważyć zwiększenie work_mem, jeśli zajdzie taka potrzeba.
Och - całkiem rozsądnie działa bez włączonej wymiany. Gdy zaczniesz wymieniać, i tak znajdziesz się w świecie bólu, jeśli chodzi o korzystanie z bazy danych.
Edytuj:rozwiń na work_mem a udostępniony
W razie wątpliwości zawsze zapoznaj się z dokumentacja .
shared_buffers wartość jest, jak sama nazwa wskazuje, współdzielona między backendami. work_mem to nie tylko zaplecze, to właściwie rodzaj. Tak więc - jedno zapytanie może użyć trzy lub cztery razy więcej, jeśli wykonuje sortowanie na trzech podzapytaniach.
