1С + PostgreSQL: Kernel OOM killer убивает процессы (postgres/rphost)
Архитектура памяти Linux и механизм OOM Killer
Проблема, когда ядро Linux (Kernel) принудительно завершает процессы сервера PostgreSQL (postgres) или рабочего процесса сервера 1С (rphost), связана с механизмом Out Of Memory (OOM) Killer. Linux по умолчанию разрешает приложениям запрашивать больше памяти, чем есть физически (Overcommit). Когда реальная RAM и SWAP заканчиваются (часто это происходит ночью при реструктуризации тяжелых таблиц, переиндексации или выполнении монструозных аналитических отчетов в 1С), ядро вызывает OOM Killer, который убивает самый прожорливый процесс (по OOM Score), чтобы спасти операционную систему от краха. Бизнес-риски: аварийное падение СУБД, откат длительных транзакций, прерывание работы всей компании.
Анализ логов: как понять, что это OOM Killer
| Источник | Команда / Лог | Симптом |
|---|---|---|
| dmesg (Linux Kernel) | dmesg -T | grep -i oom | Строки вида: "Out of memory: Killed process 12345 (postgres)". |
| PostgreSQL Log | /var/log/postgresql/... | Строки: "server process (PID ...) was terminated by signal 9: Killed". |
| 1С (Тех. Журнал) | ТЖ (Событие PROC) | Внезапное исчезновение rphost, ошибка «Сеанс отсутствует или удален» на клиентах. |
Тюнинг Linux и PostgreSQL для 1С
Сценарий 1: Настройка Overcommit Memory в Linux (sysctl)
Для серверов СУБД критически важно запретить ядру Linux безумно раздавать виртуальную память (режим "heuristic overcommit" = 0). Необходимо перевести его в строгий режим (Strict overcommit = 2).
1. Редактируем параметры ядра
nano /etc/sysctl.conf
2. Добавляем или изменяем строки:
vm.overcommit_memory = 2
vm.overcommit_ratio = 80 # Процент RAM, доступный приложениям сверх SWAP
vm.swappiness = 10 # Минимизируем использование swap (от 1 до 10)
3. Применяем настройки без ребута
sysctl -pСценарий 2: Корректировка параметров postgresql.conf
Самая частая причина OOM в связке с 1С — неправильно настроенный work_mem (память на сортировку) и maintenance_work_mem (память для VACUUM/CREATE INDEX).
- shared_buffers: Не ставьте больше 25-40% от RAM. PostgreSQL активно использует файловый кэш ОС (page cache).
- work_mem: 1С генерирует сложные запросы с кучей сортировок (ORDER BY). Если
work_mem= 100MB, а в запросе 10 сортировок, ОДИН процесс postgres заберет 1GB! Для 1С ставьте не более 16-32MB. - maintenance_work_mem: Если памяти 64GB, ставьте 1-2GB, но не больше, иначе параллельный автовакуум (autovacuum_max_workers) съест всю память.
Типовые ошибки администраторов
- Отключение файла подкачки (SWAP): «У меня 256GB RAM, swap не нужен!» — это миф. Linux использует swap для сброса неактивных страниц памяти (anonymous pages). Без swap OOM Killer приходит гораздо раньше, так как ядро теряет маневренность в управлении памятью. Создайте хотя бы 4-8GB SWAP.
Тюнинг PostgreSQL под 1С — это балансировка на грани между производительностью дисковой подсистемы и крахами OOM. DBA-эксперты ITSTM проведут аудит конфигурации PG (pgbadger), настроят пулинг соединений (PgBouncer) и подберут идеальные параметры для вашего железа.
Частые вопросы (FAQ)
Если убивает rphost (Сервер 1С), а не postgres, в чем причина?
Процесс rphost страдает утечками памяти (Memory Leaks) при формировании огромных табличных документов (отчетов) или неправильной работе с COM-объектами на сервере. Настройте перезапуск рабочих процессов (rphost) по лимиту памяти в консоли кластера 1С (Администрирование серверов).
Что такое vm.overcommit_ratio = 80?
В режиме overcommit_memory = 2 ядро разрешает выделить память в объеме: (Размер_SWAP) + (Размер_RAM * overcommit_ratio / 100). Если лимит превышен, приложение получит штатную ошибку 'Out of memory' и отменит операцию, но сам процесс (и ОС) не упадут от кинжала OOM Killer.
Как защитить конкретный процесс (например, postgres) от OOM Killer?
Можно изменить OOM Score для конкретного процесса. В systemd unit файле службы (postgresql.service) добавьте строку OOMScoreAdjust=-1000. Это сделает процесс практически неуязвимым для OOM Killer, но тогда ядро может убить sshd или другие важные демоны.
Влияет ли max_connections на потребление памяти?
Да. Каждое соединение (даже простаивающее) потребляет ресурсы ОС (shared memory, structures). В 1С без PgBouncer количество соединений равно количеству рабочих сеансов. Старайтесь использовать PgBouncer (transaction pooling) для снижения количества реальных коннектов к PostgreSQL.