Инженер Amazon обнаружил критический баг в тестовом ядре за две недели до релиза — миллионы баз данных под угрозой.
Инженер Amazon Web Services (AWS) Сальваторе Дипьетро выявил серьёзную регрессию производительности в тестовой версии ядра Linux 7.0, которая приводит к двукратному снижению пропускной способности PostgreSQL. Проблема, обнаруженная 3-4 апреля 2026 года, ставит под угрозу миллионы производственных развёртываний популярной СУБД, поскольку стабильный релиз Linux 7.0 ожидается уже 18 апреля — менее чем через две недели.
Масштаб проблемы
.Измерения, проведённые на серверах AWS Graviton4 с ARM-процессорами, показали катастрофические результаты: пропускная способность PostgreSQL на Linux 7.0 составляет всего 0.51x от показателей предыдущих версий ядра. Это не просто небольшое замедление — это полномасштабный производственный кризис, который может удвоить инфраструктурные затраты организаций, использующих PostgreSQL.
Для наглядности: компания, эксплуатирующая 10 серверов PostgreSQL, внезапно потребует 20 серверов для поддержания текущей нагрузки. Альтернатива — согласиться на двукратное снижение производительности и замедление отклика баз данных.
Корень зла: удаление PREEMPT_NONE
Причина регрессии кроется в архитектурном решении разработчиков ядра Linux 7.0 ограничить доступные режимы преемпции (прерывания задач планировщиком). В новой версии для современных архитектур процессоров (ARM64, x86, PowerPC, RISC-V, s390, LoongArch) удалён режим PREEMPT_NONE, оптимизированный для серверных нагрузок. Теперь доступны только PREEMPT_FULL (всегда прерываемый, для низкой латентности) и PREEMPT_LAZY (контролируемая преемпция).
PostgreSQL использует пользовательские спинлоки (spinlocks) — лёгкие блокировки, которые циклически проверяют доступность ресурса. Эти спинлоки рассчитаны на режим PREEMPT_NONE, где поток, удерживающий блокировку, не прерывается планировщиком. В режиме PREEMPT_LAZY планировщик прерывает потоки, удерживающие блокировки, заставляя другие потоки впустую расходовать CPU-циклы в ожидании освобождения ресурса, который не будет доступен до возобновления прерванного потока. Результат — коллапс производительности.
Философский конфликт: кто должен адаптироваться?
Сальваторе Дипьетро опубликовал патч, восстанавливающий PREEMPT_NONE как режим по умолчанию, однако его принятие под вопросом. Ведущий разработчик ядра Питер Зейлстра ответил категорично: «Исправление заключается в том, чтобы заставить PostgreSQL использовать расширение временного среза rseq... Это должно ограничить воздействие преемпции владельца блокировки»
Зейлстра предлагает использовать механизм Restartable Sequences (RSEQ) — технологию пользовательских атомарных операций, которая позволяет потокам запрашивать продление временного среза, чтобы избежать прерывания при удержании критических блокировок. RSEQ был интегрирован в Linux 7.0 именно как решение подобных проблем.
Однако здесь возникает парадокс: PostgreSQL пока не поддерживает RSEQ, и сроки реализации неизвестны. Администраторы баз данных, сталкивающиеся с 50%-ным падением производительности, не могут позволить себе ждать месяцы, пока сообщество PostgreSQL адаптируется к изменениям ядра. Это порождает фундаментальный вопрос: должно ли ядро сохранять обратную совместимость для широко используемых приложений, или приложения должны постоянно адаптироваться к эволюции ядра? Позиция Зейлстра однозначна: приложения должны модернизироваться.
Рекомендации для администраторов
Для снижения рисков экспертами рекомендуется:
- Закрепить версии ядра в production — отключить автоматические обновления до разрешения ситуации
- Включить бенчмарки PostgreSQL (pgbench, sysbench) в процедуры тестирования обновлений ядра
- Мониторить метрики времени ожидания спинлоков на дашбордах
- Ожидать официального анонса поддержки RSEQ в PostgreSQL перед миграцией на Linux 7.0
- Для managed-решений (AWS RDS, Google Cloud SQL) ожидать автоматической задержки внедрения Linux 7.0 провайдерами.
Системный провал тестирования
Инцидент выявил опасный пробел в методологии тестирования ядра. PostgreSQL — одна из самых популярных баз данных в мире с миллионами production-развёртываний. Как удаление PREEMPT_NONE не вызвало регрессионных тестов с нагрузками баз данных до выхода релиз-кандидатов? Ответ: тестирование ядра фокусируется на синтетических бенчмарках, а не на реальных прикладных стеках. В результате администраторы баз данных вынуждены обнаруживать проблемы производительности либо через production-инциденты, либо — в лучшем случае — через тщательное предварительное тестирование.
Урок очевиден: никогда не доверять «стабильным» релизам ядра для нагрузок, чувствительных к производительности, без обширной валидации. Даже широко используемая open-source инфраструктура может содержать критические регрессии для конкретных сценариев использования.