Замедление вызвано изменением режима вытеснения (preemption) в планировщике по умолчанию с PREEMPT_NONE на PREEMPT_LAZY на архитектурах, поддерживающих такой режим, из-за чего в пользовательском пространстве PostgreSQL стал тратить 55% времени CPU на вызов s_lock(). Для решения проблемы предложено вернуть по умолчанию режим PREEMPT_NONE и убрать его привязку к настройке ARCH_NO_PREEMPT.
Питер Зейлстра (Peter Zijlstra), автор изменений, из-за которых возникла регрессия, и мэйнтейнер планировщика задач и связанных с блокировками подсистем ядра, заявил, что исправление нужно вносить в код PostgreSQL. Для устранения падения производительности он посоветовал задействовать в PostgreSQL недавно добавленное в ядро расширение «rseq slice» (Restartable Sequences) для ограничения вероятности вытеснения держателя блокировки.
Пока не ясно какое решение примет Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя. С одной стороны ядро 7.0 находится на финальной стадии тестирования перед релизом и откат настроек планировщика может привести к другим регрессиям, а с другой стороны пользователи могут столкнуться с двухкратным снижением производительности одной из самых популярных СУБД.
Источник: http://www.opennet.ru/opennews/art.shtml?num=65143
