Наиболее вероятная причина действительно звучит как нехватка памяти. Если это серверы Linux, то при запуске условия нехватки памяти вызывается «OOM-killer», который просто завершает процессы захвата памяти (следовательно, «сервер прервал процесс ненормально»). Ситуация с нехваткой памяти часто означает очень высокую загрузку дисков / подкачку, из-за чего сервер кажется не отвечающим.
См. Ваши файлы журнала ядра (или команду dmesg) для чего-то похожего на "Out of Memory: Killed process 1234 (postgres)". Это вызвано тем, что по умолчанию ядро разрешает перегружать память. Первое, что вы должны сделать, это отключить overcommit, чтобы обеспечить плавную обработку ситуаций нехватки памяти:
echo 2 > /proc/sys/vm/overcommit_memory
План A:
Вероятным виновником является настройка work_mem, которая указывает, сколько памяти может выделять каждая отдельная операция. Один запрос может состоять из нескольких этапов, интенсивно использующих память, поэтому каждый сервер может выделить несколько раз work_mem объема памяти, в дополнение к глобальной настройке shared_buffers. Кроме того, вам также понадобится немного свободной памяти для кэша операционной системы.
Для получения дополнительной информации см. Руководство PostgreSQL по настройкам потребления ресурсов: Документация PostgreSQL 8.3, потребление ресурсов
План B:
Возможно, сокращение этих параметров настолько замедлит ваши запросы, что вы все равно не сможете выполнить свою работу. Альтернативой этому является искусственное ограничение количества запросов, которые могут выполняться параллельно. Многие пулы соединений промежуточного программного обеспечения для PostgreSQL могут ограничивать количество параллельных запросов и вместо этого предоставлять очереди. Примерами этого программного обеспечения являются pgbouncer (более простой) и pgpool-II (более гибкий).
РЕДАКТИРОВАТЬ : Отвечая на ваши вопросы:
Каков наилучший / оптимальный способ обработки большого количества соединений в приложении, если они будут уничтожены после каждого запроса?
Как правило, установление новых подключений к PostgreSQL происходит не быстро, поскольку PostgreSQL порождает новый процесс для каждого бэкэнда. Тем не менее, процессы недешевы с точки зрения памяти, поэтому сохранение большого количества незанятых соединений с базой данных не является хорошей идеей.
Промежуточное ПО для пулов соединений, о котором я упоминал в Plan B , позаботится о сохранении разумного количества соединений с Postgres - независимо от того, когда и как часто вы подключаетесь или отключаетесь от пула. Поэтому, если вы выберете этот маршрут, вам не нужно беспокоиться об открытии / закрытии соединений вручную.
Во-вторых, я должен увеличить max_connections?
Если ваш сервер баз данных не имеет большого объема ОЗУ (более 8 ГБ), я бы не стал превышать ограничение по умолчанию в 100 подключений.