Ubicloud: OOM killer в Linux способен разом оборвать все соединения Postgres. Сооснователь признал: перебор
Когда Linux убивает один процесс Postgres, чтобы освободить память, общее состояние может стать противоречивым, поэтому постмастер убивает сразу все процессы, и рвётся каждое соединение. Решение Ubicloud — один параметр sysctl. А затем в тред пришёл сооснователь Ubicloud и сказал, что заголовок вышел слишком резким.
Механика: процессы Postgres делят общие сегменты памяти, поэтому OOM-killer, убив один процесс, вынуждает постмастер завершить все процессы разом. Ответ Ubicloud — строгий overcommit (vm.overcommit_memory=2): Linux сразу отказывает в выделении памяти сверх лимита с ошибкой ENOMEM, а Postgres просто отменяет ту транзакцию, что стала причиной.
Тред разделился. Один комментатор говорит, что статья неверно описывает режимы overcommit в ядре и не упоминает oom_score_adj; сооснователь самой компании признаёт, что подача получилась слишком резкой.
.jpg)
Механизм отказа и решение в одну строку
.jpg)
Статья Ubicloud *PostgreSQL и OOM killer* делает конкретное заявление: Postgres и Linux OOM killer не могут безопасно сосуществовать. Постмастер порождает процессы, которые делят общие сегменты памяти, поэтому если ядро убьёт один процесс под давлением памяти, общая память может остаться в противоречивом состоянии. Единственный безопасный вариант для постмастера: завершить все процессы разом, оборвав каждое соединение, или рискнуть тихим повреждением данных.
Их решение — строгий overcommit: vm.overcommit_memory=2. Ядро сразу отказывает в выделении памяти сверх лимита с ошибкой ENOMEM, и Postgres спокойно отменяет ту самую транзакцию вместо того, чтобы рушиться целиком. Компания публикует используемый CommitLimit (80% памяти без учёта hugepages плюс 2 ГБ) и попутно нашла в Linux 6.5 баг учёта памяти, из-за которого система показывала 651 ГБ занятой памяти на машине с 8 ГБ; исправили однобайтовым изменением.
Поправка и отступление от собственной компании
Тред выдал техническое опровержение и необычно честное признание. Сначала прозвучала поправка:
«Режим 0 (Heuristic) описан неверно. Всю эту сложную эвристику убрали почти десять лет назад... Статья игнорирует правильное современное решение... OOM Score Adjust.» — комментатор, назвавший упущенную альтернативу
Затем сооснователь компании, опубликовавшей пост, сам умерил его заголовок:
«Я согласен с технической частью поста, но чувствую, что в заголовке мы перегнули палку... Вижу много других сценариев, где строгий overcommit памяти дал бы непредвиденные побочные эффекты.» — Озгун из Ubicloud, экс-Citus Data
Системный инженер настаивал, что настоящее решение лежит на стороне приложения, а не в настройке ядра:
«OOM нужно обрабатывать так же, как это делают зрелые базы данных: вести собственный учёт памяти, использовать только свои аллокаторы... следить, чтобы каждый путь выделения памяти мог восстановиться после OOM.» — комментатор о дисциплине управления памятью на уровне приложения
Есть и практическая опасность, которую пост недооценивает: на некоторых конфигурациях строгий overcommit может начать блокировать сам `fork()`, так что проверяйте это на стейджинге, прежде чем выкатывать в прод. Практический вывод уже, чем заголовок: значение overcommit_memory=2 разумно по умолчанию для выделенного сервера Postgres, но это компромисс с острыми углами, а не универсальное лекарство, которое обещает заголовок, и об этом говорят даже те, кто его написал.
Получайте такие разборы каждый день
Главные истории Hacker News — на email, в Telegram или RSS.
Столетний федеральный доклад описывает Америку 1926 года — тред спорит, стало ли лучше
Девятнадцать миллионов автомобилей, радио, только вошедшее в дома, и половина страны — ещё сельская, но уже стекающаяся в города: забытый правительственный обзор 1926 года читается как черновик тревог 2026-го. А затем комментатор подкидывает факт, который рушит всю ностальгию: концентрация богатства тогда была выше, чем сейчас.