Engenheiro da AWS relata que o desempenho do PostgreSQL cai pela metade no Linux 7.0 — a correção pode não ser simples

• No kernel de desenvolvimento do Linux 7.0, foi descoberta por um engenheiro da Amazon/AWS uma grave regressão de desempenho em que a vazão do servidor de banco de dados PostgreSQL cai para cerca de metade em relação ao kernel anterior
• Em medições feitas em servidores Graviton4, o Linux 7.0 oferece apenas cerca de 0,51x da vazão em comparação com o kernel anterior, e foi constatado que a causa é o consumo de muito mais tempo em spinlocks em espaço de usuário
• A causa da regressão é uma mudança no Linux 7.0 que restringiu o modo de preempção do kernel; foi enviado um patch para restaurar o PREEMPT_NONE como padrão, mas a possibilidade de adoção é incerta
• O autor original, Peter Zijlstra, afirmou que, em vez de corrigir o kernel, o PostgreSQL deveria ser modificado para usar a extensão de time slice do RSEQ (Restartable Sequences)
• A versão estável do Linux 7.0 deve ser lançada em cerca de 2 semanas e também será usada como kernel base do Ubuntu 26.04 LTS, o que gera preocupação com degradação ampla de desempenho até que o PostgreSQL se adapte

---

Descoberta do problema e escala

• O engenheiro da Amazon/AWS Salvatore Dipietro relatou regressões de vazão e latência no PostgreSQL
• Em medições com base em servidores Graviton4, o Linux 7.0 oferece apenas 0,51x da vazão em relação ao kernel existente
  • Foi confirmado que a causa é o gasto de muito mais tempo em spinlocks em espaço de usuário

Causa da regressão: restrição do modo de preempção

• Como resultado de um bisect, foi identificado que a causa é a mudança que restringiu o modo de preempção do kernel no Linux 7.0
• Essa mudança foi feita para manter apenas os modos de preempção Full e Lazy em arquiteturas de CPU modernas, e foi incluída como parte da atualização do scheduler do Linux 7.0

Patch enviado e reação dos mantenedores do kernel

• Um patch para restaurar o PREEMPT_NONE como modo de preempção padrão foi enviado à mailing list do kernel Linux devido à gravidade da regressão
• No entanto, Peter Zijlstra, que escreveu o código original, é contrário à aceitação desse patch e afirmou que a solução é o PostgreSQL usar a extensão de time slice do RSEQ (Restartable Sequences)
  • A extensão de time slice do RSEQ também é um recurso incluído no Linux 7.0
  • Zijlstra explicou que "isso pode limitar a exposição à preempção do detentor do lock"

Alcance do impacto e cronograma de lançamento

• Se essa posição for mantida, até que o PostgreSQL seja atualizado, o desempenho do PostgreSQL em alguns cenários no Linux 7.0 estável poderá cair significativamente
• A versão estável do Linux 7.0 deve ser lançada em cerca de 2 semanas
• O Linux 7.0 será o kernel base do Ubuntu 26.04 LTS, e o mesmo impacto também poderá atingir o Ubuntu 26.04 LTS, previsto para o fim de abril

[unstabler]

Pelo que ouvi, parece que os desenvolvedores do kernel vêm dizendo aos desenvolvedores do PostgreSQL há quase 10–20 anos algo como: "spinlocks em userland não são recomendados, então gostaríamos que vocês reconsiderassem isso"..

https://x.com/kosaki55tea/status/2040458791536497035

[GN⁺]

Comentários no Hacker News

• Vale a pena ler a mensagem de acompanhamento no LKML do desenvolvedor do Postgres Andres Freund

  • Se o problema de desempenho for uma regressão reproduzível, é estranho que a solução exija desativar recursos adicionados no 7.0
  • Não é uma única mensagem; acompanhando a thread inteira há informações adicionais
  • Não é bom forçar recursos de baixo nível introduzidos no 7.0 para corrigir uma regressão que só aparece no 7.0
    A opinião é que os mantenedores do Linux deveriam tratar aplicativos centrais como o PostgreSQL como prioridade de suporte
    Isso lembrou um caso antigo em que o Fedora bloqueava atualizações ao instalar o Wine
  • A solução “use hugepages” sempre é sugerida, mas a maioria dos usuários ignora isso
  • A queda de desempenho para 0,51x só ocorreu em uma máquina ARM64 de 96 núcleos e não foi reproduzida em AMD64
    Ou seja, não é um problema que afete todos os usuários do PostgreSQL ao migrar para o kernel mais recente

• Houve a opinião de que usar spinlock em espaço de usuário sem suporte do kernel é pedir por perda de desempenho

  • Eu também não gosto do uso de spinlock no Postgres e estou removendo isso aos poucos
    Porém, locks baseados em futex causam regressão de desempenho por conta do aumento de barreiras de memória
    Além disso, o Postgres ainda precisa considerar plataformas que não suportam operações atômicas de 8 bytes, então a substituição não é simples
    O spinlock em questão foi removido recentemente e, ao usar huge pages, o gargalo praticamente desaparece
  • Surgiu a analogia de que usar spinlock em espaço de usuário é como “dar uma martelada na própria cara”
  • Também houve a opinião de que o PostgreSQL usa spinlock por manter compatibilidade com kernels antigos, mas que já passou da hora de parar

• Também apareceu a afirmação de que “ninguém usa kernel mais novo em produção”
  Na prática, o Ubuntu 26.04 LTS será lançado em breve com base no Linux 7.0, então muitos usuários vão acabar usando
  O problema é que, no momento, é preciso um patch no kernel, não uma configuração via sysctl

  • Ainda assim, é preciso que alguém teste kernels recentes para que problemas assim sejam descobertos cedo
  • Se o PostgreSQL é afetado, há chance de outros aplicativos também serem
  • Também houve a observação de que, em ambientes Docker, não há escolha porque o kernel do host é compartilhado
  • Como referência, a opção PREEMPT_NONE foi removida na maioria das plataformas

• O contexto sobre PREEMPT_LAZY pode ser visto em um artigo da LWN

• Houve um comentário em tom de piada perguntando se alguém verificou se Jia Tan enviou patches recentes para o kernel,
  ao que responderam: “nem precisa, já há vulnerabilidades demais”

• Houve curiosidade sobre se a I/O assíncrona e as otimizações de consultas paralelas do PostgreSQL 18 poderiam compensar essa queda de desempenho
  Mais detalhes podem ser vistos nas notas de lançamento do PostgreSQL 18

• Também houve quem questionasse por que modos dinâmicos de preempção como PREEMPT_LAZY são necessários
  A alegação é que o benefício para usuários comuns não é claro

  • Em resposta, explicaram que a ideia é aumentar a vazão sem elevar a latência
    Isso permitiria ao kernel receber informações mais explícitas e melhorar as decisões de escalonamento

• Houve um comentário dizendo que mediram uma queda de desempenho de 10% entre o FreeBSD 14 e o 15.0, e que este caso trouxe algum consolo

  • A reação seguinte foi: “mas pelo menos houve esse tanto de recurso novo?”

• Também houve crítica de que o Phoronix publicou a matéria sem verificação suficiente
  Em um e-mail posterior, concluiu-se que o próprio benchmark estava errado e que, na prática, não havia um grande problema

  • Ainda assim, a regressão ocorre apenas quando huge pages não são usadas
    Talvez não seja um grande problema para o PostgreSQL, mas pode afetar outros aplicativos que não podem usar huge pages
    Por isso, houve a opinião de que não é algo a ser simplesmente ignorado

• Um link para uma thread antiga do LKML também foi compartilhado