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

 (phoronix.com/news)
7 pontos por GN⁺ 24 일 전 | 2 comentários | Compartilhar no WhatsApp
  • 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

Leituras relacionadas

2 comentários

 
unstabler 23 일 전

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⁺ 24 일 전
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