Инженер AWS обнаружил: Linux 7.0 вдвое снижает производительность PostgreSQL
Инженер AWS Сальваторе Дипьетро обнаружил, что Linux 7.0 вдвое снижает производительность PostgreSQL: throughput падает до 0,51x из-за нового планировщика PREEMPT_LAZY, который прерывает потоки, держащие spinlock.
Новости Tproger
PostgreSQL — одна из самых нагруженных баз данных в мире, и её производительность критична для тысяч продуктов. Но инженер AWS обнаружил, что обычное обновление ядра Linux может вдвое обрушить throughput — без каких-либо изменений в самой СУБД.
Сальваторе Дипьетро (Salvatore Dipietro) из AWS сообщил: на Linux 7.0 с планировщиком PREEMPT_LAZY throughput PostgreSQL упал до 0,51x по сравнению с Linux 6.x. То есть база данных стала работать почти вдвое медленнее — и виновата одна строка в ядре.
Ключевые выводы
- Linux 7.0 убрал режим
PREEMPT_NONE— остались только Full и Lazy preemption - Throughput PostgreSQL на Linux 7.0 упал до 0,51x (50 751 tps против 98 565 tps на Linux 6.x)
- Причина: планировщик прерывает поток, держащий spinlock, — 55% CPU уходит на spinning в ожидании
- Revert-патч восстанавливает производительность до 1,94x
- Linux 7.0 stable выйдет примерно через 2 недели; Ubuntu 26.04 LTS будет на нём
Как обнаружили регрессию
Дипьетро тестировал на EC2 m8g.24xlarge с 96-vCPU процессором Graviton4. Стенд: PostgreSQL 17, утилита pgbench, 1024 клиента, 96 потоков, длительность теста — 1200 секунд. Это типичная нагрузка высоконагруженного OLTP-сервиса.
На Linux 6.x результат составил 98 565 tps. На Linux 7.0 с PREEMPT_LAZY — 50 751 tps, то есть падение до 0,51x. После применения revert-патча производительность выросла до 1,94x относительно Linux 6.x — и достигла 98 565 tps.
Почему ядро изменили и при чём здесь spinlocks
Виновен коммит 7dadeaa6e851 за авторством Питера Зийлстры (Peter Zijlstra) из Intel. В Linux 7.0 убрали режим PREEMPT_NONE: теперь доступны только Full и Lazy preemption. По умолчанию включён PREEMPT_LAZY.
Проблема в том, как PostgreSQL реализует spinlocks. Функция s_lock() в StrategyGetBuffer/GetVictimBuffer крутится в ожидании блокировки. При PREEMPT_LAZY планировщик может вытеснить поток прямо в тот момент, когда он держит spinlock. Все остальные потоки, ожидающие этот замок, начинают активно спиниться — и по замерам 55% CPU уходит именно на это бесполезное ожидание. Затронуты все основные архитектуры: arm64, x86, powerpc, riscv, s390, loongarch.
PREEMPT_NONE означает, что задача будет выполняться до явного вызова schedule() или возврата из системного вызова/прерывания. Это исторически использовалось для серверных нагрузок с активным ожиданием, но мы убираем этот режим — он маскирует проблемы с блокировками вместо того, чтобы их решать.
Патовая ситуация: кто должен чинить?
Разработчики ядра считают, что проблема на стороне PostgreSQL: база данных должна использовать механизм rseq (Restartable Sequences) — расширение Linux, позволяющее коду пространства пользователя эффективно работать с критическими секциями без spinlock-спиннинга.
Правильное решение — использовать rseq time slice extension. Spinlock-спиннинг в пространстве пользователя изначально является проблемным паттерном в вытесняющей многозадачной среде.
Но PostgreSQL rseq не поддерживает, и никаких сроков интеграции нет. Это классический тупик: ядро меняет поведение, опираясь на «правильную» архитектуру, а прикладное ПО годами использует привычные примитивы. В итоге пострадают администраторы баз данных, которые просто обновят ядро.
Что делать администраторам PostgreSQL
До тех пор, пока проблема не решена на уровне ядра или PostgreSQL, администраторам баз данных стоит учитывать следующее:
- Не обновляться на Linux 7.0 в production до появления официального патча или workaround
- Отслеживать параметр
preemption modelядра при обновлении дистрибутива - Ubuntu 26.04 LTS, выходящая примерно в конце апреля 2026, будет использовать Linux 7.0 — проверить совместимость заранее
- При необходимости использовать кастомное ядро с revert-патчем коммита
7dadeaa6e851 - Следить за обновлениями в PostgreSQL hackers mailing list и linux-kernel mailing list
Часто задаваемые вопросы
Затронуты ли другие СУБД кроме PostgreSQL?
Потенциально — любые приложения, использующие spinlock-спиннинг в пространстве пользователя. PostgreSQL — наиболее известный пример, но MySQL, Redis и другие СУБД с аналогичными паттернами блокировок могут столкнуться с похожей проблемой на PREEMPT_LAZY.
Когда выйдет Linux 7.0 stable?
По прогнозу — примерно через 2 недели от публикации отчёта (начало апреля 2026). Ubuntu 26.04 LTS запланирована на конец апреля 2026 и будет включать Linux 7.0.
Что такое rseq и почему PostgreSQL его не использует?
Restartable Sequences (rseq) — механизм ядра Linux, позволяющий атомарно выполнять короткие последовательности в пространстве пользователя с автоматическим перезапуском при вытеснении. Это современная альтернатива spinlock-спиннингу. PostgreSQL исторически использует собственные spinlock-примитивы и не имеет реализации rseq — это многолетний технический долг, устранение которого требует значительных инженерных ресурсов.
Это баг Linux или PostgreSQL?
Оба лагеря правы по-своему. Ядро Linux меняет семантику вытеснения, следуя современным принципам дизайна. PostgreSQL использует паттерн, который работал десятилетиями, но плохо совместим с новым планировщиком. Практический итог один: администраторы получают деградацию производительности без предупреждения.
Регрессия производительности PostgreSQL на Linux 7.0 — наглядный пример того, как изменение в ядре может затронуть критическую инфраструктуру. До появления официального решения (патч ядра или поддержка rseq в PostgreSQL) администраторам баз данных следует воздержаться от обновления ядра в production-окружениях. Отслеживать развитие ситуации можно на Phoronix.
