Performance no Linux

 (brendangregg.com)
3 pontos por GN⁺ 2023-10-15 | 1 comentários | Compartilhar no WhatsApp
  • A página Linux Performance de Brendan Gregg é um hub de links que reúne em um só lugar materiais de observabilidade, análise, benchmarking e tuning necessários para começar a investigar desempenho no Linux
  • O fluxo principal de ferramentas segue por perf, eBPF, bcc, bpftrace e Flame Graphs, com acesso direto desde exemplos de comandos até ferramentas de tracing e visualização
  • Os materiais de documentação se expandem para o texto de análise de desempenho da Netflix de 2015, tuning de EC2, Linux load averages, frame pointers, exemplos de gdb e dois livros sobre desempenho
  • A lista de palestras oferece trilhas de aprendizado por situação, como uma visão geral de 40 minutos, um tutorial de ferramentas de 90 minutos, análise de desempenho de contêineres e checklist de SRE
  • Em cada mapa de ferramentas, é preciso verificar o ano no canto inferior direito da imagem para confirmar a atualidade, e o diagrama integrado não é tão completo quanto os diagramas individuais

Hub de materiais de desempenho e mapas de ferramentas

  • Esta página é um hub de links que reúne os materiais de desempenho no Linux criados por Brendan Gregg
  • A imagem do mapa de ferramentas à direita foi feita com fonte grande para combinar com um slide deck, e também tem um formato que pode ser impresso e colocado na parede do escritório
  • O mapa de ferramentas divide o trabalho de desempenho no Linux nas seguintes áreas
  • Para saber quão atualizada está cada imagem, é preciso verificar o ano no canto inferior direito
  • Um diagrama em alta resolução que combina observabilidade, tuning estático de desempenho e perf-tools/bcc também é fornecido separadamente
    • png
    • svg
    • Este diagrama integrado não é tão completo quanto os outros diagramas individuais

Principais ferramentas com acesso direto

  • perf: perf one-liners, exemplos e materiais de visualização
  • eBPF tools: ferramentas de tracing BPF/bcc e exemplos
  • perf-tools: coleção de ferramentas perf baseada em Ftrace
  • bcc: coleção de ferramentas de desempenho BPF/bcc
  • bpftrace: coleção de ferramentas de desempenho BPF/bpftrace
  • Flame Graphs: como usar Flame Graph com perf e outros profilers

Documentação e materiais de aprendizado

Artigos avançados sobre eBPF, ftrace e perf

Palestras recomendadas por situação

  • Linux Systems Performance, USENIX LISA 2019

    • Resume, em 40 minutos, o desempenho de sistemas Linux em 6 aspectos: observabilidade, metodologia, benchmarking, profiling, tracing e tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Resume, em uma keynote de 20 minutos, as mudanças e funcionalidades mais recentes do Linux performance em 2018
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Em um tutorial de 90 minutos, cobre observabilidade de performance, benchmarking, tuning, tuning estático de performance, ferramentas e metodologias de tracing, além de demos ao vivo
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • Foca mais em tuning do que em observabilidade de performance, cobrindo o contexto da Netflix, tipos e recursos de instâncias AWS EC2, Linux kernel tunables e observabilidade
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Aborda como encontrar onde está o gargalo entre host e container, como fazer profiling de apps em containers e como se aprofundar mais até o kernel
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Cobre problemas frequentes em ferramentas de sistema Linux, métricas, estatísticas, visualização, overhead de medição e benchmarks, junto com conselhos de “What You Can Do”
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Foca em profiling de CPU e no funcionamento de Flame Graphs, incluindo questões de stack traces e symbols ao fazer profiling de Java, Node.js, VMs e containers, além das características de perf_events
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Aborda o uso do enhanced BPF, ou eBPF, adicionado à série Linux 4.x, para análise de performance, observabilidade e debugging
    • O frontend é o projeto open source bcc, que fornece a interface BPF e um conjunto de ferramentas
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • Cobre as ferramentas ftrace e perf_events, além do perf-tools, que usa principalmente ftrace
    • O ftrace é apresentado como um tracer que estava embutido no kernel Linux há vários anos, mas permaneceu quase desconhecido
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Na segunda metade, inclui um checklist para incident performance response em Linux, que também pode ser útil para análises urgentes de performance em Linux
    • youtube, usenix, slideshare, PDF

Materiais recomendados

Leituras relacionadas

1 comentários

 
GN⁺ 2023-10-15
Opiniões do Hacker News

  • Uso o tuned em um VPS Debian/Ubuntu que roda apps em tempo real, e ele funciona bem
    É mais simples do que alterar diretamente parâmetros do kernel, ou seja, configurações de sysctl ou tunables do kernel
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • Também usamos Tuned em workloads SAP e gostamos muito

  • Eu não sabia que Brendan Gregg agora estava na Intel
    https://en.wikipedia.org/wiki/Brendan_Gregg
    Ele também é o protagonista do vídeo viral Shouting in the Data Center
    https://www.youtube.com/watch?v=tDacjrSCeq4
    É um verdadeiro gênio

  • Vale apontar que quase tudo o que o texto original aborda não é latência, mas throughput/largura de banda de rede, disco, outras E/S e CPU
    Para muita gente, desempenho significa throughput, então dá para entender. Mas há casos em que a latência é muito mais importante do que o throughput, e ajustar latência no Linux exige outro conjunto de ferramentas

    • É uma observação bastante válida. Reduzir latência também é muito mais difícil do que aumentar throughput[1], então muitas vezes é importante se preocupar com latência
      Outro eixo que as pessoas podem otimizar é desempenho por watt, mas não vou me alongar nisso aqui
      Às vezes, otimizar throughput também acaba otimizando latência. Por exemplo, se você consegue colocar mais processos em uma mesma máquina, a distância média entre os processos e os destinos com que eles se comunicam diminui, reduzindo também a latência média
      Uma medida bastante óbvia ao otimizar latência é aumentar o throughput o suficiente para que ele não vire gargalo
      Se você está otimizando latência de forma agressiva, tenho a impressão de que não há tanto tuning de Linux em si. Posso estar errado, mas em geral parece que o foco fica em fixar processos a cores, execução tickless, networking em espaço de usuário e ajustes mais ligados ao hardware, como tamanho de página, SMT, configurações de economia de energia e escolha de hardware
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Parece mais correto chamar de throughput do que de bandwidth. O significado é parecido, mas o contraste entre throughput e latência já é discutido há muito tempo
      Às vezes dá para melhorar ambos, mas normalmente há um trade-off
    • Tenho curiosidade sobre ferramentas ou materiais recomendáveis relacionados a tuning de latência
    • Se o objetivo é reduzir latência para características de tempo real do sistema, é provável que, por mais knobs que você ajuste em uma distribuição Linux padrão, ela não se torne um sistema satisfatório

  • Esperar também é uma boa estratégia
    A partir do Linux 6.5, o scheduler entende que, quando um “core” SMT está ocupado, talvez não seja ideal colocar algo em outro “core”. Na prática, ele se parece mais com um único core com custo de troca de contexto muito baixo
    Graças a isso, tarefas altamente paralelas ficaram perceptivelmente mais responsivas, e isso também aparece nos gráficos de uso de CPU
    Os resultados podem variar por causa de coerência de cache e questões de NUMA

    • Em kernels anteriores, apenas desativar SMT já pode produzir esse efeito de maior responsividade, além de bloquear alguns ataques de canal lateral e melhorar a eficiência energética

  • Posts relacionados:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - janeiro de 2017, 64 comentários
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - agosto de 2014, 22 comentários

  • Se alguém quiser alterar algum parâmetro tunable, mas não conseguir explicar por que essa mudança teria o efeito desejado nem por que ele foi configurado originalmente com aquele valor, eu não deixaria mudar em produção
    Dá para chamar isso de “parâmetro tunable de Chesterton”

    • Mesmo que você consiga explicar um motivo hipotético, não bastaria fazer benchmark fora do ambiente de produção?

  • Considerando o trabalho do Brendan com eBPF, vejo esse material como uma forma de monitorar e avaliar com mais facilidade diversas situações de desempenho
    Ajustes e tuning envolvem trade-offs, e normalmente otimizar uma coisa prejudica outra
    Como observação adicional, o btop tem sido muito útil como visualizador TUI all-in-one de desempenho e carga do sistema, substituindo o glances. Fico curioso sobre quanto os desenvolvedores o usam e se há motivação para criar ferramentas melhores de monitoramento em TUI
    Quando entro em um servidor, a primeira coisa que faço é abrir o tmux e dedicar uma janela ao btop

  • Para mim, “tuning” de desempenho no Linux equivale a desativar as mitigações de Spectre/Meltdown
    Nesse caso, os nós de computação rodam dentro de uma VPC sem acesso à internet, então o risco parece bem baixo

    • Depende de qual CPU você usa. No Zen 4, desativar as mitigações não era suportado e causava bugs ou crashes
      Parece que aquele crash específico foi corrigido, mas ainda assim não recomendo. As CPUs mais recentes da AMD e da Intel foram projetadas para rodar pelo menos com as mitigações básicas ativadas

  • Deixei nos favoritos. Acho que logo vai ser útil para algo em que estou trabalhando
    Ainda não li todos os slides, mas fico curioso para saber se alguém já viu uma melhora significativa de desempenho com opções de build do kernel
    Antigamente, quando eu usava Gentoo e mexia nas flags de build, eu costumava alterar o Makefile do kernel para usar -O3 e aplicar um patch de -march=native. Olhando em retrospecto, pelos benchmarks da Phoronix isso parece ser até prejudicial em várias cargas de trabalho; fico curioso para saber se alguém já viu casos contrários

  • É um bom site. Ele tem uma tendência a resumir desempenho em Linux, seja tuning ou monitoramento, o que faz a gente respirar fundo
    Esse assunto é profundo, e há muitos tipos de ferramentas de observabilidade. No mínimo, é preciso conhecer bem uptime, dmesg e iostat. Essas ferramentas passam por vários aspectos do sistema, como carga, memória e CPU, e dão as primeiras pistas para diagnosticar o estado. É a página 1 de 100 da checklist que eu chamo de “vamos dar uma olhada”
    Em metodologia de análise de desempenho, recomenda-se usar benchmarks cuidadosos para avaliar de forma geral o comportamento do sistema e as características da carga de trabalho. Compare cenários antes e depois das mudanças; primeiro faça pequenas alterações e depois vá combinando gradualmente aquelas que parecerem trazer ganhos. O laboratório e o ambiente de produção nunca se comportam exatamente da mesma forma
    A partir daqui fica complicado. Profiling de CPU com ferramentas como perf e visualizações como flame graph permitem uma análise direcionada da atividade da CPU; somando o rastreamento de eventos de hardware, dá para otimizar a eficiência computacional. É preciso saber mais do que “o problema é no app, estava tudo bem antes da última release do time de desenvolvimento”
    Como administrador, ao conversar com desenvolvedores, passam a ser necessárias ferramentas como ftrace e BPF no Linux. Elas permitem rastrear em detalhe a execução de funções do kernel e chamadas de sistema, o que é importante para troubleshooting e otimização de desempenho. Por outro lado, se você for desenvolvedor, talvez precise validar a intuição do administrador. Como dizem, confie, mas verifique
    Se o código é seu, você precisa conhecer BPF. BPF não só permite rastreamento eficiente dentro do kernel como também impulsiona a criação de ferramentas avançadas e personalizadas de profiling com bcc e bpftrace, dando uma visão mais profunda do desempenho do sistema
    Por fim, isto é realmente difícil. Tuning envolve ajustar inúmeros componentes do sistema e parâmetros do kernel, de CPU e memória até configurações de rede, para otimizar desempenho e confiabilidade em diferentes cargas de trabalho. Ou então é só pôr a culpa na rede
    Na prática, é preciso uma boa postura em relação à gestão de mudanças. Correr atrás de código ou de parâmetros do kernel pode sobrecarregar todo mundo e, em situações de aperto de tempo, a pressão aumenta ainda mais a chance de erro humano