PostgreSQL Error 53200: out_of_memory — расчет work_mem и shared_buffers
- Ошибка в клиенте:
ERROR: out of memory (SQLSTATE 53200). Detail: Failed on request of size ... - Падение параллельных аналитических запросов с множественными узлами сортировки/хеширования.
- Высокая утилизация SWAP и риск вызова Linux OOM Killer.
1. Анализ текущей конфигурации памяти
SHOW shared_buffers;
SHOW work_mem;
SHOW maintenance_work_mem;
SHOW max_connections;2. Правильный расчет work_mem
Память work_mem выделяется на каждую операцию сортировки/соединения внутри запроса, а не на весь процесс. При сложном плане один запрос может использовать work_mem * 5.
-- Формула безопасного work_mem:
-- work_mem = (Доступная RAM - shared_buffers) / (max_connections * 3)
-- Установка адекватного лимита
ALTER SYSTEM SET work_mem = '32MB';
SELECT pg_reload_conf();3. Проверка настроек Linux Huge Pages
cat /proc/meminfo | grep -i HugePagesИспользование Transparent Huge Pages (THP) приводит к фрагментации памяти. Отключите THP в ОС:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defragЧастые вопросы (FAQ)
Почему возникает ошибка 53200 при наличии свободной физической памяти?
PostgreSQL отслеживает внутренние контексты аллокаций памяти (AllocSet). Ошибка генерируется, когда запрос упирается в 32-битный лимит одного блока памяти или системный ulimit процесса.
Какой процент RAM выделять под shared_buffers для баз 1С?
Рекомендуемый объем составляет 25% от общей оперативной памяти сервера (для серверов с RAM > 64GB обычно от 16GB до 32GB).
Можно ли задавать большой work_mem только для одного пользователя?
Да: ALTER USER report_user SET work_mem = '512MB'; позволит выделить память только для тяжелых отчетов без риска для остальных сессий.
Как влияют настройки sysctl vm.overcommit_memory на ошибку 53200?
При vm.overcommit_memory = 2 ядро Linux строго запрещает выделение памяти сверх установленного лимита (RAM + Swap * ratio), что предотвращает внезапный OOM Killer.