Ако чета изхода от горната ви информация правилно, тя не е взета в момент, когато ви липсва памет.
Действителната грешка изглежда наред - не изисква огромно количество памет, така че вероятно машината е била без памет в този момент.
Нека да разгледаме набързо вашите настройки:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
И така - вие сте на мнение, че можете да поддържате 1000 едновременни заявки, като всяка използва да речем 10 + 40MB (някои може да използват кратни на 40MB, но нека бъдем разумни). И така - това ми подсказва, че вашата машина има> 500 ядра и да речем 100 GB RAM. Това не е така.
Така че - вземете вашия брой ядра и го удвоете - това е разумна стойност за максималния брой връзки. Това ще ви позволи една заявка за всяко ядро, докато друго чака I/O. След това поставете пул за връзка пред DB, ако трябва (pgbouncer / пул за връзка на Java).
След това можете дори да помислите за увеличаване на work_mem, ако е необходимо.
О - напълно разумно да работи без активиран суап. След като започнете да разменяте, така или иначе сте в свят на болка по отношение на използването на базата данни.
Редактиране:разширяване на work_mem срещу shared
Ако се съмнявате, винаги вижте документация .
shared_buffers стойността е, както подсказва името, споделена между задните части. work_mem не е само за бекенд, а всъщност е за сортиране. И така - една заявка може да използва три или четири пъти тази сума, ако извършва сортиране на три подзаявки.
