У нас есть экземпляр postgres 9.0, который работает на довольно мощной машине (96 ГБ ОЗУ / 24 ядра). В последние недели у нас были сбои из-за того, что дочерние процессы postgres были убиты из-за нехватки памяти OOM killer. Кажется, что из-за использования пула соединений эти дочерние процессы являются долгоживущими (что имеет смысл, поскольку открытие и закрытие соединений требует времени), проблема в том, что они постепенно растут в потреблении памяти, чтобы достичь даже 9 ГБ / процесс. Как вы можете себе представить, наличие 10 из них заполняет доступный таран, и в дело вступает убийца.
Вопросы следующие:
Для справки, настройки, которые могут влиять на память:
max_connections = 950
shared_buffers = 32MB
Все остальные настройки не отменяются, то есть мы используем значения по умолчанию.
Первое, что нужно учесть, - это увеличить shared_buffers путь вверх, по крайней мере, до 1 ГБ и, возможно, намного больше, до 25% основной памяти. Это что говорит документ.
Всего 32 МБ, из которых ~ 18 МБ уже будет использовано только для работы с max_connections до 950 дочерние процессы имеют доступ к разделяемой памяти, едва достаточной для общего доступа.
Это может или не может уменьшить проблему потребления памяти для вашей конкретной рабочей нагрузки и ситуации, но в любом случае это шаг в правильном направлении. Текущее значение безумно низкое.
Что касается конкретно OOM, вы можете рассмотреть обходные пути, предлагаемые в Перегрузка памяти Linux раздел док. Обратите внимание, однако, что это короткий абзац по сложной проблеме. Например, есть еще в этом сообщении в блоге и его комментарии с указателями для понимания контекста и компромиссов, связанных с ограничением или отключением OOM.
Кроме того, всегда возможна утечка памяти в Postgres. Убедитесь, что вы используете последнюю дополнительную версию, если она уже исправлена. В примечаниях к выпуску, которые поставляются с каждым выпуском исправлений, время от времени обязательно упоминаются утечки памяти.