Pesquisar

Monitoramento e gerenciamento do status e desempenho do sistema

download PDF
Red Hat Enterprise Linux 8

Otimização do rendimento, da latência e do consumo de energia do sistema

Resumo

Esta coleção de documentação fornece instruções sobre como monitorar e otimizar a produtividade, latência e consumo de energia do Red Hat Enterprise Linux 8 em diferentes cenários.

Tornando o código aberto mais inclusivo

A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.

Fornecendo feedback sobre a documentação da Red Hat

Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-la. Para fazer isso:

  • Para comentários simples sobre passagens específicas:

    1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML. Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
    2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
    3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
    4. Siga as instruções apresentadas.
  • Para enviar comentários mais complexos, crie um bilhete Bugzilla:

    1. Ir para o site da Bugzilla.
    2. Como Componente, use Documentation.
    3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
    4. Clique em Submit Bug.

Capítulo 1. Visão geral das opções de monitoramento de desempenho

A seguir estão algumas das ferramentas de monitoramento e configuração de desempenho disponíveis no Red Hat Enterprise Linux 8:

  • O Performance Co-Pilot (pcp) é usado para monitorar, visualizar, armazenar e analisar as medições de desempenho em nível de sistema. Ele permite o monitoramento e gerenciamento de dados em tempo real, e o registro e recuperação de dados históricos.
  • O Red Hat Enterprise Linux 8 fornece várias ferramentas que podem ser usadas da linha de comando para monitorar um sistema fora do nível de execução 5. A seguir estão as ferramentas da linha de comando embutidas:

    • top é fornecido pelo pacote procps-ng. Ele dá uma visão dinâmica dos processos em um sistema em execução. Ele exibe uma variedade de informações, incluindo um resumo do sistema e uma lista de tarefas atualmente sendo gerenciadas pelo kernel do Linux.
    • ps é fornecido pelo pacote procps-ng. Ele captura um instantâneo de um seleto grupo de processos ativos. Por padrão, o grupo examinado é limitado aos processos que são de propriedade do usuário atual e associados ao terminal onde o comando ps é executado.
    • As estatísticas da memória virtual (vmstat) são fornecidas pelo pacote procps-ng. Ele fornece relatórios instantâneos dos processos de seu sistema, memória, paginação, entrada/saída de blocos, interrupções e atividade da CPU.
    • O relatório de atividades do sistema (sar) é fornecido pelo pacote sysstat. Ele coleta e relata informações sobre a atividade do sistema que ocorreu até o momento no dia atual.
  • perf usa contadores de desempenho de hardware e pontos de rastreamento de kernel para rastrear o impacto de outros comandos e aplicações em um sistema.
  • bcc-tools é usado para a Coleção de Compiladores BPF (BCC). Ele fornece mais de 100 scripts eBPF que monitoram as atividades do kernel. Para mais informações sobre cada uma destas ferramentas, veja a página de manual descrevendo como utilizá-la e quais funções ela executa.
  • turbostat é fornecido pelo pacote kernel-tools. Ele relata a topologia do processador, freqüência, estatísticas do estado de inatividade, temperatura e uso de energia nos processadores Intel 64.
  • iostat é fornecido pelo pacote sysstat. Ele monitora e relata a carga do dispositivo de entrada/saída do sistema para ajudar os administradores a tomarem decisões sobre como equilibrar a carga de entrada/saída entre os discos físicos.
  • irqbalance distribui interrupções de hardware entre processadores para melhorar o desempenho do sistema.
  • ss imprime informações estatísticas sobre soquetes, permitindo aos administradores avaliar o desempenho do dispositivo ao longo do tempo. A Red Hat recomenda o uso de ss sobre netstat no Red Hat Enterprise Linux 8.
  • numastat é fornecido pelo pacote numactl. Por padrão, numastat exibe as estatísticas por nó NUMA de um sistema de falhas do alocador de memória do kernel. O desempenho ideal é indicado pelos valores altos numa_hit e baixos numa_miss.
  • numad é um daemon automático de gestão de afinidade NUMA. Ele monitora a topologia NUMA e o uso de recursos dentro de um sistema que melhora dinamicamente a alocação de recursos NUMA, o gerenciamento e, portanto, o desempenho do sistema.
  • SystemTap monitora e analisa as atividades do sistema operacional, especialmente as atividades do kernel.
  • valgrind analisa as aplicações executando-o em uma CPU sintética e instrumentando o código de aplicação existente à medida que é executado. Em seguida, imprime comentários que identificam claramente cada processo envolvido na execução da aplicação para um arquivo especificado pelo usuário, descritor de arquivo ou soquete de rede. Também é útil para encontrar vazamentos de memória.
  • pqos é fornecido pelo pacote intel-cmt-cat. Ele monitora e controla o cache da CPU e a largura de banda de memória em processadores Intel recentes.

Recursos adicionais

  • Para mais informações, consulte as páginas de homens de pcp, top, ps, vmstat, sar, perf, iostat, irqbalance, ss, numastat, numad, valgrind, e pqos.
  • Para maiores informações em pcp, veja a documentação no diretório /usr/share/doc/.
  • Para mais informações sobre o valor await e o que pode fazer com que seus valores sejam altos, veja o artigo da Red Hat Knowledgebase: Qual é exatamente o significado do valor "esperar" relatado pelo iostat?

Capítulo 2. Começando com Tuned

Como administrador do sistema, você pode usar o aplicativo Tuned para otimizar o perfil de desempenho de seu sistema para uma variedade de casos de uso.

2.1. O propósito de Tuned

Tuned é um serviço que monitora seu sistema e otimiza o desempenho sob certas cargas de trabalho. O núcleo do Tuned é profiles, que afina seu sistema para diferentes casos de uso.

Tuned é distribuído com uma série de perfis pré-definidos para casos de uso, como por exemplo:

  • Alto rendimento
  • Baixa latência
  • Economia de energia

É possível modificar as regras definidas para cada perfil e personalizar a afinação de um determinado dispositivo. Ao mudar para outro perfil ou desativar Tuned, todas as mudanças feitas nas configurações do sistema pelo perfil anterior retornam ao seu estado original.

Você também pode configurar Tuned para reagir às mudanças no uso do dispositivo e ajustar as configurações para melhorar o desempenho dos dispositivos ativos e reduzir o consumo de energia dos dispositivos inativos.

2.2. Perfis afinados

Uma análise detalhada de um sistema pode ser muito demorada. Tuned fornece uma série de perfis pré-definidos para casos de uso típico. Você também pode criar, modificar e excluir perfis.

Os perfis fornecidos com Tuned estão divididos nas seguintes categorias:

  • Perfis de economia de energia
  • Perfis de aumento de desempenho

Os perfis de aumento de desempenho incluem perfis que se concentram nos seguintes aspectos:

  • Baixa latência para armazenamento e rede
  • Alto rendimento para armazenamento e rede
  • Desempenho da máquina virtual
  • Desempenho do host de virtualização
O perfil padrão

Durante a instalação, o melhor perfil para seu sistema é selecionado automaticamente. Atualmente, o perfil padrão é selecionado de acordo com as seguintes regras personalizáveis:

Meio AmbientePerfil padrãoObjetivo

Nós de cálculo

throughput-performance

O melhor desempenho em termos de rendimento

Máquinas virtuais

virtual-guest

O melhor desempenho. Se você não estiver interessado no melhor desempenho, você pode mudá-lo para o perfil balanced ou powersave.

Outros casos

balanced

Desempenho equilibrado e consumo de energia

Perfis fundidos

Como uma característica experimental, é possível selecionar mais perfis de uma vez. Tuned tentará fundi-los durante a carga.

Se houver conflitos, as configurações do último perfil especificado têm precedência.

Exemplo 2.1. Baixo consumo de energia em um convidado virtual

O exemplo a seguir otimiza o sistema para funcionar em uma máquina virtual para o melhor desempenho e, ao mesmo tempo, sintoniza-o para baixo consumo de energia, enquanto o baixo consumo de energia é a prioridade:

# Perfil do convidado virtual de perfil afinado powersave
Atenção

A fusão é feita automaticamente sem verificar se a combinação de parâmetros resultante faz sentido. Conseqüentemente, a característica pode afinar alguns parâmetros da maneira oposta, o que pode ser contraproducente: por exemplo, ajustando o disco para alta produção usando o perfil throughput-performance e, simultaneamente, ajustando o spindown do disco para o valor baixo pelo perfil spindown-disk.

A localização dos perfis

Tuned armazena perfis nos seguintes diretórios:

/usr/lib/tuned/
Os perfis específicos de distribuição são armazenados no diretório. Cada perfil tem seu próprio diretório. O perfil consiste no arquivo principal de configuração chamado tuned.conf, e opcionalmente outros arquivos, por exemplo, scripts de ajuda.
/etc/tuned/
Se você precisar personalizar um perfil, copie o diretório de perfis para o diretório, que é usado para perfis personalizados. Se houver dois perfis com o mesmo nome, é usado o perfil personalizado localizado em /etc/tuned/.
A sintaxe da configuração do perfil

O arquivo tuned.conf pode conter uma seção [main] e outras seções para a configuração de instâncias de plug-in. Entretanto, todas as seções são opcionais.

As linhas que começam com o sinal de hash (#) são comentários.

Recursos adicionais

  • A página do homem tuned.conf(5).

2.3. Perfis afinados distribuídos com a RHEL

A seguir está uma lista de perfis que estão instalados com Tuned no Red Hat Enterprise Linux.

Nota

Pode haver mais perfis de produtos específicos ou de terceiros Tuned disponíveis. Tais perfis são normalmente fornecidos por pacotes de RPM separados.

balanced
O perfil padrão de economia de energia. Pretende-se que seja um compromisso entre desempenho e consumo de energia. Utiliza o autoescalonamento e o autoajuste sempre que possível. O único inconveniente é o aumento da latência. No atual lançamento Tuned, ele habilita a CPU, disco, áudio e plugins de vídeo, e ativa o governador da CPU conservative. A opção radeon_powersave usa o valor dpm-balanced se for suportado, caso contrário, está configurada para auto.
powersave

Um perfil para o máximo desempenho de economia de energia. Ele pode acelerar o desempenho a fim de minimizar o consumo real de energia. No atual lançamento Tuned, ele permite autosuspendência USB, economia de energia WiFi e economia de energia de Link Power Management (ALPM) agressivo para adaptadores host SATA. Ele também programa economia de energia para sistemas com uma baixa taxa de despertar e ativa o regulador ondemand. Ele permite economia de energia de áudio AC97 ou, dependendo de seu sistema, economia de energia HDA-Intel com um timeout de 10 segundos. Se seu sistema contém uma placa gráfica Radeon suportada com KMS habilitado, o perfil a configura para economia automática de energia. Nos PCs ASUS Eee, um Motor Super Híbrido dinâmico é habilitado.

Nota

Em certos casos, o perfil balanced é mais eficiente em comparação com o perfil powersave.

Considere que há uma quantidade definida de trabalho que precisa ser feita, por exemplo, um arquivo de vídeo que precisa ser transcodificado. Sua máquina pode consumir menos energia se a transcodificação for feita na potência total, porque a tarefa é concluída rapidamente, a máquina começa a ficar ociosa, e pode automaticamente descer para modos de economia de energia muito eficientes. Por outro lado, se você transcodificar o arquivo com uma máquina estrangulada, a máquina consome menos energia durante a transcodificação, mas o processo leva mais tempo e a energia total consumida pode ser maior.

É por isso que o perfil balanced pode ser geralmente uma opção melhor.

throughput-performance
Um perfil de servidor otimizado para alta taxa de transferência. Ele desabilita mecanismos de economia de energia e permite configurações do sysctl que melhoram o desempenho de rendimento do disco e do IO da rede. O regulador de CPU está configurado para performance.
latency-performance
Um perfil de servidor otimizado para baixa latência. Ele desativa os mecanismos de economia de energia e permite a configuração do sysctl que melhora a latência. O governador da CPU está configurado para performance e a CPU está bloqueada para os estados de baixa C (por PM QoS).
network-latency
Um perfil para ajuste de rede de baixa latência. Ele se baseia no perfil latency-performance. Além disso, desativa o balanceamento de páginas enormes transparentes e NUMA, e ajusta vários outros parâmetros sysctl relacionados à rede.
network-throughput
Um perfil para a sintonia da rede de produção. Ele se baseia no perfil throughput-performance. Além disso, aumenta os buffers de rede do kernel.
virtual-guest
Um perfil projetado para máquinas virtuais Red Hat Enterprise Linux 8 e convidados VMWare com base no perfil throughput-performance que, entre outras tarefas, diminui a troca de memória virtual e aumenta os valores de readahead de disco. Ele não desabilita as barreiras de disco.
virtual-host
Um perfil projetado para hosts virtuais com base no perfil throughput-performance que, entre outras tarefas, diminui a troca de memória virtual, aumenta os valores de readahead de disco e permite um valor mais agressivo de writeback de páginas sujas.
oracle
Um perfil otimizado para cargas de bancos de dados Oracle baseado no perfil throughput-performance. Além disso, ele desativa páginas enormes transparentes e modifica outros parâmetros do kernel relacionados ao desempenho. Este perfil é fornecido pelo pacote tuned-profiles-oracle.
desktop
Um perfil otimizado para desktops, com base no perfil balanced. Além disso, permite a criação de autogrupos programados para uma melhor resposta das aplicações interativas.
cpu-partitioning

O perfil cpu-partitioning separa as CPUs do sistema em CPUs isoladas e domésticas. Para reduzir o jitter e as interrupções em uma CPU isolada, o perfil limpa a CPU isolada dos processos de espaço do usuário, dos fios móveis do kernel, dos manipuladores de interrupção e dos temporizadores do kernel.

Uma CPU de manutenção doméstica pode executar todos os serviços, processos shell e fios de kernel.

Você pode configurar o perfil cpu-partitioning no arquivo /etc/tuned/cpu-partitioning-variables.conf. As opções de configuração são:

isolated_cores=cpu-list
Lista CPUs a serem isoladas. A lista de CPUs isoladas é separada por vírgulas ou o usuário pode especificar o intervalo. É possível especificar um intervalo usando um traço, como por exemplo 3-5. Esta opção é obrigatória. Qualquer CPU em falta nesta lista é automaticamente considerada uma CPU doméstica.
no_balance_cores=cpu-list
Lista as CPUs que não são consideradas pelo núcleo durante o balanceamento de carga do processo em todo o sistema. Esta opção é opcional. Esta é normalmente a mesma lista que a isolated_cores.

Para mais informações em cpu-partitioning, consulte a página de manual tuned-profiles-cpu-partitioning(7).

postgresql
Um perfil otimizado para cargas de bancos de dados PostgreSQL baseado no perfil throughput-performance. Além disso, ele desativa páginas enormes transparentes e modifica outros parâmetros do kernel relacionados ao desempenho. Este perfil é fornecido pelo pacote tuned-profiles-postgresql.
Perfis em tempo real

Os perfis em tempo real são destinados a sistemas que executam o núcleo em tempo real. Sem uma construção especial do kernel, eles não configuram o sistema para ser em tempo real. Na RHEL, os perfis estão disponíveis a partir de repositórios adicionais.

Os seguintes perfis em tempo real estão disponíveis:

realtime

Utilização em sistemas de tempo real de metais nulos.

Fornecido pelo pacote tuned-profiles-realtime, que está disponível a partir dos repositórios RT ou NFV.

realtime-virtual-host

Utilização em um host de virtualização configurado para tempo real.

Fornecido pelo pacote tuned-profiles-nfv-host, que está disponível no repositório da NFV.

realtime-virtual-guest

Utilização em um convidado de virtualização configurado para tempo real.

Fornecido pelo pacote tuned-profiles-nfv-guest, que está disponível no repositório da NFV.

2.4. Sintonia estática e dinâmica em Tuned

Esta seção explica a diferença entre as duas categorias de ajuste de sistemas que se aplicam a Tuned: static e dynamic.

Sintonia estática
Consiste principalmente na aplicação de configurações predefinidas de sysctl e sysfs e na ativação de várias ferramentas de configuração, como ethtool.
Sintonia dinâmica

Observa como vários componentes do sistema são usados durante o tempo de funcionamento de seu sistema. Tuned ajusta as configurações do sistema dinamicamente com base nessas informações de monitoramento.

Por exemplo, o disco rígido é muito usado durante a inicialização e o login, mas mal é usado mais tarde quando o usuário pode trabalhar principalmente com aplicações como navegadores web ou clientes de e-mail. Da mesma forma, a CPU e os dispositivos de rede são usados de forma diferente em momentos diferentes. Tuned monitora a atividade destes componentes e reage às mudanças em seu uso.

Por padrão, a sintonia dinâmica está desativada. Para ativá-la, edite o arquivo /etc/tuned/tuned-main.conf e mude a opção dynamic_tuning para 1. Tuned então periodicamente analisa as estatísticas do sistema e as utiliza para atualizar suas configurações de ajuste do sistema. Para configurar o intervalo de tempo em segundos entre estas atualizações, use a opção update_interval.

Os algoritmos de ajuste dinâmico atualmente implementados tentam equilibrar o desempenho e o poder de corte, e por isso são desativados nos perfis de desempenho. O ajuste dinâmico para plug-ins individuais pode ser habilitado ou desabilitado nos perfis Tuned.

Exemplo 2.2. Sintonia estática e dinâmica em uma estação de trabalho

Em uma estação de trabalho típica do escritório, a interface de rede Ethernet está inativa a maior parte do tempo. Apenas alguns poucos e-mails entram e saem ou algumas páginas da web podem ser carregadas.

Para esses tipos de cargas, a interface de rede não precisa funcionar a toda velocidade o tempo todo, como faz por padrão. Tuned tem um plug-in de monitoramento e ajuste para dispositivos de rede que podem detectar essa baixa atividade e depois baixar automaticamente a velocidade dessa interface, resultando normalmente em um menor consumo de energia.

Se a atividade na interface aumenta por um período de tempo maior, por exemplo, porque uma imagem de DVD está sendo baixada ou um e-mail com um anexo grande é aberto, Tuned detecta isso e define a velocidade máxima da interface para oferecer o melhor desempenho enquanto o nível de atividade é alto.

Este princípio é usado para outros plug-ins para CPU e discos também.

2.5. Modo sintonizado sem demônio

Você pode rodar Tuned no modo no-daemon, que não requer nenhuma memória residente. Neste modo, Tuned aplica as configurações e as saídas.

Por padrão, o modo no-daemon está desativado porque falta muita funcionalidade Tuned neste modo, inclusive:

  • Apoio D-Bus
  • Suporte a hot-plug
  • Suporte Rollback para configurações

Para ativar o modo no-daemon, inclua a seguinte linha no arquivo /etc/tuned/tuned-main.conf:

daemon = 0

2.6. Instalando e habilitando o Tuned

Este procedimento instala e habilita o aplicativo Tuned, instala perfis Tuned e pré-define um perfil padrão Tuned para seu sistema.

Procedimento

  1. Instale o pacote tuned:

    # yum instalar afinado
  2. Habilite e inicie o serviço tuned:

    # systemctl habilitado --agora sintonizado
  3. Opcionalmente, instale os perfis Tuned para sistemas em tempo real:

    # yum instalar perfis sintonizados - perfis sintonizados em tempo real-nfv
  4. Verificar se um perfil Tuned está ativo e aplicado:

    $ tuned-adm active
    
    Current active profile: balanced
    $ tuned-adm verify
    
    Verfication succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

2.7. Listagem de perfis afinados disponíveis

Este procedimento lista todos os perfis Tuned que estão atualmente disponíveis em seu sistema.

Procedimento

  • Para listar todos os perfis disponíveis Tuned em seu sistema, use:

    $ tuned-adm list
    
    Available profiles:
    - balanced               - General non-specialized tuned profile
    - desktop                - Optimize for the desktop use-case
    - latency-performance    - Optimize for deterministic performance at the cost of increased power consumption
    - network-latency        - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
    - network-throughput     - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
    - powersave              - Optimize for low power consumption
    - throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
    - virtual-guest          - Optimize for running inside a virtual guest
    - virtual-host           - Optimize for running KVM guests
    Current active profile: balanced
  • Para exibir apenas o perfil atualmente ativo, use:

    $ tuned-adm active
    
    Current active profile: balanced

Recursos adicionais

  • A página do homem tuned-adm(8).

2.8. Definição de um perfil afinado

Este procedimento ativa um perfil Tuned selecionado em seu sistema.

Pré-requisitos

Procedimento

  1. Opcionalmente, você pode deixar Tuned recomendar o perfil mais adequado para seu sistema:

    # tuned-adm recommend
    
    balanced
  2. Ativar um perfil:

    # perfil afinado-adm selected-profile

    Alternativamente, você pode ativar uma combinação de vários perfis:

    # perfil afinado-adm profile1 profile2

    Exemplo 2.3. Uma máquina virtual otimizada para baixo consumo de energia

    O exemplo a seguir otimiza o sistema para funcionar em uma máquina virtual com o melhor desempenho e, ao mesmo tempo, o afina para um baixo consumo de energia, enquanto o baixo consumo de energia é a prioridade:

    # Perfil do convidado virtual de perfil afinado powersave
  3. Veja o perfil atual ativo Tuned em seu sistema:

    # tuned-adm active
    
    Current active profile: selected-profile
  4. Reinicie o sistema:

    # reinicialização

Etapas de verificação

  • Verifique se o perfil Tuned está ativo e aplicado:

    $ tuned-adm verify
    
    Verfication succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Recursos adicionais

  • A página do homem tuned-adm(8)

2.9. Desabilitando Tuned

Este procedimento desativa Tuned e redefine todas as configurações do sistema afetado para seu estado original antes de Tuned modificá-las.

Procedimento

  • Para desativar todas as afinações temporariamente:

    # tuned-adm off

    As afinações são aplicadas novamente após o reinício do serviço tuned.

  • Alternativamente, para parar e desativar o serviço tuned permanentemente:

    # systemctl desativar --agora sintonizado

Recursos adicionais

  • A página do homem tuned-adm(8).

Capítulo 3. Personalização de perfis afinados

Você pode criar ou modificar os perfis Tuned para otimizar o desempenho do sistema para seu caso de uso pretendido.

Pré-requisitos

3.1. Perfis afinados

Uma análise detalhada de um sistema pode ser muito demorada. Tuned fornece uma série de perfis pré-definidos para casos de uso típico. Você também pode criar, modificar e excluir perfis.

Os perfis fornecidos com Tuned estão divididos nas seguintes categorias:

  • Perfis de economia de energia
  • Perfis de aumento de desempenho

Os perfis de aumento de desempenho incluem perfis que se concentram nos seguintes aspectos:

  • Baixa latência para armazenamento e rede
  • Alto rendimento para armazenamento e rede
  • Desempenho da máquina virtual
  • Desempenho do host de virtualização
O perfil padrão

Durante a instalação, o melhor perfil para seu sistema é selecionado automaticamente. Atualmente, o perfil padrão é selecionado de acordo com as seguintes regras personalizáveis:

Meio AmbientePerfil padrãoObjetivo

Nós de cálculo

throughput-performance

O melhor desempenho em termos de rendimento

Máquinas virtuais

virtual-guest

O melhor desempenho. Se você não estiver interessado no melhor desempenho, você pode mudá-lo para o perfil balanced ou powersave.

Outros casos

balanced

Desempenho equilibrado e consumo de energia

Perfis fundidos

Como uma característica experimental, é possível selecionar mais perfis de uma vez. Tuned tentará fundi-los durante a carga.

Se houver conflitos, as configurações do último perfil especificado têm precedência.

Exemplo 3.1. Baixo consumo de energia em um convidado virtual

O exemplo a seguir otimiza o sistema para funcionar em uma máquina virtual para o melhor desempenho e, ao mesmo tempo, sintoniza-o para baixo consumo de energia, enquanto o baixo consumo de energia é a prioridade:

# Perfil do convidado virtual de perfil afinado powersave
Atenção

A fusão é feita automaticamente sem verificar se a combinação de parâmetros resultante faz sentido. Conseqüentemente, a característica pode afinar alguns parâmetros da maneira oposta, o que pode ser contraproducente: por exemplo, ajustando o disco para alta produção usando o perfil throughput-performance e, simultaneamente, ajustando o spindown do disco para o valor baixo pelo perfil spindown-disk.

A localização dos perfis

Tuned armazena perfis nos seguintes diretórios:

/usr/lib/tuned/
Os perfis específicos de distribuição são armazenados no diretório. Cada perfil tem seu próprio diretório. O perfil consiste no arquivo principal de configuração chamado tuned.conf, e opcionalmente outros arquivos, por exemplo, scripts de ajuda.
/etc/tuned/
Se você precisar personalizar um perfil, copie o diretório de perfis para o diretório, que é usado para perfis personalizados. Se houver dois perfis com o mesmo nome, é usado o perfil personalizado localizado em /etc/tuned/.
A sintaxe da configuração do perfil

O arquivo tuned.conf pode conter uma seção [main] e outras seções para a configuração de instâncias de plug-in. Entretanto, todas as seções são opcionais.

As linhas que começam com o sinal de hash (#) são comentários.

Recursos adicionais

  • A página do homem tuned.conf(5).

3.2. Herança entre perfis afinados

Tuned os perfis podem ser baseados em outros perfis e modificar apenas certos aspectos de seu perfil pai.

A seção [main] de Tuned perfis reconhece a opção include:

[main]
include=parent

Todas as configurações do parent são carregados neste perfil child. Nas seções seguintes, o perfil child pode substituir certas configurações herdadas do parent perfil ou adicionar novas configurações não presentes no parent perfil.

Você pode criar seu próprio perfil child no diretório /etc/tuned/ com base em um perfil pré-instalado em /usr/lib/tuned/ com apenas alguns parâmetros ajustados.

Se o parent perfil é atualizado, tal como após uma atualização em Tuned, as mudanças são refletidas no perfil child.

Exemplo 3.2. Um perfil de economia de energia baseado em

A seguir, um exemplo de um perfil personalizado que estende o perfil balanced e define o Aggressive Link Power Management (ALPM) para todos os dispositivos até a máxima economia de energia.

[main]
include=balanced

[scsi_host]
alpm=min_power

Recursos adicionais

  • A página do homem tuned.conf(5)

3.3. Sintonia estática e dinâmica em Tuned

Esta seção explica a diferença entre as duas categorias de ajuste de sistemas que se aplicam a Tuned: static e dynamic.

Sintonia estática
Consiste principalmente na aplicação de configurações predefinidas de sysctl e sysfs e na ativação de várias ferramentas de configuração, como ethtool.
Sintonia dinâmica

Observa como vários componentes do sistema são usados durante o tempo de funcionamento de seu sistema. Tuned ajusta as configurações do sistema dinamicamente com base nessas informações de monitoramento.

Por exemplo, o disco rígido é muito usado durante a inicialização e o login, mas mal é usado mais tarde quando o usuário pode trabalhar principalmente com aplicações como navegadores web ou clientes de e-mail. Da mesma forma, a CPU e os dispositivos de rede são usados de forma diferente em momentos diferentes. Tuned monitora a atividade destes componentes e reage às mudanças em seu uso.

Por padrão, a sintonia dinâmica está desativada. Para ativá-la, edite o arquivo /etc/tuned/tuned-main.conf e mude a opção dynamic_tuning para 1. Tuned então periodicamente analisa as estatísticas do sistema e as utiliza para atualizar suas configurações de ajuste do sistema. Para configurar o intervalo de tempo em segundos entre estas atualizações, use a opção update_interval.

Os algoritmos de ajuste dinâmico atualmente implementados tentam equilibrar o desempenho e o poder de corte, e por isso são desativados nos perfis de desempenho. O ajuste dinâmico para plug-ins individuais pode ser habilitado ou desabilitado nos perfis Tuned.

Exemplo 3.3. Sintonia estática e dinâmica em uma estação de trabalho

Em uma estação de trabalho típica do escritório, a interface de rede Ethernet está inativa a maior parte do tempo. Apenas alguns poucos e-mails entram e saem ou algumas páginas da web podem ser carregadas.

Para esses tipos de cargas, a interface de rede não precisa funcionar a toda velocidade o tempo todo, como faz por padrão. Tuned tem um plug-in de monitoramento e ajuste para dispositivos de rede que podem detectar essa baixa atividade e depois baixar automaticamente a velocidade dessa interface, resultando normalmente em um menor consumo de energia.

Se a atividade na interface aumenta por um período de tempo maior, por exemplo, porque uma imagem de DVD está sendo baixada ou um e-mail com um anexo grande é aberto, Tuned detecta isso e define a velocidade máxima da interface para oferecer o melhor desempenho enquanto o nível de atividade é alto.

Este princípio é usado para outros plug-ins para CPU e discos também.

3.4. Plug-ins afinados

Os plug-ins são módulos em perfis Tuned que Tuned usa para monitorar ou otimizar diferentes dispositivos no sistema.

Tuned utiliza dois tipos de plug-ins:

  • plug-ins de monitoramento
  • plug-ins de afinação
Plug-ins de monitoramento

Os plug-ins de monitoramento são usados para obter informações de um sistema em funcionamento. A saída dos plug-ins de monitoramento pode ser usada sintonizando os plug-ins para o ajuste dinâmico.

Os plug-ins de monitoramento são automaticamente instanciados sempre que suas métricas são necessárias por qualquer um dos plug-ins de ajuste habilitados. Se dois plug-ins de ajuste requerem os mesmos dados, apenas uma instância do plug-in de monitoramento é criada e os dados são compartilhados.

Plug-ins de afinação

Cada plug-in de sintonia sintoniza um subsistema individual e toma vários parâmetros que são povoados a partir dos perfis sintonizados. Cada subsistema pode ter vários dispositivos, tais como CPUs múltiplas ou placas de rede, que são tratados por instâncias individuais dos plug-ins de sintonização. Configurações específicas para dispositivos individuais também são suportadas.

Sintaxe para plug-ins em perfis afinados

As seções que descrevem as instâncias de plug-in são formatadas da seguinte forma:

[NAME]
type=TYPE
devices=DEVICES
NOME
é o nome da instância de plug-in como é usada nos logs. Pode ser uma cadeia arbitrária.
TIPO
é o tipo do plug-in de sintonia.
DISPOSITIVOS

é a lista de dispositivos que esta instância de plug-in manipula.

A linha devices pode conter uma lista, um wildcard (*), e negação (!). Se não houver uma linha devices, todos os dispositivos presentes ou posteriormente anexados no sistema do TYPE são tratados pela instância de plug-in. Isto é o mesmo que usar a opção devices=*.

Exemplo 3.4. Dispositivos de blocos de encaixe com um plug-in

O exemplo a seguir corresponde a todos os dispositivos de bloco que começam com sd, como sda ou sdb, e não desabilita as barreiras sobre eles:

[data_disk]
type=disk
devices=sd*
disable_barriers=false

O exemplo a seguir corresponde a todos os dispositivos de bloco, exceto sda1 e sda2:

[data_disk]
type=disk
devices=!sda1, !sda2
disable_barriers=false

Se nenhuma instância de um plug-in for especificada, o plug-in não é ativado.

Se o plug-in suportar mais opções, elas também podem ser especificadas na seção plug-in. Se a opção não for especificada e não tiver sido previamente especificada no plug-in incluído, o valor padrão é usado.

Sintaxe curta do plug-in

Se você não precisar de nomes personalizados para a instância plug-in e houver apenas uma definição da instância em seu arquivo de configuração, Tuned suporta a seguinte sintaxe curta:

[TYPE]
devices=DEVICES

Neste caso, é possível omitir a linha type. A instância é então referenciada com um nome, igual ao tipo. O exemplo anterior poderia então ser reescrito:

Exemplo 3.5. Dispositivos de blocos de correspondência usando a sintaxe curta

[disk]
devices=sdb*
disable_barriers=false
Definições conflitantes de plug-in em um perfil

Se a mesma seção for especificada mais de uma vez usando a opção include, as configurações são fundidas. Se não puderem ser fundidas devido a um conflito, a última definição conflitante se sobrepõe às definições anteriores. Se você não souber o que foi definido anteriormente, você pode usar a opção replace Boolean e defini-la para true. Isto faz com que todas as definições anteriores com o mesmo nome sejam sobrescritas e a fusão não acontece.

Você também pode desativar o plug-in especificando a opção enabled=false. Isto tem o mesmo efeito como se a instância nunca tivesse sido definida. Desativar o plug-in é útil se você estiver redefinindo a definição anterior a partir da opção include e não quiser que o plug-in esteja ativo em seu perfil personalizado.

Funcionalidade não implementada em nenhum plug-in

Tuned inclui a capacidade de executar qualquer comando de shell como parte da habilitação ou desativação de um perfil de ajuste. Isto permite estender os perfis Tuned com funcionalidades que ainda não foram integradas no Tuned.

Você pode especificar comandos de shell arbitrários usando o plug-in script.

Recursos adicionais

  • A página do homem tuned.conf(5)

3.5. Plug-ins afinados disponíveis

Esta seção lista todos os plug-ins de monitoramento e sintonia atualmente disponíveis em Tuned.

Plug-ins de monitoramento

Atualmente, são implementados os seguintes plug-ins de monitoramento:

disk
Obtém carga em disco (número de operações IO) por dispositivo e intervalo de medição.
net
Obtém carga de rede (número de pacotes transferidos) por placa de rede e intervalo de medição.
load
Obtém carga de CPU por CPU e intervalo de medição.
Plug-ins de afinação

Atualmente, são implementados os seguintes plug-ins de ajuste. Apenas alguns desses plug-ins implementam o ajuste dinâmico. As opções suportadas pelos plug-ins também são listadas:

cpu

Define o regulador da CPU para o valor especificado pela opção governor e muda dinamicamente a latência de Acesso Direto à Memória da CPU (DMA) da Qualidade de Serviço (PM QoS) de acordo com a carga da CPU.

Se a carga da CPU for inferior ao valor especificado pela opção load_threshold, a latência é definida para o valor especificado pela opção latency_high, caso contrário, é definida para o valor especificado por latency_low.

Você também pode forçar a latência a um valor específico e impedi-la de mudar dinamicamente ainda mais. Para fazer isso, defina a opção force_latency para o valor de latência necessário.

eeepc_she

Define dinamicamente a velocidade do barramento frontal (FSB) de acordo com a carga da CPU.

Esta característica pode ser encontrada em alguns netbooks e também é conhecida como o ASUS Super Hybrid Engine (SHE).

Se a carga da CPU for menor ou igual ao valor especificado pela opção load_threshold_powersave, o plug-in define a velocidade da FSB para o valor especificado pela opção she_powersave. Se a carga da CPU for maior ou igual ao valor especificado pela opção load_threshold_normal, ela define a velocidade FSB para o valor especificado pela opção she_normal.

O ajuste estático não é suportado e o plug-in é desabilitado de forma transparente se Tuned não detectar o suporte de hardware para este recurso.

net
Configura a funcionalidade Wake-on-LAN para os valores especificados pela opção wake_on_lan. Utiliza a mesma sintaxe que o utilitário ethtool. Também muda dinamicamente a velocidade da interface de acordo com a utilização da interface.
sysctl

Define várias configurações sysctl especificadas pelas opções de plug-in.

A sintaxe é name=valueonde name é o mesmo que o nome fornecido pela concessionária sysctl.

Use o plug-in sysctl se você precisar alterar as configurações do sistema que não são cobertas por outros plug-ins disponíveis em Tuned. Se as configurações forem cobertas por alguns plug-ins específicos, prefira estes plug-ins.

usb

Define o timeout automático dos dispositivos USB para o valor especificado pelo parâmetro autosuspend.

O valor 0 significa que o autosuspend é desativado.

vm

Permite ou desativa páginas enormes transparentes, dependendo do valor da opção transparent_hugepages.

Os valores válidos da opção transparent_hugepages são:

  • "sempre"..
  • "nunca"..
  • "madvise"
audio

Define o tempo limite autosuspendido para os codecs de áudio para o valor especificado pela opção timeout.

Atualmente, os codecs snd_hda_intel e snd_ac97_codec são suportados. O valor 0 significa que o autosuspend está desativado. Você também pode fazer com que o controlador seja reinicializado configurando a opção booleana reset_controller para true.

disk

Define o elevador de discos para o valor especificado pela opção elevator.

Também se define:

  • APM para o valor especificado pela opção apm
  • Escalonador quantum para o valor especificado pela opção scheduler_quantum
  • Tempo limite de spindown do disco para o valor especificado pela opção spindown
  • Disco readahead para o valor especificado pelo parâmetro readahead
  • O disco atual readahead a um valor multiplicado pela constante especificada pela opção readahead_multiply

Além disso, este plug-in muda dinamicamente o gerenciamento avançado de energia e a configuração de spindown timeout para o acionamento de acordo com a utilização atual do acionamento. O ajuste dinâmico pode ser controlado pela opção Booleana dynamic e é ativado por padrão.

scsi_host

Opções de sintonia para os anfitriões SCSI.

Estabelece o Aggressive Link Power Management (ALPM) para o valor especificado pela opção alpm.

mounts
Ativa ou desativa barreiras para montagens de acordo com o valor booleano da opção disable_barriers.
script

Executa um script externo ou binário quando o perfil é carregado ou descarregado. Você pode escolher um executável arbitrário.

Importante

O plug-in script é fornecido principalmente para compatibilidade com versões anteriores. Prefira outros plug-ins Tuned se eles cobrirem a funcionalidade necessária.

Tuned chama o executável com um dos seguintes argumentos:

  • start ao carregar o perfil
  • stop ao descarregar o perfil

Você precisa implementar corretamente a ação stop em seu executável e reverter todas as configurações que você alterou durante a ação start. Caso contrário, o passo de retrocesso após a mudança de seu perfil Tuned não funcionará.

Os scripts Bash podem importar a biblioteca /usr/lib/tuned/functions Bash e utilizar as funções aí definidas. Use estas funções somente para funcionalidades que não são fornecidas nativamente por Tuned. Se o nome de uma função começa com um sublinhado, como _wifi_set_power_level, considere a função privada e não a utilize em seus scripts, pois ela pode mudar no futuro.

Especifique o caminho para o executável usando o parâmetro script na configuração do plug-in.

Exemplo 3.6. Executando um Bash script a partir de um perfil

Para executar um script Bash chamado script.sh que está localizado no diretório de perfis, use:

[script]
script=${i:PROFILE_DIR}/script.sh
sysfs

Define várias configurações sysfs especificadas pelas opções de plug-in.

A sintaxe é name=valueonde name é o caminho sysfs a ser utilizado.

Use este plug-in caso precise alterar algumas configurações que não são cobertas por outros plug-ins. Prefira plug-ins específicos se eles cobrirem as configurações necessárias.

video

Estabelece vários níveis de segurança de energia em placas de vídeo. Atualmente, somente os cartões Radeon são suportados.

O nível de powersave pode ser especificado usando a opção radeon_powersave. Os valores suportados são:

  • default
  • auto
  • low
  • mid
  • high
  • dynpm
  • dpm-battery
  • dpm-balanced
  • dpm-perfomance

Para obter detalhes, consulte www.x.org. Observe que este plug-in é experimental e a opção pode mudar em lançamentos futuros.

bootloader

Adiciona opções à linha de comando do kernel. Este plug-in suporta apenas o carregador de inicialização GRUB 2.

A localização personalizada não padrão do arquivo de configuração do GRUB 2 pode ser especificada pela opção grub2_cfg_file.

As opções do kernel são adicionadas à configuração atual do GRUB e seus modelos. O sistema precisa ser reinicializado para que as opções do kernel entrem em vigor.

A mudança para outro perfil ou a parada manual do serviço tuned remove as opções adicionais. Se você desligar ou reinicializar o sistema, as opções do kernel persistem no arquivo grub.cfg.

As opções de kernel podem ser especificadas pela seguinte sintaxe:

cmdline=arg1 arg2 .. argN

Exemplo 3.7. Modificando a linha de comando do kernel

Por exemplo, para adicionar a opção quiet a um perfil Tuned, inclua as seguintes linhas no arquivo tuned.conf:

[bootloader]
cmdline=quiet

A seguir, um exemplo de um perfil personalizado que adiciona a opção isolcpus=2 à linha de comando do kernel:

[bootloader]
cmdline=isolcpus=2

3.6. Variáveis e funções incorporadas em perfis sintonizados

Variáveis e funções incorporadas se expandem em tempo de execução quando um perfil Tuned é ativado.

O uso das variáveis Tuned reduz a quantidade de digitação necessária nos perfis Tuned. Você também pode:

  • Usar várias funções embutidas junto com variáveis Tuned
  • Criar funções personalizadas em Python e adicioná-las a Tuned sob a forma de plug-ins
Variáveis

Não há variáveis pré-definidas nos perfis Tuned. Você pode definir suas próprias variáveis, criando a seção [variables] em um perfil e usando a seguinte sintaxe:

[variables]

variable_name=value

Para expandir o valor de uma variável em um perfil, use a seguinte sintaxe:

${variable_name}

Exemplo 3.8. Isolamento de núcleos de CPU usando variáveis

No exemplo a seguir, a variável ${isolated_cores} se expande para 1,2; daí as botas do kernel com a opção isolcpus=1,2:

[variables]
isolated_cores=1,2

[bootloader]
cmdline=isolcpus=${isolated_cores}

As variáveis podem ser especificadas em um arquivo separado. Por exemplo, você pode adicionar as seguintes linhas a tuned.conf:

[variables]
include=/etc/tuned/my-variables.conf

[bootloader]
cmdline=isolcpus=${isolated_cores}

Se você adicionar a opção isolated_cores=1,2 ao arquivo /etc/tuned/my-variables.conf, o kernel boots com a opção isolcpus=1,2.

Funções

Para chamar uma função, use a seguinte sintaxe:

${f:function_name:argument_1:argument_2}

Para expandir o caminho do diretório onde o perfil e o arquivo tuned.conf estão localizados, use a função PROFILE_DIR, que requer uma sintaxe especial:

${i:PROFILE_DIR}

Exemplo 3.9. Isolamento de núcleos de CPU usando variáveis e funções incorporadas

No exemplo a seguir, a variável ${non_isolated_cores} se expande para 0,3-5, e a função embutida cpulist_invert é chamada com o argumento 0,3-5:

[variables]
non_isolated_cores=0,3-5

[bootloader]
cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}

A função cpulist_invert inverte a lista de CPUs. Para uma máquina com 6 CPUs, a inversão é 1,2, e a inicialização do kernel com a opção de linha de comando isolcpus=1,2.

Recursos adicionais

  • A página do homem tuned.conf(5)

3.7. Funções incorporadas disponíveis em perfis afinados

As seguintes funções embutidas estão disponíveis em todos os perfis Tuned:

PROFILE_DIR
Retorna o caminho do diretório onde o perfil e o arquivo tuned.conf estão localizados.
exec
Executa um processo e devolve sua produção.
assertion
Compara dois argumentos. Se eles do not match, a função registra o texto do primeiro argumento e aborta o carregamento do perfil.
assertion_non_equal
Compara dois argumentos. Se eles match, a função registra o texto do primeiro argumento e aborta o carregamento do perfil.
kb2s
Converte kilobytes em setores de disco.
s2kb
Converte setores de disco em quilobytes.
strip
Cria um cordão a partir de todos os argumentos passados e elimina tanto o espaço branco de chumbo quanto o branco de fuga.
virt_check

Verifica se Tuned está funcionando dentro de uma máquina virtual (VM) ou em metal nu:

  • Dentro de uma VM, a função retorna o primeiro argumento.
  • No metal nu, a função retorna o segundo argumento, mesmo no caso de um erro.
cpulist_invert
Inverte uma lista de CPUs para fazer seu complemento. Por exemplo, em um sistema com 4 CPUs, numeradas de 0 a 3, a inversão da lista 0,2,3 é 1.
cpulist2hex
Converte uma lista de CPU para uma máscara de CPU hexadecimal.
cpulist2hex_invert
Converte uma lista de CPU para uma máscara de CPU hexadecimal e a inverte.
hex2cpulist
Converte uma máscara hexadecimal de CPU em uma lista de CPU.
cpulist_online
Verifica se as CPUs da lista estão online. Retorna a lista contendo apenas CPUs online.
cpulist_present
Verifica se as CPUs da lista estão presentes. Retorna a lista contendo apenas as CPUs presentes.
cpulist_unpack
Desempacote uma lista de CPU na forma de 1-3,4 para 1,2,3,4.
cpulist_pack
Pacote uma lista de CPU na forma de 1,2,3,5 para 1-3,5.

3.8. Criação de novos perfis sintonizados

Este procedimento cria um novo perfil Tuned com regras de desempenho personalizadas.

Pré-requisitos

Procedimento

  1. No diretório /etc/tuned/, crie um novo diretório com o mesmo nome que o perfil que você deseja criar:

    # mkdir /etc/tuned/my-profile
  2. No novo diretório, crie um arquivo chamado tuned.conf. Adicione uma seção [main] e definições de plug-in nela, de acordo com suas exigências.

    Por exemplo, veja a configuração do perfil balanced:

    [main]
    summary=General non-specialized tuned profile
    
    [cpu]
    governor=conservative
    energy_perf_bias=normal
    
    [audio]
    timeout=10
    
    [video]
    radeon_powersave=dpm-balanced, auto
    
    [scsi_host]
    alpm=medium_power
  3. Para ativar o perfil, use:

    # perfil afinado-adm my-profile
  4. Verificar se o perfil Tuned está ativo e se as configurações do sistema estão aplicadas:

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verfication succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Recursos adicionais

  • A página do homem tuned.conf(5)

3.9. Modificação de perfis sintonizados existentes

Este procedimento cria um perfil infantil modificado com base em um perfil Tuned existente.

Pré-requisitos

Procedimento

  1. No diretório /etc/tuned/, crie um novo diretório com o mesmo nome que o perfil que você deseja criar:

    # mkdir /etc/tuned/modified-profile
  2. No novo diretório, crie um arquivo chamado tuned.conf, e defina a seção [main] como segue:

    [main]
    include=parent-profile

    Substitua parent-profile com o nome do perfil que você está modificando.

  3. Inclua suas modificações de perfil.

    Exemplo 3.10. Diminuindo a troca no perfil de desempenho de produção

    Para usar as configurações do perfil throughput-performance e alterar o valor de vm.swappiness para 5, em vez do valor padrão 10, use:

    [main]
    include=throughput-performance
    
    [sysctl]
    vm.swappiness=5
  4. Para ativar o perfil, use:

    # perfil afinado-adm modified-profile
  5. Verificar se o perfil Tuned está ativo e se as configurações do sistema estão aplicadas:

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verfication succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Recursos adicionais

  • A página do homem tuned.conf(5)

3.10. Ajuste do programador de discos usando o Tuned

Este procedimento cria e permite um perfil Tuned que define um determinado programador de discos para os dispositivos de bloco selecionados. A configuração persiste através de reinicializações do sistema.

Nos seguintes comandos e configurações, substitua:

  • device com o nome do dispositivo do bloco, por exemplo sdf
  • selected-scheduler com o programador de discos que você deseja definir para o dispositivo, por exemplo bfq

Pré-requisitos

Procedimento

  1. Opcional: Selecione um perfil existente em Tuned no qual seu perfil será baseado. Para uma lista dos perfis disponíveis, veja Seção 2.3, “Perfis afinados distribuídos com a RHEL”.

    Para ver qual perfil está atualmente ativo, use:

    $ tuned-adm ativo
  2. Crie um novo diretório para manter seu perfil em Tuned:

    # mkdir /etc/tuned/my-profile
  3. Encontre o identificador único do sistema do dispositivo de bloco selecionado:

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    Nota

    O comando neste exemplo retornará todos os valores identificados como um World Wide Name (WWN) ou número de série associado ao dispositivo de bloco especificado. Embora seja preferível usar um WWN, o WWN nem sempre está disponível para um determinado dispositivo e quaisquer valores retornados pelo comando do exemplo são aceitáveis para uso como o device system unique ID.

  4. Criar o /etc/tuned/my-profile/tuned.conf arquivo de configuração. No arquivo, defina as seguintes opções:

    • Opcional: Incluir um perfil existente:

      [main]
      include=existing-profile
    • Defina o programador de disco selecionado para o dispositivo que corresponda ao identificador da WWN:

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler
      • Substitua IDNAME com o nome do identificador a ser utilizado (por exemplo, ID_WWN).
      • Substitua device system unique id com o valor do identificador escolhido (por exemplo, 0x5002538d00000000).

      Para combinar vários dispositivos na opção devices_udev_regex, coloque os identificadores entre parênteses e separe-os com barras verticais:

    devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. Habilite seu perfil:

    # perfil afinado-adm my-profile
  6. Verificar se o perfil Sintonizado está ativo e aplicado:

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Recursos adicionais

Capítulo 4. Revisão de um sistema usando interface de atum

Use a ferramenta tuna para ajustar as sintonizações do programador, ajustar a prioridade da rosca, os manipuladores IRQ e isolar os núcleos e soquetes da CPU. O atum reduz a complexidade de executar tarefas de sintonização.

4.1. Instalando a ferramenta atum

A ferramenta tuna foi projetada para ser usada em um sistema em funcionamento. Isto permite que ferramentas de medição específicas da aplicação vejam e analisem o desempenho do sistema imediatamente após as mudanças terem sido feitas.

A ferramenta tuna realiza as seguintes operações:

  • Lista as CPUs em um sistema
  • Lista os pedidos de interrupção (IRQs) atualmente em funcionamento em um sistema
  • Altera a política e as informações prioritárias sobre os tópicos
  • Exibe as políticas e prioridades atuais de um sistema

Procedimento

  1. Para instalar a ferramenta tuna:

    # yum instalar atum
  2. Para exibir as opções disponíveis do tuna CLI:

    # atum -h

Recursos adicionais

  • A página do homem tuna.

4.2. Visualização do status do sistema usando a ferramenta atum

Este procedimento descreve como visualizar o status do sistema usando a ferramenta de interface de linha de comando (CLI) tuna.

Pré-requisitos

Procedimento

  • Para ver as políticas e prioridades atuais:

    # tuna --show_threads
                thread
    pid   SCHED_ rtpri affinity             cmd
    1      OTHER     0      0,1            init
    2       FIFO    99        0     migration/0
    3      OTHER     0        0     ksoftirqd/0
    4       FIFO    99        0      watchdog/0
  • Para visualizar uma linha específica correspondente a um PID ou que corresponda a um nome de comando:

    # Atum --threads=pid_or_cmd_list --show_threads

    O argumento pid_or_cmd_list é uma lista de PIDs separados por vírgula ou padrões de nomes de comando.

  • Para sintonizar as CPUs usando a tuna CLI, ver Seção 4.3, “Sintonia de CPUs usando a ferramenta atum”.
  • Para sintonizar os IRQs usando a ferramenta tuna, ver Seção 4.4, “Ajuste de IRQs usando ferramenta de atum”.
  • Para salvar a configuração alterada:

    # Atum --guardar= nome do arquivo

    Este comando salva atualmente apenas os fios do kernel em execução. Os processos que não estão em execução não são salvos.

Recursos adicionais

  • A página do homem tuna.
  • O comando tuna -h exibe as opções CLI disponíveis.

4.3. Sintonia de CPUs usando a ferramenta atum

Os comandos da ferramenta tuna podem ter como alvo CPUs individuais. Usando a ferramenta atum, você pode:

Isolate CPUs
Todas as tarefas executadas na CPU especificada passam para a próxima CPU disponível. O isolamento de uma CPU a torna indisponível, removendo-a da máscara de afinidade de todas as roscas.
Include CPUs
Permite que as tarefas sejam executadas na CPU especificada
Restore CPUs
Restaura a CPU especificada para sua configuração anterior.

Este procedimento descreve como sintonizar as CPUs usando o tuna CLI.

Pré-requisitos

Procedimento

  • Para especificar a lista de CPUs a serem afetadas por um comando:

    # atum --cpus=cpu_list [command]

    O argumento cpu_list é uma lista de números de CPU separados por vírgula. Por exemplo, --cpus=0,2. As listas de CPU também podem ser especificadas em uma série, por exemplo --cpus=”1-3que selecionaria as CPUs 1, 2, e 3.

    Para adicionar uma CPU específica ao atual cpu_list, por exemplo, use --cpus= 0.

    Substituir [command] por, por exemplo, --isolate.

  • Para isolar uma CPU:

    # tuna --cpus=cpu_list --isolate
  • Para incluir uma CPU:

    # atum --cpus=cpu_list --inclua
  • Para usar um sistema com quatro ou mais processadores, mostrar como fazer todos os threads ssh rodarem na CPU 0 e 1, e todos os threads http na CPU 2 e 3:

    # tuna --cpus=0,1 --threads=ssh\* \
    --move --cpus=2,3 --threads=http\* --move

    Este comando executa as seguintes operações sequencialmente:

    1. Seleciona as CPUs 0 e 1.
    2. Seleciona todos os tópicos que começam com ssh.
    3. Movimenta os fios selecionados para as CPUs selecionadas. Atum define a máscara de afinidade dos fios, começando com ssh para as CPUs apropriadas. As CPUs podem ser expressas numericamente como 0 e 1, em máscara hexagonal como 0x3, ou em binário como 11.
    4. Redefine a lista de CPU para 2 e 3.
    5. Seleciona todos os tópicos que começam com http.
    6. Movimenta os fios selecionados para as CPUs especificadas. Tuna define a máscara de afinidade dos fios começando com http para as CPUs especificadas. As CPUs podem ser expressas numericamente como 2 e 3, em máscara hexadecimal como 0xC, ou em binário como 1100.

Etapas de verificação

  • Para exibir a configuração atual e verificar se as mudanças foram realizadas como esperado:

    # tuna --threads=gnome-sc\* --show_threads \
    --cpus=0 --move --show_threads --cpus=1 \
    --move --show_threads --cpus=+0 --move --show_threads
    
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        0     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav

    Este comando executa as seguintes operações sequencialmente:

    1. Seleciona todas as roscas que começam com as roscas gnome-sc.
    2. Exibe os fios selecionados para permitir que o usuário verifique sua máscara de afinidade e prioridade RT.
    3. Seleciona CPU 0.
    4. Movimenta os fios gnome-sc para a CPU especificada, CPU 0.
    5. Mostra o resultado da mudança.
    6. Redefine a lista de CPU para CPU 1.
    7. Movimenta os fios gnome-sc para a CPU especificada, CPU 1.
    8. Exibe o resultado da mudança.
    9. Adiciona a CPU 0 à lista de CPU.
    10. Move os tópicos gnome-sc para as CPUs especificadas, CPUs 0 e 1.
    11. Exibe o resultado da mudança.

Recursos adicionais

  • O arquivo /proc/cpuinfo.
  • A página do homem tuna.
  • O comando tuna -h exibe as opções CLI disponíveis.

4.4. Ajuste de IRQs usando ferramenta de atum

O arquivo /proc/interrupts registra o número de interrupções por IRQ, o tipo de interrupção, e o nome do dispositivo que está localizado nesse IRQ. Este procedimento descreve como afinar os IRQs usando a ferramenta tuna.

Pré-requisitos

Procedimento

  • Para ver os IRQs atuais e sua afinidade:

    # tuna --show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  • Para especificar a lista de IRQs a serem afetados por um comando:

    # atum --irqs=irq_list [command]

    O argumento irq_list é uma lista de números IRQ separados por vírgula ou padrões de nomes de usuários.

    Substituir [command] por, por exemplo, --isolate.

  • Para mover uma interrupção para uma CPU especificada:

    # tuna --irqs=128 --show_irqs
       # users            affinity
     128 iwlwifi           0,1,2,3
    
    # tuna --irqs=128 --cpus=3 --move

    Substituir 128 pelo argumento irq_list e 3 pelo argumento cpu_list.

    O argumento cpu_list é uma lista de números de CPU separados por vírgula, por exemplo, --cpus=0,2. Para mais informações, ver Seção 4.3, “Sintonia de CPUs usando a ferramenta atum”.

Etapas de verificação

  • Compare o estado dos IRQs selecionados antes e depois de mover qualquer interrupção para uma CPU especificada:

    # tuna --irqs=128 --show_irqs
       # users            affinity
     128 iwlwifi                 3

Recursos adicionais

  • O arquivo /procs/interrupts.
  • A página do homem tuna.
  • O comando tuna -h exibe as opções CLI disponíveis.

Capítulo 5. Monitoramento do desempenho usando os papéis do Sistema RHEL

5.1. Introdução aos papéis do sistema RHEL

O Sistema RHEL Roles é um conjunto de funções e módulos possíveis. As funções do sistema RHEL fornecem uma interface de configuração para gerenciar remotamente vários sistemas RHEL. A interface permite gerenciar configurações de sistema através de múltiplas versões do RHEL, bem como adotar novas versões principais.

No Red Hat Enterprise Linux 8, a interface atualmente consiste nas seguintes funções:

  • kdump
  • rede
  • selinux
  • armazenagem
  • certificado
  • kernel_settings
  • madeireiro
  • métricas
  • nbde_client e nbde_server
  • timesync
  • tlog

Todas essas funções são fornecidas pelo pacote rhel-system-roles disponível no repositório AppStream.

Recursos adicionais

  • Para uma visão geral dos Papéis do Sistema RHEL, veja o artigo do Red Hat Enterprise Linux (RHEL) System Roles Red Hat Knowledgebase.
  • Para informações sobre uma função específica, consulte a documentação sob o diretório /usr/share/doc/rhel-system-roles. Esta documentação é instalada automaticamente com o pacote rhel-system-roles.

5.2. Terminologia dos papéis do Sistema RHEL

Você pode encontrar os seguintes termos ao longo desta documentação:

Terminologia dos papéis do sistema

Livro de jogo possível
Os playbooks são a linguagem de configuração, implantação e orquestração do Ansible. Eles podem descrever uma política que você quer que seus sistemas remotos apliquem, ou um conjunto de passos em um processo geral de TI.
Nó de controle
Qualquer máquina com Ansible instalado. Você pode executar comandos e playbooks, invocando /usr/bin/ansible ou /usr/bin/ansible-playbook, a partir de qualquer nó de controle. Você pode usar qualquer computador que tenha o Python instalado nele como um nó de controle - laptops, desktops compartilhados e servidores podem todos rodar o Ansible. Entretanto, você não pode usar uma máquina Windows como nó de controle. Você pode ter múltiplos nós de controle.
Inventário
Uma lista de nós administrados. Um arquivo de inventário também é às vezes chamado de "arquivo hospedeiro". Seu inventário pode especificar informações como endereço IP para cada nó gerenciado. Um inventário também pode organizar nós administrados, criando e aninhando grupos para facilitar o escalonamento. Para saber mais sobre o inventário, consulte a seção Trabalhando com o inventário.
Nós administrados
Os dispositivos de rede, servidores, ou ambos que você administra com Ansible. Os nós gerenciados também são às vezes chamados de "hosts". O Ansible não é instalado em nós gerenciados.

5.3. Instalação de funções do sistema RHEL em seu sistema

Este parágrafo é a introdução do módulo de procedimento: uma breve descrição do procedimento.

Pré-requisitos

Procedimento

  1. Instale o pacote rhel-system-roles no sistema que você deseja usar como nó de controle:

    # yum instalar rhel-system-roles

    Se você não tiver uma assinatura do Red Hat Ansible Engine, você pode usar uma versão suportada limitada do Red Hat Ansible Engine fornecida com sua assinatura do Red Hat Enterprise Linux. Neste caso, siga estes passos:

    1. Habilitar o repositório RHEL Ansible Engine:

      # subscription-manager refresh
      
      # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
    2. Instalar Motor Possível:

      # yum instalar possível

Como resultado, você é capaz de criar um livro de brincadeiras possível.

Recursos adicionais

5.4. Aplicando um papel

O procedimento a seguir descreve como aplicar uma função específica.

Pré-requisitos

  • O pacote rhel-system-roles está instalado no sistema que você deseja usar como um nó de controle:

    # yum install rhel-system-roles
  • O repositório Ansible Engine está habilitado, e o pacote ansible está instalado no sistema que você deseja usar como um nó de controle. Você precisa do pacote ansible para executar playbooks que usam os papéis do sistema RHEL.

    • Se você não tiver uma assinatura do Red Hat Ansible Engine, você pode usar uma versão suportada limitada do Red Hat Ansible Engine fornecida com sua assinatura do Red Hat Enterprise Linux. Neste caso, siga estes passos:

      1. Habilitar o repositório RHEL Ansible Engine:

        # subscription-manager refresh
        # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
      2. Instalar Motor Possível:

        # yum install ansible
    • Se você tem uma assinatura de Red Hat Ansible Engine, siga o procedimento descrito em Como faço para baixar e instalar o Red Hat Ansible Engine?
  • Você é capaz de criar um livro de brincadeiras possível.

    Os playbooks representam a linguagem de configuração, implantação e orquestração do Ansible. Usando playbooks, você pode declarar e gerenciar configurações de máquinas remotas, implantar várias máquinas remotas ou etapas de orquestração de qualquer processo encomendado manualmente.

    Um playbook é uma lista de um ou mais plays. Cada play pode incluir variáveis, tarefas ou papéis possíveis.

    Os livros didáticos são legíveis por humanos e são expressos no formato YAML.

    Para mais informações sobre livros didáticos, consulte Documentação possível.

Procedimento

  1. Crie um caderno de atividades, incluindo o papel necessário.

    O exemplo a seguir mostra como usar os papéis através da opção roles: para um determinado play:

    ---
    - hosts: webservers
      roles:
         - rhel-system-roles.network
         - rhel-system-roles.timesync

    Para mais informações sobre o uso de papéis em livros didáticos, consulte Documentação possível.

    Veja Exemplos possíveis, por exemplo, livros didáticos.

    Nota

    Cada função inclui um arquivo README, que documenta como utilizar a função e os valores dos parâmetros suportados. Você também pode encontrar um exemplo de playbook para um determinado papel sob o diretório de documentação do papel. Tal diretório de documentação é fornecido por padrão com o pacote rhel-system-roles, e pode ser encontrado no local a seguir:

    /usr/share/doc/rhel-system-roles/SUBSYSTEM/

    Substituir SUBSYSTEM pelo nome da função requerida, como selinux, kdump, network, timesync, ou storage.

  2. Verificar a sintaxe do playbook:

    # ansible-playbook --syntax-check name.of.the.playbook

    O comando ansible-playbook oferece uma opção --syntax-check que você pode usar para verificar a sintaxe de um playbook.

  3. Executar o playbook nos anfitriões-alvo executando o comando ansible-playbook:

    # ansible-playbook -i name.of.the.inventory name.of.the.playbook

    Um inventário é uma lista de sistemas contra os quais o Ansible funciona. Para mais informações sobre como criar e inventariar, e como trabalhar com ele, consulte a documentação do Ansible.

    Se você não tiver um inventário, você pode criá-lo no momento da execução ansible-playbook:

    Se você tiver apenas um anfitrião específico contra o qual você deseja executar o playbook, use:

    # ansible-playbook -i host1, name.of.the.playbook

    Se você tiver vários anfitriões alvo contra os quais você deseja executar o livro de jogo, use:

    # ansible-playbook -i host1,host2,....,hostn name.of.the.playbook

Recursos adicionais

  • Para obter informações mais detalhadas sobre o uso do comando ansible-playbook, consulte a página de manual ansible-playbook.

5.5. Introdução ao sistema métrico Papel do sistema

As funções do sistema RHEL são um conjunto de funções e módulos possíveis que fornecem uma interface de configuração consistente para gerenciar remotamente vários sistemas RHEL. A função do sistema de métricas configura serviços de análise de desempenho para o sistema local e, opcionalmente, inclui uma lista de sistemas remotos a serem monitorados pelo sistema local. O sistema de métricas System Role permite que você use pcp para monitorar o desempenho de seus sistemas sem ter que configurar pcp separadamente, já que a configuração e implantação de pcp é tratada pelo playbook.

Tabela 5.1. Variáveis de papel do sistema métrico
Função variávelDescriçãoExemplo de uso

métricas_monitoradas_hosts

Lista de hospedeiros remotos a serem analisados pelo hospedeiro alvo. Estes anfitriões terão métricas registradas no anfitrião alvo, portanto, certifique-se de que existe espaço suficiente em disco abaixo de /var/log para cada anfitrião.

metrics_monitored_hosts: ["webserver.example.com", "database.example.com"]

dias_de_retenção_métrica

Configura o número de dias para retenção de dados de desempenho antes da exclusão.

metrics_retention_days: 14

metrics_graph_service

Uma bandeira booleana que permite a instalação do host com serviços de visualização de dados de desempenho via pcp e grafana. Definido como falso por padrão.

metrics_graph_service: false

métrica_consulta_serviço

Uma bandeira booleana que permite configurar o host com serviços de consulta de séries temporais para consulta de métricas registradas pcp via redis. Definido como falso por padrão.

metrics_query_service: false

metrics_provider

Especifica qual métrica coletor a ser usada para fornecer métricas. Atualmente, pcp é o único fornecedor de métricas suportado.

metrics_provider: "pcp"

Recursos adicionais

  • para detalhes sobre os parâmetros usados em metrics_connections e informações adicionais sobre a função do sistema métrico, veja o arquivo /usr/share/ansible/roles/rhel-system-roles.metrics/README.md.

5.6. Usando o sistema métrico Função do sistema para monitorar seu sistema local com visualização

Este procedimento descreve como usar a métrica RHEL System Role para monitorar seu sistema local enquanto simultaneamente fornece a visualização de dados via grafana.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado na máquina que você deseja monitorar.
  • Você tem o pacote rhel-system-roles instalado na máquina que você deseja monitorar.

Procedimento

  1. Configurar localhost no site /etc/ansible/hosts Inventário possível, adicionando o seguinte conteúdo ao inventário:

    localhost ansible_connection=local
  2. Crie um livro de jogo possível com o seguinte conteúdo:

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
      roles:
        - rhel-system-roles.metrics
  3. Execute o livro de jogo Ansible playbook:

    # ansible-playbook name_of_your_playbook.yml
    Nota

    Como o metrics_graph_service boolean está configurado para value="yes", grafana é automaticamente instalado e provisionado com pcp adicionado como fonte de dados.

  4. Para visualizar a visualização das métricas que estão sendo coletadas em sua máquina, acesse a interface web grafana como descrito em Accessing the Grafana web UI.

5.7. Usando o sistema métrico Função do sistema para configurar uma frota de sistemas individuais para monitorar a si mesmos

Este procedimento descreve como usar o sistema métrico Papel do sistema para montar uma frota de máquinas para monitorar a si mesmos.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado na máquina que você deseja usar para executar o playbook.
  • Você tem o pacote rhel-system-roles instalado na máquina que você deseja usar para executar o playbook.

Procedimento

  1. Adicione o nome ou IP das máquinas que você deseja monitorar através do playbook ao arquivo /etc/ansible/hosts. Um possível arquivo de inventário com um nome de grupo identificador entre parênteses:

    [remotes]
    webserver.example.com
    database.example.com
  2. Crie um livro de jogo possível com o seguinte conteúdo:

    ---
    - hosts: remotes
      vars:
        metrics_retention_days: 0
      roles:
        - rhel-system-roles.metrics
  3. Execute o livro de jogo Ansible playbook:

    # ansible-playbook name_of_your_playbook.yml

5.8. Usando o sistema métrico Papel do sistema para monitorar uma frota de máquinas de forma centralizada através de sua máquina local

Este procedimento descreve como usar o sistema de métricas Função do sistema para configurar sua máquina local para monitorar centralmente uma frota de máquinas, ao mesmo tempo em que fornece a visualização dos dados via grafana e consulta dos dados via redis.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado na máquina que você deseja usar para executar o playbook.
  • Você tem o pacote rhel-system-roles instalado na máquina que você deseja usar para executar o playbook.

Procedimento

  1. Crie um livro de jogo possível com o seguinte conteúdo:

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
      roles:
        - rhel-system-roles.metrics
  2. Execute o livro de jogo Ansible playbook:

    # ansible-playbook name_of_your_playbook.yml
    Nota

    Como as booleans metrics_graph_service e metrics_query_service estão configuradas para value="yes", grafana é automaticamente instalado e provisionado com pcp adicionado como fonte de dados com o registro de dados pcp indexado em redis, permitindo que a linguagem de consulta pcp seja usada para consulta complexa dos dados.

  3. Para visualizar a representação gráfica das métricas que estão sendo coletadas centralmente por sua máquina e para consultar os dados, acesse a interface web grafana conforme descrito em Accessing the Grafana web UI.

Capítulo 6. Monitorando o desempenho com o Co-Piloto de Desempenho

Como administrador de sistemas, você pode monitorar o desempenho do sistema usando o aplicativo Performance Co-Pilot (PCP) no Red Hat Enterprise Linux 8.

6.1. Visão geral do PCP

O PCP é um conjunto de ferramentas, serviços e bibliotecas para monitoramento, visualização, armazenamento e análise de medidas de desempenho em nível de sistema.

Características do PCP:

  • Arquitetura distribuída leve, que é útil durante a análise centralizada de sistemas complexos.
  • Ele permite o monitoramento e o gerenciamento de dados em tempo real.
  • Ele permite o registro e a recuperação de dados históricos.

Você pode adicionar métricas de desempenho usando interfaces Python, Perl, C , e C. Ferramentas de análise podem usar as APIs clientes Python, C , C diretamente, e aplicações web ricas podem explorar todos os dados de desempenho disponíveis usando uma interface JSON.

Você pode analisar padrões de dados comparando resultados ao vivo com dados arquivados.

O PCP tem os seguintes componentes:

  • O Performance Metric Collector Daemon (pmcd) coleta dados de desempenho dos Agentes do Domínio Performance Metric instalados (pmda). PMDAs pode ser carregado ou descarregado individualmente no sistema e são controlados pelo PMCD no mesmo host.
  • Várias ferramentas do cliente, tais como pminfo ou pmstat, podem recuperar, exibir, arquivar e processar esses dados no mesmo host ou através da rede.
  • O pacote pcp fornece as ferramentas de linha de comando e a funcionalidade subjacente.
  • O pacote pcp-gui fornece a aplicação gráfica. Instale o pacote pcp-gui executando o comando yum install pcp-gui. Para maiores informações, veja Seção 6.6, “Rastreamento visual dos arquivos de log do PCP com a aplicação PCP Charts.

Recursos adicionais

6.2. Instalando e habilitando o PCP

Para começar a usar o PCP, instale todos os pacotes necessários e habilite os serviços de monitoramento do PCP.

Procedimento

  1. Instalar o pacote PCP:

    # yum instalar pcp
  2. Habilite e inicie o serviço pmcd na máquina host:

    # systemctl enable pmcd
    
    # systemctl start pmcd
  3. Verifique se o processo pmcd está rodando no host e se o XFS PMDA está listado como habilitado na configuração:

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

Recursos adicionais

6.3. Implantação de uma configuração mínima de PCP

A configuração mínima do PCP coleta estatísticas de desempenho no Red Hat Enterprise Linux. A configuração envolve a adição do número mínimo de pacotes em um sistema de produção necessário para coletar dados para análise posterior. Você pode analisar o arquivo tar.gz resultante e o arquivo da saída do pmlogger usando várias ferramentas PCP e compará-los com outras fontes de informação de desempenho.

Pré-requisitos

Procedimento

  1. Atualizar a configuração do pmlogger:

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. Iniciar os serviços pmcd e pmlogger:

    # systemctl start pmcd.service
    
    # systemctl start pmlogger.service
  3. Executar as operações necessárias para registrar os dados de desempenho.
  4. Pare os serviços pmcd e pmlogger:

    # systemctl stop pmcd.service
    
    # systemctl stop pmlogger.service
  5. Salve a saída e salve-a em um arquivo tar.gz nomeado com base no nome do host e na data e hora atuais:

    # cd /var/log/pcp/pmlogger/
    
    # tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)

    Extraia este arquivo e analise os dados usando ferramentas PCP.

6.4. Registro de dados de desempenho com o pmlogger

Com a ferramenta PCP, você pode registrar os valores métricos de desempenho e reproduzi-los posteriormente. Isto permite que você faça uma análise retrospectiva do desempenho.

Usando a ferramenta pmlogger, você pode:

  • Criar os logs arquivados de métricas selecionadas no sistema
  • Especifique quais métricas são registradas no sistema e com que freqüência

6.4.1. Modificando o arquivo de configuração do pmlogger com pmlogconf

Quando o serviço pmlogger está em execução, o PCP registra um conjunto padrão de métricas no host. Use o utilitário pmlogconf para verificar a configuração padrão. Se o arquivo de configuração pmlogger não existir, pmlogconf o cria com um valor de métrica padrão.

Pré-requisitos

Procedimento

  1. Criar ou modificar o arquivo de configuração pmlogger:

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. Siga as instruções do pmlogconf para ativar ou desativar grupos de métricas de desempenho relacionadas e para controlar o intervalo de registro para cada grupo ativado.

6.4.2. Edição manual do arquivo de configuração do pmlogger

Para criar uma configuração de registro personalizada com métricas específicas e determinados intervalos, edite o arquivo de configuração pmlogger manualmente.

Na configuração manual, você pode:

  • Registrar métricas que não estão listadas na configuração automática.
  • Escolha freqüências de registro personalizadas.
  • Adicione PMDA com a métrica de aplicação.

O arquivo de configuração padrão pmlogger é /var/lib/pcp/config/pmlogger/config.default. O arquivo de configuração especifica quais métricas são registradas pela instância de registro principal.

Pré-requisitos

Procedimento

  • Abra e edite o arquivo /var/lib/pcp/config/pmlogger/config.default para adicionar métricas específicas:

    # It is safe to make additions from here on ...
    #
    
    log mandatory on every 5 seconds {
        xfs.write
        xfs.write_bytes
        xfs.read
        xfs.read_bytes
    }
    
    log mandatory on every 10 seconds {
        xfs.allocs
        xfs.block_map
        xfs.transactions
        xfs.log
    
    }
    
    [access]
    disallow * : all;
    allow localhost : enquire;

6.4.3. Permitindo o serviço de pmlogger

O serviço pmlogger deve ser iniciado e habilitado para registrar os valores métricos na máquina local.

Pré-requisitos

Procedimento

  1. Inicie e habilite o serviço pmlogger:

    # systemctl start pmlogger
    
    # systemctl enable pmlogger
  2. Verifique se o site pmlogger está habilitado:

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents, 1 client
    pmda: root pmcd proc xfs linux mmv kvm jbd2
    pmlogger: primary logger: /var/log/pcp/pmlogger/workstation/20190827.15.54

Recursos adicionais

6.4.4. Criação de um sistema cliente para coleta de métricas

Este procedimento descreve como configurar um sistema de cliente para que um servidor central possa coletar métricas de clientes executando PCP.

Pré-requisitos

Procedimento

  1. Instale o pacote pcp-system-tools:

    # yum instalar as ferramentas do sistema pcp
  2. Configurar um endereço IP para pmcd:

    # echo "-i 192.168.4.62" >/etc/pcp/pmcd/pmcd.options

    Substituir 192.168.4.62 pelo endereço IP, o cliente deve ouvir.

    Por padrão, pmcd está escutando no local.

  3. Configurar o firewall para adicionar o público zone permanentemente:

    # firewall-cmd --permanent --zone=public --add-port=44321/tcp
    success
    
    # firewall-cmd --reload
    success
  4. Preparar um booleano SELinux:

    # setsebool -P pcp_bind_all_unreserved_ports on
  5. Habilitar os serviços pmcd e pmlogger:

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

Etapas de verificação

  • Verifique se o pmcd está escutando corretamente o endereço IP configurado:

    # ss -tlp | grep 44321
    LISTEN   0   5     127.0.0.1:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=6))
    LISTEN   0   5  192.168.4.62:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=0))
    LISTEN   0   5         [::1]:44321      [::]:*   users:(("pmcd",pid=151595,fd=7))

Recursos adicionais

6.4.5. Criação de um servidor central para a coleta de dados

Este procedimento descreve como criar um servidor central para coletar métricas de clientes executando PCP.

Pré-requisitos

Procedimento

  1. Instale o pacote pcp-system-tools:

    # yum instalar as ferramentas do sistema pcp
  2. Adicionar clientes para monitoramento:

    # echo "192.168.4.13 n n PCP_LOG_DIR/pmlogger/rhel7u4a -r -T24h10m \
    -c config.remote"  >> /etc/pcp/pmlogger/control.d/remote
    
    # echo "192.168.4.14 n n PCP_LOG_DIR/pmlogger/rhel6u10a -r -T24h10m \
     -c config.remote" >> /etc/pcp/pmlogger/control.d/remote
    
    # echo "192.168.4.62 n n PCP_LOG_DIR/pmlogger/rhel8u1a -r -T24h10m \
    -c config.remote" >> /etc/pcp/pmlogger/control.d/remote

    Substituir 192.168.4.13, 192.168.4.14, e 192.168.4.62 pelos endereços IP do cliente.

  3. Habilitar os serviços pmcd e pmlogger:

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

Etapas de verificação

  • Certifique-se de que você possa acessar o arquivo mais recente de cada diretório:

    # for i in /var/log/pcp/pmlogger/rhel*/*.0; do pmdumplog -L $i; done
    Log Label (Log Format Version 2)
    Performance metrics from host rhel6u10a.local
      commencing Mon Nov 25 21:55:04.851 2019
      ending     Mon Nov 25 22:06:04.874 2019
    Archive timezone: JST-9
    PID for pmlogger: 24002
    Log Label (Log Format Version 2)
    Performance metrics from host rhel7u4a
      commencing Tue Nov 26 06:49:24.954 2019
      ending     Tue Nov 26 07:06:24.979 2019
    Archive timezone: CET-1
    PID for pmlogger: 10941
    [..]

    Os arquivos do diretório /var/log/pcp/pmlogger/ podem ser usados para análises e gráficos adicionais.

Recursos adicionais

6.4.6. Reprodução dos arquivos de log do PCP com o pmdumptext

Depois de gravar os dados métricos, você pode reproduzir novamente os arquivos de registro do PCP. Para exportar os logs para arquivos de texto e importá-los para planilhas, use utilitários PCP como pmdumptext, pmrep, ou pmlogsummary.

Usando a ferramenta pmdumptext, você pode:

  • Ver os arquivos de log
  • Analisar o arquivo de log PCP selecionado e exportar os valores para uma tabela ASCII
  • Extrair todo o log de arquivo ou apenas selecionar valores métricos do log especificando métricas individuais na linha de comando

Pré-requisitos

Procedimento

  • Exibir os dados no sistema métrico:

    $ pmdumptext -t 5seconds -H -a 20170605 xfs.perdev.log.writes
    
    Time local::xfs.perdev.log.writes["/dev/mapper/fedora-home"] local::xfs.perdev.log.writes["/dev/mapper/fedora-root"]
    ? 0.000 0.000
    none count / second count / second
    Mon Jun 5 12:28:45 ? ?
    Mon Jun 5 12:28:50 0.000 0.000
    Mon Jun 5 12:28:55 0.200 0.200
    Mon Jun 5 12:29:00 6.800 1.000

    O exemplo mencionado exibe os dados da métrica xfs.perdev.log coletados em um arquivo em um intervalo de 5 second e exibe todos os cabeçalhos.

Recursos adicionais

6.5. Monitoramento de pós fixado com pmda-postfix

Este procedimento descreve como monitorar as métricas de desempenho do servidor de e-mail postfix com pmda-postfix. Ele ajuda a verificar quantos e-mails são recebidos por segundo.

Pré-requisitos

Procedimento

  1. Instale os seguintes pacotes:

    1. Instale o pcp-system-tools:

      # yum instalar as ferramentas do sistema pcp
    2. Instale o pacote pmda-postfix para monitorar postfix:

      # yum instalar pcp-pmda-postfix postfix
    3. Instalar o daemon de extração:

      # yum instalar rsyslog
    4. Instalar o cliente de correio para testes:

      # yum instalar mutt
  2. Habilitar os serviços postfix e rsyslog:

    # systemctl enable postfix rsyslog
    # systemctl restart postfix rsyslog
  3. Habilite o booleano SELinux, para que pmda-postfix possa acessar os arquivos de registro necessários:

    # setsebool -P pcp_read_generic_logs=on
  4. Instale o PMDA:

    # cd /var/lib/pcp/pmdas/postfix/
    
    # ./Install
    
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Waiting for pmcd to terminate ...
    Starting pmcd ...
    Check postfix metrics have appeared ... 7 metrics and 58 values

Etapas de verificação

  • Verifique a operação pmda-postfix:

    echo testmail | raiz mutt
  • Verificar as métricas disponíveis:

    # pminfo postfix
    
    postfix.received
    postfix.sent
    postfix.queues.incoming
    postfix.queues.maildrop
    postfix.queues.hold
    postfix.queues.deferred
    postfix.queues.active

Recursos adicionais

6.6. Rastreamento visual dos arquivos de log do PCP com a aplicação PCP Charts

Após gravar os dados métricos, você pode reproduzir novamente os arquivos de registro do PCP como gráficos.

Usando o aplicativo PCP Charts, você pode:

  • Reproduza os dados na aplicação PCP Charts e use gráficos para visualizar os dados retrospectivos junto com os dados ao vivo do sistema.
  • Traçar os valores métricos de desempenho em gráficos.
  • Exibir vários gráficos simultaneamente.

As métricas são obtidas de um ou mais hosts vivos com opções alternativas para usar os dados métricos dos arquivos de log do PCP como fonte de dados históricos.

A seguir estão as diversas maneiras de personalizar a interface do aplicativo PCP Charts para exibir os dados da métrica de desempenho:

  • gráfico da linha
  • gráficos de barra
  • gráficos de utilização

Pré-requisitos

Procedimento

  1. Iniciar o aplicativo PCP Charts a partir da linha de comando:

    # pmchart

    pmchart começou

    As configurações do servidor pmtime estão localizadas na parte inferior. O botão start e pause permite o controle:

    • O intervalo no qual o PCP faz o levantamento dos dados métricos
    • A data e a hora para a métrica dos dados históricos
  2. Acesse File → New Chart para selecionar a métrica tanto da máquina local quanto das máquinas remotas, especificando o nome ou endereço de seu host. As opções de configuração avançada incluem a capacidade de definir manualmente os valores dos eixos para o gráfico, e escolher manualmente a cor dos gráficos.
  3. Registre as opiniões criadas na aplicação PCP Charts:

    A seguir estão as opções para tirar imagens ou gravar as vistas criadas no aplicativo PCP Charts:

    • Clique em File → Export para salvar uma imagem da vista atual.
    • Clique em Record → Start para iniciar uma gravação. Clique em Record → Stop para interromper a gravação. Após a interrupção da gravação, as métricas gravadas são arquivadas para serem vistas mais tarde.
  4. Opcional: No aplicativo PCP Charts, o arquivo principal de configuração, conhecido como view, permite salvar os metadados associados a um ou mais gráficos. Estes metadados descrevem todos os aspectos dos gráficos, incluindo as métricas utilizadas e as colunas dos gráficos. Salve a configuração personalizada view clicando em File → Save View, e carregue a configuração view posteriormente. O seguinte exemplo do arquivo de configuração da visualização da aplicação PCP Charts descreve um gráfico de empilhamento mostrando o número total de bytes lidos e escritos no determinado sistema de arquivos XFS loop1:

    #kmchart
    version 1
    
    chart title "Filesystem Throughput /loop1" style stacking antialiasing off
        plot legend "Read rate"   metric xfs.read_bytes   instance  "loop1"
        plot legend "Write rate"  metric xfs.write_bytes  instance  "loop1"

Recursos adicionais

6.7. Análise de desempenho do sistema de arquivos XFS com PCP

O XFS PMDA é enviado como parte do pacote pcp e é habilitado por padrão durante a instalação. Ele é usado para reunir dados métricos de desempenho dos sistemas de arquivos XFS em PCP.

6.7.1. Instalação manual do XFS PMDA

Se o XFS PMDA não estiver listado na leitura de configuração do PCP, instale o agente PMDA manualmente.

Procedimento

  1. Navegue até o diretório xfs:

    # cd /var/lib/pcp/pmdas/xfs/
  2. Instalar o XFS PMDA manualmente:

    xfs]# ./Install
    
    You will need to choose an appropriate configuration for install of
    the “xfs” Performance Metrics Domain Agent (PMDA).
    
      collector     collect performance statistics on this system
      monitor       allow this system to monitor local and/or remote systems
      both          collector and monitor configuration for this system
    
    Please enter c(ollector) or m(onitor) or (both) [b]
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Waiting for pmcd to terminate ...
    Starting pmcd ...
    Check xfs metrics have appeared ... 149 metrics and 149 values
  3. Selecione a função PMDA pretendida entrando em c para coletor, m para monitor, ou b para ambos. O roteiro de instalação do PMDA solicita que você especifique uma das seguintes funções do PMDA:

    • A função collector permite a coleta de métricas de desempenho no sistema atual
    • A função monitor permite ao sistema monitorar sistemas locais, sistemas remotos, ou ambos

      A opção padrão é tanto collector quanto monitor, o que permite que o XFS PMDA funcione corretamente na maioria dos cenários.

Recursos adicionais

6.7.2. Examinando as métricas de desempenho XFS com pminfo

A ferramenta pminfo exibe informações sobre as métricas de desempenho disponíveis. Este procedimento exibe uma lista de todas as métricas disponíveis fornecidas pelo XFS PMDA.

Pré-requisitos

Procedimento

  1. Exibir a lista de todas as métricas disponíveis fornecidas pelo XFS PMDA:

    # pminfo xfs
  2. Exibir informações para as métricas individuais. Os exemplos a seguir examinam as métricas específicas do XFS read e write usando a ferramenta pminfo:

    • Mostrar uma breve descrição da métrica xfs.write_bytes:

      # pminfo --oneline xfs.write_bytes
      
      xfs.write_bytes [number of bytes written in XFS file system write operations]
    • Mostrar uma longa descrição da métrica xfs.read_bytes:

      # pminfo --helptext xfs.read_bytes
      
      xfs.read_bytes
      Help:
      This is the number of bytes read via read(2) system calls to files in
      XFS file systems. It can be used in conjunction with the read_calls
      count to calculate the average size of the read operations to file in
      XFS file systems.
    • Obter o valor de desempenho atual da métrica xfs.read_bytes:

      # pminfo --fetch xfs.read_bytes
      
      xfs.read_bytes
          value 4891346238

Recursos adicionais

6.7.3. Reinicialização das métricas de desempenho XFS com a loja pm

Com o PCP, você pode modificar os valores de certas métricas, especialmente se a métrica atuar como uma variável de controle, como a métrica xfs.control.reset. Para modificar um valor de métrica, use a ferramenta pmstore.

Pré-requisitos

Procedimento

  1. Mostrar o valor de uma métrica:

    $ pminfo -f xfs.write
    
    xfs.write
        value 325262
  2. Redefinir todas as métricas do XFS:

    # pmstore xfs.control.reset 1
    
    xfs.control.reset old value=0 new value=1
  3. Veja as informações após redefinir o sistema métrico:

    $ pminfo --fetch xfs.write
    
    xfs.write
        value 0

6.7.4. Examinando as métricas XFS disponíveis por sistema de arquivo

O PCP permite que o XFS PMDA permita o relatório de certas métricas XFS por cada um dos sistemas de arquivo XFS montados. Isto facilita a identificação de problemas específicos do sistema de arquivo montado e a avaliação do desempenho. O comando pminfo fornece métricas XFS por dispositivo para cada sistema de arquivo XFS montado.

Pré-requisitos

Procedimento

  • Obter métricas por dispositivo XFS com pminfo:

    # pminfo --fetch --oneline xfs.perdev.read xfs.perdev.write
    
    xfs.perdev.read [number of XFS file system read operations]
    inst [0 or "loop1"] value 0
    inst [0 or "loop2"] value 0
    
    xfs.perdev.write [number of XFS file system write operations]
    inst [0 or "loop1"] value 86
    inst [0 or "loop2"] value 0

6.8. Serviços de sistema distribuídos com PCP

Nome

Descrição

pmcd

O Coletor Métrico de Desempenho Daemon (PMCD).

pmie

O Motor de Inferência de Métricas de Desempenho.

pmlogger

O registrador de métricas de desempenho.

pmmgr

Gerencia uma coleção de daemons PCP para um conjunto de hospedeiros locais e remotos descobertos executando o Performance Metric Collector Daemon (PMCD) de acordo com zero ou mais diretórios de configuração.

pmproxy

O servidor proxy PMCD (Performance Metric Collector Daemon).

6.9. Ferramentas distribuídas com PCP

Nome

Descrição

pcp

Exibe o status atual de uma instalação do Co-Piloto de Desempenho.

pcp-atop

Mostra a ocupação em nível de sistema dos recursos de hardware mais críticos do ponto de vista de desempenho: CPU, memória, disco e rede.

pcp-dstat

Exibe as métricas de um sistema de cada vez. Para exibir métricas de vários sistemas, use a opção --host.

pmchart

Gráficos de valores métricos de desempenho disponíveis através das instalações do Co-Piloto de Desempenho.

pmclient

Exibe métricas de desempenho de alto nível do sistema usando a Interface de Programação de Aplicação de Métricas de Desempenho (PMAPI).

pmcollectl

Coleta e exibe dados em nível de sistema, seja de um sistema ao vivo ou de um arquivo de Co-piloto de Desempenho.

pmconfig

Exibe os valores dos parâmetros de configuração.

pmdbg

Exibe as bandeiras de controle de depuração do Co-Piloto de Desempenho disponíveis e seus valores.

pmdiff

Compara os valores médios para cada métrica em um ou dois arquivos, em uma determinada janela de tempo, para mudanças que provavelmente serão de interesse quando se procura por regressões de desempenho.

pmdumplog

Exibe informações de controle, metadados, índice e estado de um arquivo do Co-Piloto de Desempenho.

pmdumptext

Produz os valores de métricas de desempenho coletados ao vivo ou de um arquivo de Co-Pilotos de Desempenho.

pmerr

Exibe os códigos de erro disponíveis do Co-Piloto de Desempenho e suas mensagens de erro correspondentes.

pmfind

Encontra serviços de PCP na rede.

pmie

Um mecanismo de inferência que periodicamente avalia um conjunto de expressões aritméticas, lógicas e de regras. As métricas são coletadas ou de um sistema ao vivo, ou de um arquivo de arquivo de Co-piloto de Desempenho.

pmieconf

Exibe ou define variáveis pmie configuráveis.

pminfo

Exibe informações sobre métricas de desempenho. As métricas são coletadas ou de um sistema ao vivo, ou de um arquivo do Co-Piloto de Desempenho.

pmiostat

Relata estatísticas de E/S para dispositivos SCSI (por padrão) ou dispositivos de fabricação de dispositivos (com a opção -x dm).

pmlc

Configura interativamente as instâncias ativas do pmlogger.

pmlogcheck

Identifica dados inválidos em um arquivo do Co-Piloto de Desempenho.

pmlogconf

Cria e modifica um arquivo de configuração do pmlogger.

pmloglabel

Verifica, modifica ou repara o rótulo de um arquivo do Co-Piloto de Desempenho.

pmlogsummary

Calcula informações estatísticas sobre métricas de desempenho armazenadas em um arquivo do Co-Piloto de Desempenho.

pmprobe

Determina a disponibilidade de métricas de desempenho.

pmrep

Relatórios sobre valores selecionados, facilmente personalizáveis, de métricas de desempenho.

pmsocks

Permite o acesso a um anfitrião de Co-Piloto de Desempenho através de um firewall.

pmstat

Periodicamente, exibe um breve resumo do desempenho do sistema.

pmstore

Modifica os valores da métrica de desempenho.

pmtrace

Fornece uma interface de linha de comando para o trace Performance Metrics Domain Agent (PMDA).

pmval

Exibe o valor atual de uma métrica de desempenho.

6.10. Grupos métricos PCP para XFS

Grupo Métrico

Métricas fornecidas

xfs.*

As métricas gerais XFS, incluindo a contagem da operação de leitura e escrita, contagem de bytes de leitura e escrita. Junto com os contadores para o número de vezes que os inodes são enxaguados, agrupados e o número de falhas no agrupamento.

xfs.allocs.*

xfs.alloc_btree.*

Gama de métricas relativas à alocação de objetos no sistema de arquivo, estas incluem número de extensões e criação de blocos/árvores. A árvore de alocação procura e compara juntamente com a criação e exclusão de registros de extensão do btree.

xfs.block_map.*

xfs.bmap_tree.*

As métricas incluem o número de apagamentos de leitura/escrita de mapas de blocos, operações de lista de extensão para inserção, apagamentos e buscas. Também contadores de operações para comparações, buscas, inserções e operações de exclusão do mapa de blocos.

xfs.dir_ops.*

Contadores para operações de diretório em sistemas de arquivos XFS para criação, eliminação de entradas, contagem de operações de "getdent".

xfs.transactions.*

Contadores para o número de transações de meta-dados, estes incluem a contagem do número de transações síncronas e assíncronas, juntamente com o número de transações vazias.

xfs.inode_ops.*

Contadores para o número de vezes que o sistema operacional procurou por um inode XFS no cache inode com resultados diferentes. Essas contagens de acertos, falhas de cache e assim por diante.

xfs.log.*

xfs.log_tail.*

Os contadores para o número de buffer de logs escritos sobre os sistemas de arquivos XFS incluem o número de blocos escritos em disco. Métricas também para o número de fluxos de log e pinagem.

xfs.xstrat.*

Conta para o número de bytes de dados de arquivo descarregados pelo deamon de descarga XFS junto com os contadores para o número de buffers descarregados para espaço contíguo e não contíguo em disco.

xfs.attr.*

Conta para o número de atributo obter, definir, remover e listar operações sobre todos os sistemas de arquivos XFS.

xfs.quota.*

Métricas para operação de cota sobre sistemas de arquivos XFS, estas incluem contadores para número de recuperações de cota, falhas de cache de cota, acertos de cache e recuperações de dados de cota.

xfs.buffer.*

Gama de métricas relativas a objetos de amortecedores XFS. Os contadores incluem o número de chamadas de buffer solicitadas, bloqueios de buffer bem sucedidos, bloqueios de buffer aguardados, bloqueios de miss_locks, miss_retries e acertos de buffer ao consultar as páginas.

xfs.btree.*

Métricas relativas às operações da árvore XFS.

xfs.control.reset

Métricas de configuração que são usadas para reiniciar os contadores métricos para as estatísticas do XFS. As métricas de controle são alternadas por meio da ferramenta pmstore.

6.11. Grupos métricos PCP por dispositivo para XFS

Grupo Métrico

Métricas fornecidas

xfs.perdev.*

As métricas gerais XFS, incluindo a contagem da operação de leitura e escrita, contagem de bytes de leitura e escrita. Junto com os contadores para o número de vezes que os inodes são enxaguados, agrupados e o número de falhas no agrupamento.

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

Gama de métricas relativas à alocação de objetos no sistema de arquivo, estas incluem número de extensões e criação de blocos/árvores. A árvore de alocação procura e compara juntamente com a criação e exclusão de registros de extensão do btree.

xfs.perdev.block_map.*

xfs.perdev.bmap_tree.*

As métricas incluem o número de apagamentos de leitura/escrita de mapas de blocos, operações de lista de extensão para inserção, apagamentos e buscas. Também contadores de operações para comparações, buscas, inserções e operações de exclusão do mapa de blocos.

xfs.perdev.dir_ops.*

Contadores para operações de diretório de sistemas de arquivos XFS para criação, apagamento de entradas, contagem de operações de "getdent".

xfs.perdev.transactions.*

Contadores para o número de transações de meta-dados, estes incluem a contagem do número de transações síncronas e assíncronas, juntamente com o número de transações vazias.

xfs.perdev.inode_ops.*

Contadores para o número de vezes que o sistema operacional procurou por um inode XFS no cache inode com resultados diferentes. Essas contagens de acertos, falhas de cache e assim por diante.

xfs.perdev.log.*

xfs.perdev.log_tail.*

Os contadores para o número de buffer de logs escritos sobre os filesytems XFS incluem o número de blocos escritos em disco. Métricas também para o número de fluxos de log e pinagem.

xfs.perdev.xstrat.*

Conta para o número de bytes de dados de arquivo descarregados pelo deamon de descarga XFS junto com os contadores para o número de buffers descarregados para espaço contíguo e não contíguo em disco.

xfs.perdev.attr.*

Conta para o número de atributo obter, definir, remover e listar operações sobre todos os sistemas de arquivos XFS.

xfs.perdev.quota.*

Métricas para operação de cota sobre sistemas de arquivos XFS, estas incluem contadores para número de recuperações de cota, falhas de cache de cota, acertos de cache e recuperações de dados de cota.

xfs.perdev.buffer.*

Gama de métricas relativas a objetos de amortecedores XFS. Os contadores incluem o número de chamadas de buffer solicitadas, bloqueios de buffer bem sucedidos, bloqueios de buffer aguardados, bloqueios de miss_locks, miss_retries e acertos de buffer ao consultar as páginas.

xfs.perdev.btree.*

Métricas relativas às operações da árvore XFS.

Capítulo 7. Criação de representação gráfica da métrica PCP

Usando uma combinação de redis, pcp, bpftrace, vector e grafana fornece gráficos, baseados nos dados ao vivo ou dados coletados pelo Performance Co-Pilot (PCP). Ele permite acessar gráficos de métricas de PCP usando um navegador da web.

  • O PCP é uma estrutura genérica que coleta, monitora, analisa e armazena métricas relacionadas ao desempenho. Para mais informações sobre o PCP e seus componentes, consulte Monitorando o desempenho com o Co-Piloto de Desempenho.
  • Redis é um in-memory-database. Ele é usado para armazenar dados dos arquivos arquivados que são facilmente acessíveis para a geração de gráficos pelo aplicativo Grafana.
  • A Bpftrace permite o acesso aos dados ao vivo de fontes que não estão disponíveis como dados normais do pmlogger ou arquivos.
  • Vector fornece acesso aos dados ao vivo, mas não fornece acesso aos dados do passado.
  • Grafana gera gráficos que são acessíveis através de um navegador. O grafana-server é um componente que escuta, por padrão, em todas as interfaces, e fornece serviços web acessados através do navegador web. O plugin grafana-pcp interage com o protocolo pmproxy no backend.

7.1. Configurando o PCP em um sistema

Este procedimento descreve como configurar o PCP em um sistema com o pacote pcp-zeroconf. Uma vez instalado o pacote pcp-zeroconf, o sistema registra o conjunto padrão de métricas em arquivos arquivados.

Procedimento

  • Instale o pacote pcp-zeroconf:

    # yum instalar pcp-zeroconf

Etapas de verificação

  • Certifique-se de que o serviço pmlogger esteja ativo, e comece a arquivar as métricas:

    # pcp | grep pmlogger
     pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12

Recursos adicionais

7.2. Criação de um servidor de grafana-servidor

Este procedimento descreve como criar um grafana-server. Trata-se de um servidor back-end para o Grafana dashbaord. O componente grafana-server ouve na interface, e fornece serviços web que são acessados via navegador.

Pré-requisitos

Procedimento

  1. Instale os seguintes pacotes:

    # yum instalar redis grafana grafana-pcp
  2. Reinicie e habilite os seguintes componentes:

    # systemctl restart redis pmproxy grafana-server
    # systemctl enable redis pmproxy grafana-server

Etapas de verificação

  • Certifique-se de que o grafana-server está escutando e respondendo às solicitações:

    # ss -ntlp | grep 3000
    LISTEN  0  128  *:3000  *:*  users:(("grafana-server",pid=19522,fd=7))

Recursos adicionais

  • A página do homem pmproxy.
  • A página do homem grafana-server.

7.3. Acesso à Grafana web UI

Este procedimento descreve como acessar a interface web do Grafana e gerar gráficos usando diferentes tipos de fontes de dados.

Pré-requisitos

Procedimento

  1. No sistema do cliente, abra um navegador e acesse o site grafana-server na porta 3000, usando http://192.0.2.0:3000 link.

    Substitua 192.0.2.0 pelo IP de sua máquina.

  2. Para o primeiro login, digite admin nos campos username e password.

    Figura 7.1. Página de login da Grafana

    grafana login
  3. Para criar uma conta segura, Grafana solicita a criação de uma nova conta password.
  4. In the pane, hover on the    grafana gear icon    configuration icon > click Plugins > in the Filter by name or type, type performance co-pilot > click Performance Co-Pilot plugin and > click Enable to enable the grafana-pcp plugin.

    Figura 7.2. Painel de controle doméstico

    grafana dashboard
    Nota

    The top corner of the screen has a similar    grafana top corner settings icon    icon, but it controls the general Dashboard settings.

  5. Click the    Grafana logo    icon to view the Home Dashboard.
  6. No site Home Dashboard, clique Add data source para adicionar fontes de dados PCP Redis, PCP bpftrace, e PCP Vector.

    Para mais informações sobre como adicionar PCP Redis, PCP bpftrace e fontes de dados PCP Vector, veja:

  7. Optional: In the pane, hover on the    grafana logout option icon    icon to change the Preferences or to Sign out.

Etapas de verificação

  • Certifique-se de que o plug-in Performance Co-Pilot esteja habilitado:

    # grafana-cli plugins ls | grep performancecopilot-pcp-app
    performancecopilot-pcp-app @ 1.0.5

Recursos adicionais

  • A página do homem grafana-cli.
  • A página do homem grafana-server.

7.4. Adicionando PCP Redis como fonte de dados

A fonte de dados PCP Redis visualiza tudo o que o arquivo contém e consulta a capacidade das séries temporais fornecidas pela linguagem pmseries. Ele analisa os dados em vários hosts. Este procedimento descreve como adicionar o PCP Redis como fonte de dados e como visualizar o painel de controle com uma visão geral das métricas úteis.

Pré-requisitos

Procedimento

  1. Click the    Grafana logo    icon > click Add data source > in the Filter by name or type, type redis > and click PCP Redis > in the URL field, accept the given suggestion http://localhost:44322 and > click Save & Test.

    Figura 7.3. Adicionando PCP Redis na fonte de dados

    pcp redis data sources
  2. In the pane, hover on the    grafana 4 queries icon    filter icon > click Manage > in the Filter Dashboard by name, type pcp redis > select PCP Redis Host Overview to see a dashboard with an overview of any useful metrics.

    Figura 7.4. Visão geral do PCP Redis Host

    PCP redis host overview
  3. In the pane, hover on the    plus sign    icon > click Dashboard option > click Add Query > from the Query list, select the PCP Redis and > in the text field of A, enter metric, for example, kernel.all.load to visualize the kernel load graph.

    Figura 7.5. Consulta PCP Redis

    PCP redis query

Recursos adicionais

  • A página do homem pmseries.

7.5. Estabelecimento de autenticação entre componentes PCP

O PCP suporta o mecanismo de autenticação scram-sha-256 através da estrutura SASL (Simple Authentication Security Layer). Este procedimento descreve como configurar a autenticação usando o mecanismo de autenticação scram-sha-256.

Nota

A partir do Red Hat Enterprise Linux 8.3, o PCP suporta o mecanismo de autenticação scram-sha-256.

Pré-requisitos

  • Instalar a estrutura sasl para o mecanismo de autenticação scram-sha-256:

    # yum instalar cyrus-sasl-scram cyrus-sasl-lib

Procedimento

  1. Especifique o mecanismo de autenticação suportado e o caminho do banco de dados do usuário no arquivo pmcd.conf:

    # vi /etc/sasl2/pmcd.conf
    
    mech_list: scram-sha-256
    
    sasldb_path: /etc/pcp/passwd.db
  2. Criar um novo usuário:

    # useradd -r metrics

    Substitua metrics pelo seu nome de usuário.

  3. Adicione o usuário criado no banco de dados do usuário:

    # saslpasswd2 -a pmcd metrics
    
    Password:
    Again (for verification):
  4. Defina as permissões do banco de dados do usuário:

    # chown root:pcp /etc/pcp/passwd.db
    # chmod 640 /etc/pcp/passwd.db
  5. Reinicie o serviço pmcd:

    # systemctl restart pmcd

Etapas de verificação

  • Verifique a configuração do sasl:

    # pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

Recursos adicionais

7.6. Adicionando PCP bpftrace como uma fonte de dados

O agente bpftrace permite a introspecção do sistema usando os scripts bpftrace, que usa o Filtro de Pacotes Berkeley melhorado (eBPF) para reunir métricas do kernel e pontos de rastreamento do espaço do usuário. Este procedimento descreve como adicionar o PCP bpftrace como fonte de dados e como visualizar o painel de controle com uma visão geral de quaisquer métricas úteis.

Pré-requisitos

Pré-requisitos

  1. Instale o pacote pcp-pmda-bpftrace:

    # yum instalar pcp-pmda-bpftrace

Procedimento

  1. Edite o arquivo bpftrace.conf e adicione seu usuário, que você criou no site Seção 7.5, “Estabelecimento de autenticação entre componentes PCP”:

    # vi /var/lib/pcp/pmdas/bpftrace/bpftrace.conf
    
    [dynamic_scripts]
    enabled = true
    auth_enabled = true
    allowed_users = root,metrics

    Substitua metrics pelo seu nome de usuário.

  2. Instale o bpftrace PMDA:

    # cd /var/lib/pcp/pmdas/bpftrace/
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bpftrace metrics have appeared ... 7 metrics and 6 values

    O pmda-bpftrace está agora instalado, e só pode ser usado após autenticar seu usuário.

  3. Faça o login na Grafana web UI. Para mais informações, veja Seção 7.3, “Acesso à Grafana web UI”.
  4. Click the    Grafana logo    icon > click Add data source > in the Filter by name or type, type bpftrace > and click PCP bpftrace > in the URL field, accept the given suggestion http://localhost:44322.

    Selecione a opção Auth básica > acrescente as credenciais de usuário criadas no campo User e Password e > clique em Save & Test.

    Figura 7.6. Adicionando PCP bpftrace na fonte de dados

    bpftrace auth
  5. In the pane, hover on the    grafana 4 queries icon    filter icon > click Manage > in the Filter Dashboard by name, type pcp bpftrace > select PCP bpftrace System Analysis to see a dashboard with an overview of useful metrics.

    Figura 7.7. Análise do Sistema PCP bpftrace

    pcp bpftrace bpftrace system analysis

Recursos adicionais

  • A página do homem pmdabpftrace.
  • A página do homem bpftrace.

7.7. Adicionando o PCP Vector como fonte de dados

A fonte de dados do PCP Vector exibe métricas ao vivo e utiliza a métrica pcp. Ela analisa dados para hosts individuais. Este procedimento descreve como adicionar um PCP Vector como fonte de dados e como visualizar o painel de controle com uma visão geral de quaisquer métricas úteis.

Pré-requisitos

Procedimento

  1. Instale o pacote pcp-pmda-bcc:

    # yum instalar pcp-pmda-bcc
  2. Instale o bcc PMDA:

    # cd /var/lib/pcp/pmdas/bcc
    # ./Install
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Initializing, currently in 'notready' state.
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Enabled modules:
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: ['biolatency', 'sysfork',
    [...]
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bcc metrics have appeared ... 1 warnings, 1 metrics and 0 values
  3. Faça o login na Grafana web UI. Para mais informações, veja Seção 7.3, “Acesso à Grafana web UI”.
  4. Click the    Grafana logo    icon > click Add data source > in the Filter by name or type, type vector > and click PCP Vector > in the URL field, accept the given suggestion http://localhost:44322 and > click Save & Test.

    Figura 7.8. Adicionando o PCP Vector na fonte de dados

    pcp vector
  5. In the pane, hover on the    grafana 4 queries icon    icon > click Manage > in the Filter Dashboard by name, type pcp vector > select PCP Vector Host Overview to see a dashboard with an overview of useful metrics.

    Figura 7.9. Visão geral do PCP Vector Host

    pcp vector overview

Recursos adicionais

  • A página do homem pmdabcc.

Capítulo 8. Otimizando o desempenho do sistema usando o console web

Saiba como definir um perfil de desempenho no console web RHEL 8 para otimizar o desempenho do sistema para uma tarefa selecionada.

8.1. Opções de ajuste de desempenho no console web

O Red Hat Enterprise Linux 8 fornece vários perfis de desempenho que otimizam o sistema para as seguintes tarefas:

  • Sistemas que utilizam a área de trabalho
  • Desempenho de produção
  • Desempenho na latência
  • Desempenho da rede
  • Baixo consumo de energia
  • Máquinas virtuais

O serviço tuned otimiza as opções do sistema para corresponder ao perfil selecionado.

No console web, você pode definir o perfil de desempenho que seu sistema utiliza.

Recursos adicionais

8.2. Definição de um perfil de desempenho no console web

Este procedimento utiliza o console web para otimizar o desempenho do sistema para uma tarefa selecionada.

Pré-requisitos

Procedimento

  1. Acesse o console web RHEL 8.

    Para obter detalhes, consulte Login no console web.

  2. Clique em Overview.
  3. No campo Performance Profile, clique no perfil de desempenho atual.

    perfil de desempenho do cockpit pf4

  4. Na caixa de diálogo Change Performance Profile, altere o perfil, se necessário.
  5. Clique em Change Profile.

    mudança de perfil de desempenho do cockpit pf4

Etapas de verificação

  • A aba Overview agora mostra o perfil de desempenho selecionado.

Capítulo 9. Ajuste do programador de discos

O programador de discos é responsável por encomendar os pedidos de E/S submetidos a um dispositivo de armazenamento.

Você pode configurar o agendador de várias maneiras diferentes:

9.1. Mudanças no agendador de discos no RHEL 8

No RHEL 8, os dispositivos de bloqueio suportam apenas a programação de múltiplas filas. Isto permite que o desempenho da camada de bloco seja bem dimensionado com acionamentos rápidos de estado sólido (SSDs) e sistemas multi-core.

Os programadores tradicionais de fila única, que estavam disponíveis na RHEL 7 e versões anteriores, foram removidos.

9.2. Programadores de disco disponíveis

Os seguintes programadores de discos multi-fila são suportados no RHEL 8:

none
Implemente um algoritmo de programação FIFO (first-in first-out). Ele funde os pedidos na camada de blocos genéricos através de um simples cache de última hora.
mq-deadline

Tentativas de proporcionar uma latência garantida para os pedidos a partir do momento em que os pedidos chegam ao agendador.

O agendador mq-deadline ordena as solicitações de E/S em fila de espera em um lote de leitura ou gravação e depois as agende para execução em ordem crescente de endereçamento lógico em bloco (LBA). Por padrão, os lotes de leitura têm precedência sobre os lotes de escrita, porque as aplicações são mais propensas a bloquear nas operações de E/S lidas. Depois de mq-deadline processar um lote, ele verifica há quanto tempo as operações de escrita estão sem tempo de processamento e programa o próximo lote de leitura ou escrita, conforme apropriado.

Este agendador é adequado para a maioria dos casos de uso, mas particularmente aqueles em que as operações de escrita são em sua maioria assíncronas.

bfq

Objetiva sistemas desktop e tarefas interativas.

O programador bfq garante que uma única aplicação nunca esteja utilizando toda a largura de banda. Com efeito, o dispositivo de armazenamento é sempre tão responsivo como se estivesse ocioso. Em sua configuração padrão, bfq concentra-se em fornecer a menor latência em vez de atingir a máxima produtividade.

bfq é baseado no código cfq. Ele não concede o disco a cada processo por uma fatia de tempo fixa, mas atribui um budget medido em número de setores ao processo.

Este agendador é adequado enquanto copia arquivos grandes e o sistema não fica sem resposta neste caso.

kyber

O programador se afina para atingir um objetivo de latência. Você pode configurar as latências alvo para solicitações de leitura e escrita síncrona.

Este programador é adequado para dispositivos rápidos, por exemplo NVMe, SSD, ou outros dispositivos de baixa latência.

9.3. Diferentes programadores de disco para diferentes casos de uso

Dependendo da tarefa que seu sistema executa, os seguintes programadores de disco são recomendados como uma linha de base antes de qualquer tarefa de análise e ajuste:

Tabela 9.1. Agendadores de discos para diferentes casos de uso
Estojo de usoProgramador de discos

HDD tradicional com uma interface SCSI

Use mq-deadline ou bfq.

SSD de alto desempenho ou um sistema vinculado à CPU com armazenamento rápido

Use none, especialmente quando estiver executando aplicações empresariais. Alternativamente, use kyber.

Tarefas de mesa ou interativas

Use bfq.

Convidado virtual

Use mq-deadline. Com um motorista HBA (host bus adapter) com capacidade para várias filas, use none.

9.4. O programador de discos padrão

Os dispositivos de bloqueio utilizam o programador de disco padrão, a menos que você especifique outro programador.

Nota

Para non-volatile Memory Express (NVMe) especificamente, o programador padrão é none e a Red Hat recomenda não alterar isto.

O kernel seleciona um programador de disco padrão com base no tipo de dispositivo. O programador selecionado automaticamente é tipicamente a configuração ideal. Se você precisar de um agendador diferente, a Red Hat recomenda usar as regras udev ou o aplicativo Tuned para configurá-lo. Combine os dispositivos selecionados e troque o agendador somente para esses dispositivos.

9.5. Determinando o programador de discos ativo

Este procedimento determina qual programador de disco está atualmente ativo em um determinado dispositivo de bloco.

Procedimento

  • Leia o conteúdo do /sys/block/device/queue/scheduler arquivo:

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    No nome do arquivo, substituir device com o nome do dispositivo do bloco, por exemplo sdc.

    O programador ativo está listado entre parênteses rectos ([ ]).

9.6. Ajuste do programador de discos usando o Tuned

Este procedimento cria e permite um perfil Tuned que define um determinado programador de discos para os dispositivos de bloco selecionados. A configuração persiste através de reinicializações do sistema.

Nos seguintes comandos e configurações, substitua:

  • device com o nome do dispositivo do bloco, por exemplo sdf
  • selected-scheduler com o programador de discos que você deseja definir para o dispositivo, por exemplo bfq

Pré-requisitos

Procedimento

  1. Opcional: Selecione um perfil existente em Tuned no qual seu perfil será baseado. Para uma lista dos perfis disponíveis, veja Seção 2.3, “Perfis afinados distribuídos com a RHEL”.

    Para ver qual perfil está atualmente ativo, use:

    $ tuned-adm ativo
  2. Crie um novo diretório para manter seu perfil em Tuned:

    # mkdir /etc/tuned/my-profile
  3. Encontre o identificador único do sistema do dispositivo de bloco selecionado:

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    Nota

    O comando neste exemplo retornará todos os valores identificados como um World Wide Name (WWN) ou número de série associado ao dispositivo de bloco especificado. Embora seja preferível usar um WWN, o WWN nem sempre está disponível para um determinado dispositivo e quaisquer valores retornados pelo comando do exemplo são aceitáveis para uso como o device system unique ID.

  4. Criar o /etc/tuned/my-profile/tuned.conf arquivo de configuração. No arquivo, defina as seguintes opções:

    • Opcional: Incluir um perfil existente:

      [main]
      include=existing-profile
    • Defina o programador de disco selecionado para o dispositivo que corresponda ao identificador da WWN:

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler
      • Substitua IDNAME com o nome do identificador a ser utilizado (por exemplo, ID_WWN).
      • Substitua device system unique id com o valor do identificador escolhido (por exemplo, 0x5002538d00000000).

      Para combinar vários dispositivos na opção devices_udev_regex, coloque os identificadores entre parênteses e separe-os com barras verticais:

    devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. Habilite seu perfil:

    # perfil afinado-adm my-profile
  6. Verificar se o perfil Sintonizado está ativo e aplicado:

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Recursos adicionais

9.7. Ajuste do programador de discos usando as regras do udev

Este procedimento define um determinado programador de discos para dispositivos de bloco específicos usando as regras do udev. A configuração persiste através de reinicializações do sistema.

Nos seguintes comandos e configurações, substitua:

  • device com o nome do dispositivo do bloco, por exemplo sdf
  • selected-scheduler com o programador de discos que você deseja definir para o dispositivo, por exemplo bfq

Procedimento

  1. Encontre o identificador único do sistema do dispositivo de bloqueio:

    $ udevadm info --name=/dev/device | grep -E '(WWN|SERIAL)'
    E: ID_WWN=0x5002538d00000000
    E: ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    E: ID_SERIAL_SHORT=20120501030900000
    Nota

    O comando neste exemplo retornará todos os valores identificados como um World Wide Name (WWN) ou número de série associado ao dispositivo de bloco especificado. Embora seja preferível usar um WWN, o WWN nem sempre está disponível para um determinado dispositivo e quaisquer valores retornados pelo comando do exemplo são aceitáveis para uso como o device system unique ID.

  2. Configurar a regra udev. Crie o arquivo /etc/udev/rules.d/99-scheduler.rules com o seguinte conteúdo:

    ACTION===="add|change==", SUBSYSTEM==="block===="block===="block===="block==", ENVIDNAME}=="device system unique id"\ATTR{queue/scheduler}=="selected-scheduler"
    • Substitua IDNAME com o nome do identificador a ser utilizado (por exemplo, ID_WWN).
    • Substitua device system unique id com o valor do identificador escolhido (por exemplo, 0x5002538d00000000).
  3. Recarregar as regras udev:

    # controle udevadm --regras de carga
  4. Aplique a configuração do agendador:

    # udevadm trigger --type=devices --action=change
  5. Verificar o agendador ativo:

    # gato /sys/bloco/device/queue/scheduler

9.8. Programação temporária de um programador para um disco específico

Este procedimento define um determinado programador de discos para dispositivos de blocos específicos. O ajuste não persiste através de reinicializações do sistema.

Procedimento

  • Escreva o nome do programador selecionado para o /sys/block/device/queue/scheduler arquivo:

    # eco selected-scheduler > /sys/block/device/queue/scheduler

    No nome do arquivo, substituir device com o nome do dispositivo do bloco, por exemplo sdc.

Etapas de verificação

  • Verifique se o programador está ativo no dispositivo:

    # gato /sys/bloco/device/queue/scheduler

Capítulo 10. Ajustando o desempenho de um servidor de Samba

Este capítulo descreve que configurações podem melhorar o desempenho do Samba em determinadas situações, e que configurações podem ter um impacto negativo no desempenho.

Partes desta seção foram adotadas a partir da documentação Performance Tuning publicada no Samba Wiki. Licença: CC BY 4.0. Autores e colaboradores: Veja a guia Histórico na página Wiki.

Pré-requisitos

10.1. Definição da versão do protocolo SMB

Cada nova versão SMB acrescenta características e melhora o desempenho do protocolo. Os recentes sistemas operacionais Windows e Windows Server sempre suportam a última versão do protocolo. Se o Samba também usa a versão mais recente do protocolo, os clientes Windows conectados ao Samba se beneficiam das melhorias de desempenho. No Samba, o valor padrão do protocolo máximo do servidor é definido para a última versão estável do protocolo SMB suportada.

Nota

Para ter sempre a última versão estável do protocolo SMB habilitada, não defina o parâmetro server max protocol. Se você definir o parâmetro manualmente, será necessário modificar a configuração com cada nova versão do protocolo SMB, para ter a última versão do protocolo ativada.

O procedimento seguinte explica como utilizar o valor padrão no parâmetro server max protocol.

Procedimento

  1. Remover o parâmetro server max protocol da seção [global] no arquivo /etc/samba/smb.conf.
  2. Recarregar a configuração do Samba

    # smbcontrol all reload-config

10.2. Tuning shares com diretórios que contêm um grande número de arquivos

Linux suporta nomes de arquivos sensíveis a maiúsculas e minúsculas. Por este motivo, o Samba precisa procurar por nomes de arquivos em maiúsculas e minúsculas ao pesquisar ou acessar um arquivo. Você pode configurar um compartilhamento para criar novos arquivos apenas em letras minúsculas ou maiúsculas, o que melhora o desempenho.

Pré-requisitos

  • O Samba é configurado como um servidor de arquivos

Procedimento

  1. Renomeie todos os arquivos da ação para minúsculas.

    Nota

    Usando as configurações neste procedimento, os arquivos com nomes que não sejam em minúsculas não serão mais exibidos.

  2. Defina os seguintes parâmetros na seção de ações:

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    Para obter detalhes sobre os parâmetros, veja suas descrições na página de manual smb.conf(5).

  3. Verifique o arquivo /etc/samba/smb.conf:

    # testparm
  4. Recarregar a configuração do Samba:

    # smbcontrol all reload-config

Após aplicar estas configurações, os nomes de todos os arquivos recém-criados nesta ação usam letras minúsculas. Devido a estas configurações, o Samba não precisa mais procurar no diretório por letras maiúsculas e minúsculas, o que melhora o desempenho.

10.3. Configurações que podem ter um impacto negativo no desempenho

Por default, o kernel do Red Hat Enterprise Linux está sintonizado para alto desempenho da rede. Por exemplo, o kernel usa um mecanismo de sintonia automática para tamanhos de buffer. A configuração do parâmetro socket options no arquivo /etc/samba/smb.conf substitui estas configurações do kernel. Como resultado, a configuração deste parâmetro diminui o desempenho da rede Samba na maioria dos casos.

Para utilizar as configurações otimizadas do Kernel, remova o parâmetro socket options da seção [global] no site /etc/samba/smb.conf.

Capítulo 11. Otimizando o desempenho da máquina virtual

As máquinas virtuais (VMs) sempre experimentam algum grau de deterioração de desempenho em comparação com o host. As seções seguintes explicam as razões para esta deterioração e fornecem instruções sobre como minimizar o impacto de desempenho da virtualização no RHEL 8, para que seus recursos de infra-estrutura de hardware possam ser utilizados da forma mais eficiente possível.

11.1. O que influencia o desempenho da máquina virtual

Os VMs são executados como processos de espaço do usuário no host. O hipervisor, portanto, precisa converter os recursos do sistema host para que as VMs possam utilizá-los. Como consequência, uma parte dos recursos é consumida pela conversão, e a VM, portanto, não pode alcançar a mesma eficiência de desempenho que o host.

O impacto da virtualização no desempenho do sistema

Razões mais específicas para a perda de desempenho da VM incluem:

  • As CPUs virtuais (vCPUs) são implementadas como threads no host, gerenciadas pelo agendador Linux.
  • As VMs não herdam automaticamente recursos de otimização, tais como NUMA ou páginas enormes, do núcleo do host.
  • As configurações de E/S do disco e da rede do host podem ter um impacto significativo no desempenho da VM.
  • O tráfego de rede normalmente viaja para uma VM através de uma ponte baseada em software.
  • Dependendo dos dispositivos host e de seus modelos, pode haver uma sobrecarga significativa devido à emulação de hardware específico.

A severidade do impacto da virtualização no desempenho da VM é influenciada por uma variedade de fatores, que incluem

  • O número de VMs em funcionamento concomitante.
  • A quantidade de dispositivos virtuais utilizados por cada VM.
  • Os tipos de dispositivos utilizados pelas VMs.
Reduzindo a perda de desempenho da VM

O RHEL 8 oferece uma série de recursos que você pode usar para reduzir os efeitos negativos da virtualização. Destacadamente:

Importante

O ajuste do desempenho da VM pode ter efeitos adversos sobre outras funções de virtualização. Por exemplo, pode tornar mais difícil a migração da VM modificada.

11.2. Otimizando o desempenho da máquina virtual usando o tuned

O utilitário tuned é um mecanismo de ajuste de perfil de entrega que adapta a RHEL para certas características de carga de trabalho, tais como requisitos para tarefas de CPU-intensiva ou de armazenamento-rede de resposta em termos de produtividade. Ele fornece uma série de perfis de ajuste que são pré-configurados para melhorar o desempenho e reduzir o consumo de energia em uma série de casos específicos de uso. Você pode editar esses perfis ou criar novos perfis para criar soluções de desempenho adaptadas ao seu ambiente, incluindo ambientes virtualizados.

A Red Hat recomenda o uso dos seguintes perfis ao usar a virtualização no RHEL 8:

  • Para as máquinas virtuais RHEL 8, utilize o perfil virtual-guest. Baseia-se no perfil geralmente aplicável throughput-performance mas também diminui a permuta da memória virtual.
  • Para os anfitriões de virtualização RHEL 8, use o perfil virtual-host. Isto permite a gravação mais agressiva de páginas de memória suja, o que beneficia o desempenho do host.

Pré-requisitos

Procedimento

Para permitir um perfil específico em tuned:

  1. Liste os perfis disponíveis em tuned.

    # tuned-adm list
    
    Available profiles:
    - balanced             - General non-specialized tuned profile
    - desktop              - Optimize for the desktop use-case
    [...]
    - virtual-guest        - Optimize for running inside a virtual guest
    - virtual-host         - Optimize for running KVM guests
    Current active profile: balanced
  2. Optional: Criar um novo perfil tuned ou editar um perfil tuned já existente.

    Para mais informações, consulte Perfis ajustados de customização.

  3. Ativar um perfil em tuned.

    # tuned-adm profile selected-profile
    • Para otimizar um host de virtualização, utilize o perfil virtual-host.

      # tuned-adm profile virtual-host
    • Em um sistema operacional convidado da RHEL, use o perfil virtual-guest.

      # tuned-adm profile virtual-guest

Recursos adicionais

11.3. Configuração da memória da máquina virtual

Para melhorar o desempenho de uma máquina virtual (VM), você pode atribuir RAM de host adicional para a VM. Da mesma forma, você pode diminuir a quantidade de memória alocada a uma VM para que a memória do host possa ser alocada a outras VMs ou tarefas.

Para realizar estas ações, você pode usar o console web ou a interface de linha de comando.

11.3.1. Adicionar e remover memória de máquina virtual usando o console web

Para melhorar o desempenho de uma máquina virtual (VM) ou para liberar os recursos do host que ela está usando, você pode usar o console web para ajustar a quantidade de memória alocada para a VM.

Pré-requisitos

  • O sistema operacional convidado está executando os drivers do balão de memória. Para verificar este é o caso:

    1. Garantir que a configuração da VM inclua o dispositivo memballoon:

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      Se este comando exibir qualquer saída e o modelo não estiver configurado para none, o dispositivo memballoon está presente.

    2. Certifique-se de que os condutores de balões estejam funcionando no sistema operacional convidado.

  • Para usar o console web para gerenciar as VMs, instale o plug-in de VM do console web.

Procedimento

  1. Optional: Obter as informações sobre a memória máxima e a memória atualmente utilizada para uma VM. Isto servirá como uma base para suas mudanças, e também para verificação.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. Na interface das Máquinas Virtuais, clique em uma linha com o nome das VMs para as quais você deseja visualizar e ajuste a memória alocada.

    A linha se expande para revelar o painel de Visão Geral com informações básicas sobre os VMs selecionados.

  3. Clique no valor da linha Memory no painel de Visão Geral.

    Aparece o diálogo Memory Adjustment.

    virt memory cockpit
  4. Configurar as CPUs virtuais para o VM selecionado.

    • Maximum allocation - Define a quantidade máxima de memória do host que a VM pode usar para seus processos. Aumentar este valor melhora o potencial de desempenho da VM, e reduzir o valor diminui a pegada de desempenho que a VM tem em seu host.

      O ajuste da alocação máxima de memória só é possível em uma VM desligada.

    • Current allocation - Define a quantidade real de memória alocada para o VM. Você pode ajustar o valor para regular a memória disponível para a VM para seus processos. Este valor não pode exceder o valor máximo de alocação.
  5. Clique em Salvar.

    A alocação da memória da VM é ajustada.

Recursos adicionais

11.3.2. Adicionar e remover memória de máquina virtual usando a interface de linha de comando

Para melhorar o desempenho de uma máquina virtual (VM) ou para liberar os recursos do host que ela está usando, você pode usar a CLI para ajustar a quantidade de memória alocada para a VM.

Pré-requisitos

  • O sistema operacional convidado está executando os drivers do balão de memória. Para verificar este é o caso:

    1. Garantir que a configuração da VM inclua o dispositivo memballoon:

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      Se este comando exibir qualquer saída e o modelo não estiver configurado para none, o dispositivo memballoon está presente.

    2. Certifique-se de que os condutores de balões estejam funcionando no sistema operacional convidado.

Procedimento

  1. Optional: Obter as informações sobre a memória máxima e a memória atualmente utilizada para uma VM. Isto servirá como uma base para suas mudanças, e também para verificação.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. Ajuste a memória máxima alocada a uma VM. Aumentar este valor melhora o potencial de desempenho da VM, e reduzir o valor diminui a pegada de desempenho que a VM tem em seu host. Note que esta mudança só pode ser realizada em uma VM desligada, portanto, o ajuste de uma VM em funcionamento requer uma reinicialização para ter efeito.

    Por exemplo, para mudar a memória máxima que o testguest VM pode usar para 4096 MiB:

    # virt-xml testguest --edit --memory memory=4096,currentMemory=4096
    Domain 'testguest' defined successfully.
    Changes will take effect after the domain is fully powered off.
  1. Optional: Você também pode ajustar a memória atualmente utilizada pela VM, até a alocação máxima. Isto regula a carga de memória que a VM tem no host até a próxima reinicialização, sem alterar a alocação máxima da VM.

    # virsh setmem testguest --current 2048

Verificação

  1. Confirmar que a memória utilizada pela VM foi atualizada:

    # virsh dominfo testguest
    Max memory:     4194304 KiB
    Used memory:    2097152 KiB
  2. Optional: Se você ajustar a memória atual da VM, você pode obter as estatísticas do balão de memória da VM para avaliar o quão efetivamente ela regula seu uso de memória.

     # virsh domstats --balloon testguest
    Domain: 'testguest'
      balloon.current=365624
      balloon.maximum=4194304
      balloon.swap_in=0
      balloon.swap_out=0
      balloon.major_fault=306
      balloon.minor_fault=156117
      balloon.unused=3834448
      balloon.available=4035008
      balloon.usable=3746340
      balloon.last-update=1587971682
      balloon.disk_caches=75444
      balloon.hugetlb_pgalloc=0
      balloon.hugetlb_pgfail=0
      balloon.rss=1005456

Recursos adicionais

11.3.3. Recursos adicionais

  • Para aumentar a memória máxima de uma VM em funcionamento, você pode anexar um dispositivo de memória à VM. Isto também é referido como memory hot plug. Para detalhes, consulte Anexando dispositivos a máquinas virtuais.

    Note que remover um dispositivo de memória de um VM, também conhecido como memory hot unplug, não é suportado no RHEL 8, e a Red Hat desencoraja muito seu uso.

11.4. Otimização do desempenho de E/S da máquina virtual

As capacidades de entrada e saída (E/S) de uma máquina virtual (VM) podem limitar significativamente a eficiência geral da VM. Para resolver isso, você pode otimizar a E/S de uma VM configurando os parâmetros de E/S de bloco.

11.4.1. E/S do bloco de sintonia em máquinas virtuais

Quando múltiplos dispositivos de bloco estão sendo usados por uma ou mais VMs, pode ser importante ajustar a prioridade de E/S de dispositivos virtuais específicos, modificando seu I/O weights.

Aumentar o peso de E/S de um dispositivo aumenta sua prioridade para a largura de banda de E/S e, portanto, proporciona mais recursos para o host. Da mesma forma, a redução do peso de um dispositivo faz com que ele consuma menos recursos do host.

Nota

O valor de cada dispositivo weight deve estar dentro da faixa 100 a 1000. Alternativamente, o valor pode ser 0, o que retira esse dispositivo das listas por dispositivo.

Procedimento

Para exibir e definir os parâmetros de E/S de um bloco VM:

  1. Exibir os parâmetros atuais <blkio> para uma VM:

    # virsh dumpxml VM-name

    <domain>
      [...]
      <blkiotune>
        <weight>800</weight>
        <device>
          <path>/dev/sda</path>
          <weight>1000</weight>
        </device>
        <device>
          <path>/dev/sdb</path>
          <weight>500</weight>
        </device>
      </blkiotune>
      [...]
    </domain>
  2. Edite o peso de E/S de um dispositivo especificado:

    # virsh blkiotune VM-name --device-weights device, I/O-weight

    Por exemplo, o seguinte muda o peso do dispositivo /dev/sda no site liftrul VM para 500.

    # virsh blkiotune liftbrul --device-weights /dev/sda, 500

11.4.2. Estrangulamento de E/S de disco em máquinas virtuais

Quando várias VMs estão funcionando simultaneamente, elas podem interferir com o desempenho do sistema, utilizando uma E/S em disco excessiva. A aceleração da E/S do disco na virtualização KVM proporciona a capacidade de definir um limite nas solicitações de E/S do disco enviadas pelas VMs para a máquina host. Isto pode evitar que uma VM utilize em excesso recursos compartilhados e tenha impacto no desempenho de outras VMs.

Para ativar a aceleração de E/S de disco, defina um limite para as solicitações de E/S de disco enviadas de cada dispositivo de bloco anexado às VMs para a máquina host.

Procedimento

  1. Use o comando virsh domblklist para listar os nomes de todos os dispositivos de disco em uma VM especificada.

    # virsh domblklist rollin-coal
    Target     Source
    ------------------------------------------------
    vda        /var/lib/libvirt/images/rollin-coal.qcow2
    sda        -
    sdb        /home/horridly-demanding-processes.iso
  2. Encontre o dispositivo de bloco hospedeiro onde o disco virtual que você deseja acionar o acelerador está montado.

    Por exemplo, se você quiser acionar o disco virtual sdb da etapa anterior, a saída a seguir mostra que o disco está montado na partição /dev/nvme0n1p3.

    $ lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    zram0                                         252:0    0     4G  0 disk  [SWAP]
    nvme0n1                                       259:0    0 238.5G  0 disk
    ├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
    ├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
    └─nvme0n1p3                                   259:3    0 236.9G  0 part
      └─luks-a1123911-6f37-463c-b4eb-fxzy1ac12fea 253:0    0 236.9G  0 crypt /home
  3. Estabelecer limites de E/S para o dispositivo de bloco usando o comando virsh blkiotune.

    # virsh blkiotune VM-name --parameter device,limit

    O seguinte exemplo aciona o disco sdb no rollin-coal VM para 1000 operações de leitura e gravação de E/S por segundo e para 50 MB por segundo de leitura e gravação de rendimento.

    # virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800

Informações adicionais

  • O estrangulamento de E/S em disco pode ser útil em várias situações, por exemplo, quando VMs pertencentes a diferentes clientes estão funcionando no mesmo host, ou quando são dadas garantias de qualidade de serviço para diferentes VMs. O estrangulamento de E/S de disco também pode ser usado para simular discos mais lentos.
  • O estrangulamento de E/S pode ser aplicado independentemente a cada dispositivo de bloco acoplado a uma VM e suporta limites de rendimento e operações de E/S.
  • A Red Hat não suporta o uso do comando virsh blkdeviotune para configurar a estrangulamento de E/S em VMs. Para mais informações sobre recursos não suportados ao usar o RHEL 8 como um host VM, consulte Recursos não suportados na virtualização do RHEL 8.

11.4.3. Possibilitando o virtio-scsi de múltiplas filas

Ao utilizar virtio-scsi dispositivos de armazenamento em suas máquinas virtuais (VMs), o recurso multi-queue virtio-scsi oferece melhor desempenho de armazenamento e escalabilidade. Ele permite que cada CPU virtual (vCPU) tenha uma fila separada e interrompa a utilização sem afetar outras vCPUs.

Procedimento

  • Para habilitar o suporte de virtio-scsi de várias filas para uma VM específica, adicione o seguinte à configuração XML da VM, onde N é o número total de filas de vCPU:

    <controller type='scsi' index='0' model='virtio-scsi'>
       <driver queues='N' />
    </controller>

11.5. Otimizando o desempenho da CPU da máquina virtual

Assim como as CPUs físicas em máquinas host, as vCPUs são fundamentais para o desempenho da máquina virtual (VM). Como resultado, a otimização das vCPUs pode ter um impacto significativo na eficiência de recursos de suas VMs. Para otimizar sua vCPU:

  1. Ajuste quantos CPUs de host são designados para o VM. Você pode fazer isso usando o CLI ou o console web.
  2. Certifique-se de que o modelo vCPU esteja alinhado com o modelo de CPU do host. Por exemplo, configurar o VM testguest1 para usar o modelo de CPU do host:

    # virt-xml testguest1 --edit --cpu host-model
  3. Desativar a fusão da mesma página do núcleo (KSM).
  4. Se sua máquina host utiliza Acesso de Memória Não-Uniforme (NUMA), você também pode configure NUMA para suas VMs. Isto mapeia a CPU do host e os processos de memória na CPU e processos de memória da VM o mais próximo possível. Com efeito, o NUMA tuning fornece à vCPU um acesso mais simplificado à memória do sistema alocada à VM, o que pode melhorar a eficácia do processamento da vCPU.

    Para maiores detalhes, ver Seção 11.5.3, “Configuração do NUMA em uma máquina virtual” e Seção 11.5.4, “Exemplo de cenário de ajuste de desempenho da vCPU”.

11.5.1. Adicionar e remover CPUs virtuais usando a interface de linha de comando

Para aumentar ou otimizar o desempenho da CPU de uma máquina virtual (VM), você pode adicionar ou remover as CPUs virtuais (vCPUs) atribuídas à VM.

Quando realizado em uma VM em funcionamento, isto também é chamado de vCPU hot plugging e hot unplugging. Entretanto, observe que o hot unplug vCPU não é suportado no RHEL 8, e a Red Hat desencoraja muito seu uso.

Pré-requisitos

  • Optional: Veja o estado atual das vCPUs na VM visada. Por exemplo, para exibir o número de vCPUs no site testguest VM:

    # virsh vcpucount testguest
    maximum      config         4
    maximum      live           2
    current      config         2
    current      live           1

    Esta saída indica que testguest está usando atualmente 1 vCPU, e mais 1 vCPu pode ser conectado a ele para aumentar o desempenho da VM. Entretanto, após a reinicialização, o número de vCPUs testguest usadas mudará para 2, e será possível fazer hot plug em mais 2 vCPUs.

Procedimento

  1. Ajuste o número máximo de vCPUs que podem ser anexadas a uma VM, o que entra em vigor na próxima inicialização da VM.

    Por exemplo, para aumentar a contagem máxima de vCPU para a VM testguest para 8:

    # virsh setvcpus testguest 8 --maximum --config

    Observe que o máximo pode ser limitado pela topologia da CPU, hardware do host, o hipervisor e outros fatores.

  2. Ajuste o número atual de vCPUs acopladas a uma VM, até o máximo configurado na etapa anterior. Por exemplo, o número de vCPUs:

    • Para aumentar o número de vCPUs anexadas à VM em execução testguest para 4:

      # virsh setvcpus testguest 4 --live

      Isto aumenta o desempenho da VM e a pegada de carga do host do testguest até a próxima inicialização da VM.

    • Diminuir permanentemente o número de vCPUs anexadas à testguest VM para 1:

      # virsh setvcpus testguest 1 --config

      Isto diminui o desempenho da VM e a pegada de carga do host do testguest após a próxima inicialização da VM. Entretanto, se necessário, vCPUs adicionais podem ser conectados a quente à VM para aumentar temporariamente seu desempenho.

Verificação

  • Confirme que o estado atual da vCPU para a VM reflete suas mudanças.

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

Recursos adicionais

11.5.2. Gerenciamento de CPUs virtuais usando o console web

Usando o console web RHEL 8, você pode rever e configurar CPUs virtuais usadas pelas máquinas virtuais (VMs) às quais o console web está conectado.

Pré-requisitos

Procedimento

  1. Na interface das Máquinas Virtuais, clique em uma linha com o nome das VMs para as quais você deseja visualizar e configurar os parâmetros da CPU virtual.

    A linha se expande para revelar o painel Visão Geral com informações básicas sobre as VMs selecionadas, incluindo o número de CPUs virtuais, e controles para desligar e excluir a VM.

  2. Clique no número de vCPUs no painel de Visão Geral.

    Aparece o diálogo de detalhes da vCPU.

    cockpit configure vCPUs
    Nota

    O aviso no diálogo de detalhes do vCPU só aparece após as configurações da CPU virtual serem alteradas.

  3. Configurar as CPUs virtuais para o VM selecionado.

    • vCPU Count - O número de vCPUs atualmente em uso.

      Nota

      A contagem da vCPU não pode ser maior do que a vCPU Máxima.

    • vCPU Maximum - O número máximo de CPUs virtuais que podem ser configuradas para a VM. Se este valor for maior que o vCPU Count, vCPUs adicionais podem ser anexadas à VM.
    • Sockets - O número de tomadas a serem expostas ao VM.
    • Cores per socket - O número de núcleos para cada soquete a ser exposto ao VM.
    • Threads per core - O número de fios para cada núcleo a ser exposto ao VM.

      Note que as opções Sockets, Cores per socket, e Threads per core ajustam a topologia da CPU da VM. Isto pode ser benéfico para o desempenho da vCPU e pode impactar a funcionalidade de certos softwares no sistema operacional convidado. Se uma configuração diferente não for exigida por sua implementação, a Red Hat recomenda manter os valores padrão.

  4. Clique em Aplicar.

    As CPUs virtuais para a VM são configuradas.

    Nota

    As alterações nas configurações da CPU virtual só entram em vigor após o reinício da VM.

Recursos adicionais:

11.5.3. Configuração do NUMA em uma máquina virtual

Os seguintes métodos podem ser usados para configurar as configurações de Acesso Não-Uniforme de Memória (NUMA) de uma máquina virtual (VM) em um host RHEL 8.

Pré-requisitos

  • O host é uma máquina compatível com NUMA. Para detectar se este é o caso, use o comando virsh nodeinfo e veja a linha NUMA cell(s):

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              48
    CPU frequency:       1200 MHz
    CPU socket(s):       1
    Core(s) per socket:  12
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         67012964 KiB

    Se o valor da linha for 2 ou maior, o host é compatível com NUMA.

Procedimento

Para facilidade de uso, você pode configurar uma configuração NUMA da VM usando utilidades e serviços automatizados. Entretanto, é mais provável que a configuração manual do NUMA produza uma melhoria significativa no desempenho.

Automatic methods

  • Defina a política NUMA da VM para Preferred. Por exemplo, para fazer isso para o testguest5 VM:

    # virt-xml testguest5 --edit --vcpus placement=auto
    # virt-xml testguest5 --edit --numatune mode=preferred
  • Habilitar o balanceamento automático NUMA no host:

    # echo 1 > /proc/sys/kernel/numa_balancing
  • Use o comando numad para alinhar automaticamente a CPU da VM com os recursos de memória.

    # numad

Manual methods

  1. Roscas de vCPU específicas de pinos para uma CPU hospedeira específica ou uma gama de CPUs. Isto também é possível em hosts e VMs não-NUMA, e é recomendado como um método seguro de melhoria do desempenho da vCPU.

    Por exemplo, os seguintes comandos pino vCPU fios 0 a 5 do testguest6 VM para hospedar CPUs 1, 3, 5, 7, 9, e 11, respectivamente:

    # virsh vcpupin testguest6 0 1
    # virsh vcpupin testguest6 1 3
    # virsh vcpupin testguest6 2 5
    # virsh vcpupin testguest6 3 7
    # virsh vcpupin testguest6 4 9
    # virsh vcpupin testguest6 5 11

    Em seguida, você pode verificar se isto foi bem sucedido:

    # virsh vcpupin testguest6
    VCPU   CPU Affinity
    ----------------------
    0      1
    1      3
    2      5
    3      7
    4      9
    5      11
  2. Depois de afixar os fios do vCPU, você também pode afixar os fios do processo QEMU associados a uma VM específica para uma CPU host específica ou uma gama de CPUs. Por exemplo, os seguintes comandos fixam a rosca de processo QEMU de testguest6 para CPUs 13 e 15, e verificam se isto foi bem sucedido:

    # virsh emulatorpin testguest6 13,15
    # virsh emulatorpin testguest6
    emulator: CPU Affinity
    ----------------------------------
           *: 13,15
  3. Finalmente, você também pode especificar quais nós do NUMA hospedeiro serão atribuídos especificamente a um determinado VM. Isto pode melhorar o uso da memória do host pelo vCPU da VM. Por exemplo, os comandos a seguir definem testguest6 para usar os nós de host NUMA 3 a 5, e verificar se isto foi bem sucedido:

    # virsh numatune testguest6 --nodeset 3-5
    # virsh numatune testguest6

Recursos adicionais

11.5.4. Exemplo de cenário de ajuste de desempenho da vCPU

Para obter o melhor desempenho possível da vCPU, a Red Hat recomenda o uso do manual vcpupin, emulatorpin e numatune, por exemplo, como no cenário a seguir.

Cenário inicial

  • Seu anfitrião tem as seguintes especificações de hardware:

    • 2 nós NUMA
    • 3 núcleos de CPU em cada nó
    • 2 roscas em cada núcleo

    A saída de virsh nodeinfo de uma máquina desse tipo seria semelhante:

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              12
    CPU frequency:       3661 MHz
    CPU socket(s):       2
    Core(s) per socket:  3
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         31248692 KiB
  • Você pretende modificar uma VM existente para ter 8 vCPUs, o que significa que ela não caberá em um único nó NUMA.

    Portanto, você deve distribuir 4 vCPUs em cada nó NUMA e fazer com que a topologia da vCPU se pareça o mais próximo possível da topologia do hospedeiro. Isto significa que as vCPUs que funcionam como filamentos irmãos de uma determinada CPU física devem ser fixadas para hospedar filamentos no mesmo núcleo. Para obter detalhes, veja o site Solution abaixo:

Solução

  1. Obter as informações sobre a topologia do hospedeiro:

    # virsh capabilities

    A saída deve incluir uma seção que se pareça com a seguinte:

    <topology>
      <cells num="2">
        <cell id="0">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="10" />
            <sibling id="1" value="21" />
          </distances>
          <cpus num="6">
            <cpu id="0" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="1" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="2" socket_id="0" core_id="2" siblings="2,5" />
            <cpu id="3" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="4" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="5" socket_id="0" core_id="2" siblings="2,5" />
          </cpus>
        </cell>
        <cell id="1">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="21" />
            <sibling id="1" value="10" />
          </distances>
          <cpus num="6">
            <cpu id="6" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="7" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="8" socket_id="1" core_id="5" siblings="8,11" />
            <cpu id="9" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="10" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="11" socket_id="1" core_id="5" siblings="8,11" />
          </cpus>
        </cell>
      </cells>
    </topology>
  2. Optional: Teste o desempenho da VM usando as ferramentas e utilitários aplicáveis.
  3. Montar e montar 1 GiB páginas enormes no host:

    1. Adicione a seguinte linha à linha de comando do kernel do host:

      padrão_hugepagesz=1G hugepagesz=1G
    2. Crie o arquivo /etc/systemd/system/hugetlb-gigantic-pages.service com o seguinte conteúdo:

      [Unit]
      Description=HugeTLB Gigantic Pages Reservation
      DefaultDependencies=no
      Before=dev-hugepages.mount
      ConditionPathExists=/sys/devices/system/node
      ConditionKernelCommandLine=hugepagesz=1G
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/etc/systemd/hugetlb-reserve-pages.sh
      
      [Install]
      WantedBy=sysinit.target
    3. Crie o arquivo /etc/systemd/hugetlb-reserve-pages.sh com o seguinte conteúdo:

      #!/bin/sh
      
      nodes_path=/sys/devices/system/node/
      if [ ! -d $nodes_path ]; then
      	echo "ERROR: $nodes_path does not exist"
      	exit 1
      fi
      
      reserve_pages()
      {
      	echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
      }
      
      reserve_pages 4 node1
      reserve_pages 4 node2

      Isto reserva quatro páginas enormes da 1GiB de node1 e quatro páginas enormes da 1GiB de node2.

    4. Tornar executável o roteiro criado na etapa anterior:

      # chmod x /etc/systemd/hugetlb-reserve-pages.sh
    5. Permitir a reserva de páginas enormes na inicialização:

      # systemctl enable hugetlb-gigantic-pages
  4. Use o comando virsh edit para editar a configuração XML da VM que você deseja otimizar, neste exemplo super-VM:

    # virsh edit super-vm
  5. Ajuste a configuração XML da VM da seguinte maneira:

    1. Configure a VM para usar 8 vCPUs estáticas. Use o elemento <vcpu/> para fazer isso.
    2. Fixe cada uma das roscas da vCPU nas roscas correspondentes da CPU hospedeira que ela espelha na topologia. Para fazer isso, use os elementos <vcpupin/> na seção <cputune>.

      Observe que, como mostrado pelo utilitário virsh capabilities acima, os fios da CPU do host não são ordenados seqüencialmente em seus respectivos núcleos. Além disso, as roscas vCPU devem ser fixadas ao conjunto mais alto disponível de núcleos hospedeiros no mesmo nó NUMA. Para uma ilustração da tabela, veja a seção Additional Resources abaixo.

      A configuração XML para as etapas a. e b. pode parecer semelhante a:

      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
    3. Configure o VM para usar 1 página gigantesca GiB:

      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
    4. Configurar os nós NUMA da VM para usar a memória dos nós NUMA correspondentes no host. Para fazer isso, use os elementos <memnode/> na seção <numatune/>:

      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
    5. Certifique-se de que o modo CPU esteja configurado para host-passthrough, e que a CPU utilize o cache no modo passthrough:

      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
  6. A configuração XML resultante da VM deve incluir uma seção similar à seguinte:

    [...]
      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
      <vcpu placement='static'>8</vcpu>
      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
        <numa>
          <cell id="0" cpus="0-3" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="10"/>
              <sibling id="1" value="21"/>
            </distances>
          </cell>
          <cell id="1" cpus="4-7" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="21"/>
              <sibling id="1" value="10"/>
            </distances>
          </cell>
        </numa>
      </cpu>
    </domain>
  7. Optional: Teste o desempenho da VM usando as ferramentas e utilitários aplicáveis para avaliar o impacto da otimização da VM.

Recursos adicionais

  • As tabelas a seguir ilustram as conexões entre as vCPUs e as CPUs anfitriãs às quais elas devem ser fixadas:

    Tabela 11.1. Topologia do hospedeiro

    CPU threads

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    Cores

    0

    1

    2

    3

    4

    5

    Sockets

    0

    1

    NUMA nodes

    0

    1

    Tabela 11.2. Topologia VM

    vCPU threads

    0

    1

    2

    3

    4

    5

    6

    7

    Cores

    0

    1

    2

    3

    Sockets

    0

    1

    NUMA nodes

    0

    1

    Tabela 11.3. Topologia combinada de host e VM

    vCPU threads

     

    0

    1

    2

    3

     

    4

    5

    6

    7

    Host CPU threads

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    Cores

    0

    1

    2

    3

    4

    5

    Sockets

    0

    1

    NUMA nodes

    0

    1

    Neste cenário, existem 2 nós NUMA e 8 vCPUs. Portanto, 4 fios de vCPU devem ser fixados a cada nó.

    Além disso, a Red Hat recomenda deixar pelo menos uma única linha de CPU disponível em cada nó para as operações do sistema hospedeiro.

    Como neste exemplo, cada nó NUMA abriga 3 núcleos, cada um com 2 fios de CPU hospedeira, o conjunto para o nó 0 se traduz como segue:

    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='4'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='5'/>

11.5.5. Desativação da fusão do kernel na mesma página

Embora a fusão da mesma página do kernel (KSM) melhore a densidade da memória, ela aumenta a utilização da CPU e pode afetar adversamente o desempenho geral, dependendo da carga de trabalho. Nestes casos, você pode melhorar o desempenho da máquina virtual (VM) desativando o KSM.

Dependendo de suas necessidades, você pode tanto desativar o KSM para uma única sessão ou persistentemente.

Procedimento

  • Para desativar o KSM para uma única sessão, use o utilitário systemctl para parar ksm e ksmtuned serviços.

    # systemctl stop ksm
    
    # systemctl stop ksmtuned
  • Para desativar o KSM persistentemente, use o utilitário systemctl para desativar ksm e ksmtuned serviços.

    # systemctl disable ksm
    Removed /etc/systemd/system/multi-user.target.wants/ksm.service.
    # systemctl disable ksmtuned
    Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.
Nota

As páginas de memória compartilhadas entre os VMs antes de desativar o KSM continuarão a ser compartilhadas. Para parar de compartilhar, exclua todas as páginas de PageKSM no sistema usando o seguinte comando:

# echo 2 > /sys/kernel/mm/ksm/run

Depois de páginas anônimas substituírem as páginas do KSM, o serviço do kernel khugepaged reconstruirá hugepages transparentes na memória física da VM.

11.6. Otimizando o desempenho da rede de máquinas virtuais

Devido à natureza virtual da placa de interface de rede (NIC) de uma VM, a VM perde uma parte de sua largura de banda de rede alocada ao host, o que pode reduzir a eficiência geral da carga de trabalho da VM. As seguintes dicas podem minimizar o impacto negativo da virtualização no rendimento virtual da placa de interface de rede (vNIC).

Procedimento

Use qualquer um dos métodos a seguir e observe se tem um efeito benéfico no desempenho de sua rede VM:

Habilitar o módulo vhost_net

No host, certifique-se de que o recurso do kernel vhost_net esteja habilitado:

# lsmod | grep vhost
vhost_net              32768  1
vhost                  53248  1 vhost_net
tap                    24576  1 vhost_net
tun                    57344  6 vhost_net

Se a saída deste comando estiver em branco, ative o módulo do kernel vhost_net:

# modprobe vhost_net
Criar uma rede virtio-multi-frequência

Para configurar o recurso multi-queue virtio-net para uma VM, use o comando virsh edit para editar para a configuração XML da VM. No XML, adicione o seguinte na seção <devices>, e substitua N pelo número de vCPUs na VM, até 16:

<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>

Se o VM estiver funcionando, reinicie-o para que as mudanças entrem em vigor.

Pacotes de rede em lotes

Nas configurações Linux VM com um longo caminho de transmissão, a dosagem de pacotes antes de submetê-los ao kernel pode melhorar a utilização do cache. Para configurar o agrupamento de pacotes, use o seguinte comando no host, e substitua tap0 pelo nome da interface de rede que as VMs usam:

# ethtool -C tap0 rx-frames 128
SR-IOV
Se seu NIC hospedeiro suporta SR-IOV, use a designação do dispositivo SR-IOV para seus vNICs. Para mais informações, consulte Gerenciando os dispositivos SR-IOV.

Recursos adicionais

11.7. Ferramentas de monitoramento de desempenho de máquinas virtuais

Para identificar o que consome mais recursos de VM e qual aspecto do desempenho da VM necessita de otimização, podem ser utilizadas ferramentas de diagnóstico de desempenho, tanto gerais quanto específicas de VM.

Ferramentas de monitoramento de desempenho padrão do SO

Para avaliação de desempenho padrão, você pode usar as utilidades fornecidas por padrão por seus sistemas operacionais host e guest:

  • Em seu host RHEL 8, como root, use o utilitário top ou o aplicativo system monitor, e procure qemu e virt na saída. Isto mostra a quantidade de recursos do sistema host que seus VMs estão consumindo.

    • Se a ferramenta de monitoramento mostrar que qualquer um dos processos qemu ou virt consome uma grande parte da CPU ou da capacidade de memória do host, use o utilitário perf para investigar. Para obter detalhes, veja abaixo.
    • Além disso, se um processo de thread vhost_net, chamado por exemplo vhost_net-1234, for exibido como consumindo uma quantidade excessiva de capacidade de CPU do host, considere o uso de recursos de otimização de rede virtual, tais como multi-queue virtio-net.
  • No sistema operacional convidado, use utilitários e aplicações de desempenho disponíveis no sistema para avaliar quais processos consomem mais recursos do sistema.

    • Em sistemas Linux, você pode usar o utilitário top.
    • Em sistemas Windows, você pode usar o aplicativo Task Manager.

perf kvm

Você pode usar o utilitário perf para coletar e analisar estatísticas específicas de virtualização sobre o desempenho de seu host RHEL 8. Para fazer isso:

  1. No host, instale o pacote perf:

    # yum install perf
  2. Use o comando perf kvm stat para exibir as estatísticas do seu host de virtualização:

    • Para o monitoramento em tempo real de seu hipervisor, use o comando perf kvm stat live.
    • Para registrar os dados do seu hipervisor durante um período de tempo, ative o registro usando o comando perf kvm stat record. Após o comando ser cancelado ou interrompido, os dados são salvos no arquivo perf.data.guest, que pode ser analisado usando o comando perf kvm stat report.
  3. Analisar a saída de perf para os tipos de eventos VM-EXIT e sua distribuição. Por exemplo, os eventos PAUSE_INSTRUCTION devem ser pouco freqüentes, mas na saída seguinte, a alta ocorrência deste evento sugere que as CPUs anfitriãs não estão lidando bem com as vCPUs em funcionamento. Em tal cenário, considere desligar algumas de suas VMs ativas, remover as vCPUs dessas VMs, ou ajustar o desempenho das vCPUs.

    # perf kvm stat report
    
    Analyze events for all VMs, all VCPUs:
    
    
                 VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time         Avg time
    
      EXTERNAL_INTERRUPT     365634    31.59%    18.04%      0.42us  58780.59us    204.08us ( +-   0.99% )
               MSR_WRITE     293428    25.35%     0.13%      0.59us  17873.02us      1.80us ( +-   4.63% )
        PREEMPTION_TIMER     276162    23.86%     0.23%      0.51us  21396.03us      3.38us ( +-   5.19% )
       PAUSE_INSTRUCTION     189375    16.36%    11.75%      0.72us  29655.25us    256.77us ( +-   0.70% )
                     HLT      20440     1.77%    69.83%      0.62us  79319.41us  14134.56us ( +-   0.79% )
                  VMCALL      12426     1.07%     0.03%      1.02us   5416.25us      8.77us ( +-   7.36% )
           EXCEPTION_NMI         27     0.00%     0.00%      0.69us      1.34us      0.98us ( +-   3.50% )
           EPT_MISCONFIG          5     0.00%     0.00%      5.15us     10.85us      7.88us ( +-  11.67% )
    
    Total Samples:1157497, Total events handled time:413728274.66us.

    Outros tipos de eventos que podem sinalizar problemas na saída do perf kvm stat incluem:

Para mais informações sobre o uso de perf para monitorar o desempenho da virtualização, consulte a página de manual perf-kvm.

numastat

Para ver a configuração atual de seu sistema NUMA, você pode usar o utilitário numastat, que é fornecido através da instalação do pacote numactl.

O seguinte mostra um host com 4 VMs rodando, cada um obtendo memória de múltiplos nós NUMA. Isto não é ideal para o desempenho do vCPU, e garante o ajuste:

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm)     68     16    357   6936      2      3    147    598  8128
51747 (qemu-kvm)    245     11      5     18   5172   2532      1     92  8076
53736 (qemu-kvm)     62    432   1661    506   4851    136     22    445  8116
53773 (qemu-kvm)   1393      3      1      2     12      0      0   6702  8114
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total              1769    463   2024   7462  10037   2672    169   7837 32434

Em contraste, o que se segue mostra a memória sendo fornecida a cada VM por um único nó, o que é significativamente mais eficiente.

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm)      0      0      7      0   8072      0      1      0  8080
53736 (qemu-kvm)      0      0      7      0      0      0   8113      0  8120
53773 (qemu-kvm)      0      0      7      0      0      0      1   8110  8118
59065 (qemu-kvm)      0      0   8050      0      0      0      0      0  8051
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total                 0      0   8072      0   8072      0   8114   8110 32368

Capítulo 12. Gerenciando o consumo de energia com PowerTOP

Como administrador do sistema, você pode usar o PowerTOP ferramenta para analisar e gerenciar o consumo de energia.

12.1. O propósito do PowerTOP

PowerTOP é um programa que diagnostica questões relacionadas ao consumo de energia e fornece sugestões sobre como prolongar a vida útil da bateria.

O PowerTOP pode fornecer uma estimativa do uso total de energia do sistema e também do uso de energia individual para cada processo, dispositivo, trabalhador do kernel, temporizador e manipulador de interrupções. A ferramenta também pode identificar componentes específicos do kernel e aplicações de espaço do usuário que freqüentemente despertam a CPU.

O Red Hat Enterprise Linux 8 usa a versão 2.x do PowerTOP.

12.2. Usando o PowerTOP

Pré-requisitos

  • Para poder usar PowerTOPCertifique-se de que o pacote powertop tenha sido instalado em seu sistema:

    # yum instalar powertop

12.2.1. Partida PowerTOP

Procedimento

  • Para correr PowerTOPUse o seguinte comando:

    # powertop
Importante

Os laptops devem funcionar com energia de bateria ao executar o comando powertop.

12.2.2. Calibrating PowerTOP

Procedimento

  1. Em um laptop, você pode calibrar o motor de estimativa de potência executando o seguinte comando:

    # powertop --calibrar
  2. Deixe a calibração terminar sem interagir com a máquina durante o processo.

    A calibração leva tempo, pois o processo realiza vários testes, faz ciclos através dos níveis de brilho e liga e desliga os dispositivos.

  3. Quando o processo de calibração estiver concluído, PowerTOP começa como normal. Deixe funcionar por aproximadamente uma hora para coletar dados.

    Quando forem coletados dados suficientes, os valores da estimativa de potência serão exibidos na primeira coluna da tabela de saída.

Nota

Note que powertop --calibrate só pode ser usado em laptops.

12.2.3. Ajuste do intervalo de medição

Por padrão, PowerTOP faz medições em intervalos de 20 segundos.

Se você quiser mudar esta freqüência de medição, use o seguinte procedimento:

Procedimento

  • Execute o comando powertop com a opção --time:

    # powertop --time=time in seconds

12.3. Estatísticas PowerTOP

Enquanto funciona, PowerTOP reúne as estatísticas do sistema.

PowerTOPA saída do produto fornece múltiplas abas:

  • Overview
  • Idle stats
  • Frequency stats
  • Device stats
  • Tunables

Você pode usar as teclas Tab e Shift Tab para percorrer estas abas.

12.3.1. A aba Visão Geral

Na aba Overview, você pode ver uma lista dos componentes que mais freqüentemente enviam despertadores para a CPU ou que consomem mais energia. Os itens na aba Overview, incluindo processos, interrupções, dispositivos e outros recursos, são classificados de acordo com sua utilização.

As colunas adjacentes dentro da guia Overview fornecem as seguintes informações:

Utilização
Estimativa de potência de como o recurso está sendo utilizado.
Eventos/s
Acordos por segundo. O número de despertadores por segundo indica a eficiência do desempenho dos serviços ou dos dispositivos e drivers do kernel. Menos despertadores significa que se consome menos energia. Os componentes são ordenados por quanto mais seu uso de energia pode ser otimizado.
Categoria
Classificação do componente; tal como processo, dispositivo ou temporizador.
Descrição
Descrição do componente.

Se calibrado corretamente, é mostrada também uma estimativa de consumo de energia para cada item listado na primeira coluna.

Além disso, a guia Overview inclui a linha com estatísticas resumidas, como por exemplo:

  • Consumo total de energia
  • Duração restante da bateria (somente se aplicável)
  • Resumo do despertar total por segundo, operações de GPU por segundo, e operações de sistema de arquivo virtual por segundo

12.3.2. A aba de estatísticas de ociosidade

A aba Idle stats mostra o uso dos estados C para todos os processadores e núcleos, enquanto a aba Frequency stats mostra o uso dos estados P incluindo o modo Turbo, se aplicável, para todos os processadores e núcleos. A duração dos estados C ou P é uma indicação de quão bem o uso da CPU foi otimizado. Quanto mais tempo a CPU permanecer nos estados C ou P mais altos (por exemplo, C4 é maior que C3), melhor será a otimização do uso da CPU. O ideal é que a residência seja 90% ou mais no estado C ou P mais alto quando o sistema estiver ocioso.

12.3.3. A aba Estatísticas do dispositivo

A guia Device stats fornece informações semelhantes à guia Overview, mas somente para dispositivos.

12.3.4. A aba Tunables

A guia Tunables contém PowerTOPs sugestões para otimizar o sistema para um menor consumo de energia.

Use as teclas up e down para passar as sugestões, e a tecla enter para ativar ou desativar a sugestão.

Figura 12.1. Saída PowerTOP

powertop output n

Recursos adicionais

Para mais detalhes sobre PowerTOPver a página inicial do PowerTOP.

12.4. Gerando uma saída HTML

Além da saída powertop’s no terminal, você também pode gerar um relatório HTML.

Procedimento

  • Execute o comando powertop com a opção --html:

    # powertop --html=htmlfile.html

    Substituir o parâmetro htmlfile.html pelo nome necessário para o arquivo de saída.

12.5. Otimizando o consumo de energia

Para otimizar o consumo de energia, você pode usar o serviço powertop ou o utilitário powertop2tuned.

12.5.1. Otimização do consumo de energia utilizando o serviço powertop

Você pode usar o serviço powertop para habilitar automaticamente todos PowerTOPsugestões da guia Tunables no porta-malas:

Procedimento

  • Habilite o serviço powertop:

    # systemctl habilita o powertop

12.5.2. O utilitário powertop2tuned

O utilitário powertop2tuned permite que você crie personalizadas Tuned perfis de PowerTOP sugestões.

Por padrão, powertop2tuned cria perfis no diretório /etc/tuned/, e baseia o perfil personalizado no perfil atualmente selecionado Tuned perfil. Por razões de segurança, todos PowerTOP as sintonizações são inicialmente desativadas no novo perfil.

Para habilitar as afinações, você pode:

  • Descomente-os no site /etc/tuned/profile_name/tuned.conf file.
  • Use a opção --enable ou -e para gerar um novo perfil que permita a maioria das sintonizações sugeridas por PowerTOP.

    Alguns ajustes potencialmente problemáticos, como o auto-uspend USB, são desativados por padrão e precisam ser descomentados manualmente.

12.5.3. Otimização do consumo de energia usando o powertop2tuned utility

Pré-requisitos

  • O utilitário powertop2tuned está instalado no sistema:

    # yum instalar tuned-utils

Procedimento

  1. Criar um perfil personalizado:

    # powertop2tuned novo_nome_do_perfil
  2. Ativar o novo perfil:

    # perfil ajustado_nome_novo_do_perfil

Informações adicionais

  • Para uma lista completa de opções que powertop2tuned suporta, use:

    $ powertop2tuned --ajuda

12.5.4. Comparação de powertop.service e powertop2tuned

A otimização do consumo de energia com powertop2tuned é preferida em relação a powertop.service pelas seguintes razões:

  • A utilidade powertop2tuned representa a integração de PowerTOP em Tunedque permite beneficiar das vantagens de ambas as ferramentas.
  • O utilitário powertop2tuned permite o controle fino da sintonia habilitada.
  • Com powertop2tuned, a sintonia potencialmente perigosa não é ativada automaticamente.
  • Com powertop2tuned, o rollback é possível sem reinicialização.

Capítulo 13. Começando com o perfume

Como administrador do sistema, você pode usar a ferramenta perf para coletar e analisar os dados de desempenho de seu sistema.

13.1. Introdução ao perfume

A ferramenta de espaço do usuário perf faz interface com o subsistema baseado no kernel Performance Counters for Linux (PCL). perf é uma ferramenta poderosa que usa a Unidade de Monitoramento de Desempenho (PMU) para medir, registrar e monitorar uma variedade de eventos de hardware e software. perf também suporta tracepoints, kprobes e uprobes.

13.2. Instalando o perf

Este procedimento instala a ferramenta de espaço do usuário perf.

Procedimento

  • Instale a ferramenta perf:

    # yum instalar perf

13.3. Comandos comuns de desempenho

Esta seção fornece uma visão geral dos comandos comumente usados no perf.

Comandos de perf comumente usados

perf stat
Este comando fornece estatísticas gerais para eventos de desempenho comuns, incluindo instruções executadas e ciclos de relógio consumidos. As opções permitem a seleção de eventos que não sejam os eventos de medição padrão.
perf record
Este comando registra os dados de desempenho em um arquivo, perf.data, que pode ser analisado posteriormente usando o comando perf report.
perf report
Este comando lê e exibe os dados de desempenho do arquivo perf.data criado por perf record.
perf list
Este comando lista os eventos disponíveis em uma determinada máquina. Estes eventos variam com base na configuração de hardware e software de monitoramento de desempenho do sistema.
perf top
Este comando executa uma função similar à utilidade top. Ele gera e exibe um perfil de contador de desempenho em tempo real.
perf trace
Este comando executa uma função similar à da ferramenta strace. Ele monitora as chamadas do sistema usadas por uma thread ou processo especificado e todos os sinais recebidos por aquela aplicação.
perf help
Este comando exibe uma lista completa dos comandos perf.

Recursos adicionais

  • Para listar opções adicionais de subcomandos e suas descrições, adicione a opção -h ao comando alvo.

13.4. Perfilamento em tempo real do uso da CPU com perftop

Você pode usar o comando perf top para medir o uso da CPU de diferentes funções em tempo real.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

13.4.1. O propósito do topo perfurado

O comando perf top é usado para o perfil do sistema em tempo real e funciona de forma semelhante ao utilitário top. Entretanto, onde o utilitário top geralmente mostra quanto tempo de CPU um determinado processo ou thread está usando, perf top mostra quanto tempo de CPU cada função específica usa. Em seu estado padrão, perf top lhe informa sobre funções sendo usadas em todas as CPUs, tanto no espaço do usuário quanto no espaço do kernel. Para usar perf top, você precisa de acesso root.

13.4.2. Perfilar o uso de CPU com perf top

Este procedimento ativa perf top e faz o perfil de utilização da CPU em tempo real.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.
  • Você tem acesso à raiz

Procedimento

  • Iniciar a interface de monitoramento perf top:

    # perf top

    Exemplo 13.1. Desempenho de topo

    --------------------------------------------------------------------
    PerfTop:   20806 irqs/sec  kernel:57.3%  exact: 100.0% lost: 0/0 drop: 0/0 [4000Hz cycles],  (all, 8 CPUs)
    ---------------------------------------------------------------------
    Overhead  Shared Object       Symbol
       2.20%  [kernel]            [k] do_syscall_64
       2.17%  [kernel]            [k] module_get_kallsym
       1.49%  [kernel]            [k] copy_user_enhanced_fast_string
       1.37%  libpthread-2.29.so  [.] __pthread_mutex_lock
       1.31%  [unknown]           [.] 0000000000000000
       1.07%  [kernel]            [k] psi_task_change
       1.04%  [kernel]            [k] switch_mm_irqs_off
       0.94%  [kernel]            [k] __fget
       0.74%  [kernel]            [k] entry_SYSCALL_64
       0.69%  [kernel]            [k] syscall_return_via_sysret
       0.69%  libxul.so           [.] 0x000000000113f9b0
       0.67%  [kernel]            [k] kallsyms_expand_symbol.constprop.0
       0.65%  firefox             [.] moz_xmalloc
       0.65%  libpthread-2.29.so  [.] __pthread_mutex_unlock_usercnt
       0.60%  firefox             [.] free
       0.60%  libxul.so           [.] 0x000000000241d1cd
       0.60%  [kernel]            [k] do_sys_poll
       0.58%  [kernel]            [k] menu_select
       0.56%  [kernel]            [k] _raw_spin_lock_irqsave
       0.55%  perf                [.] 0x00000000002ae0f3

    No exemplo anterior, a função do kernel do_syscall_64 está usando o maior tempo de CPU.

Recursos adicionais

  • A página do homem perf-top(1).

13.4.3. Interpretação da produção do topo do perf

A coluna "Adiantamento"
Exibe a porcentagem de CPU que uma determinada função está usando.
A coluna "Objeto Compartilhado
Exibe o nome do programa ou biblioteca que está usando a função.
A coluna "Símbolo
Exibe o nome ou símbolo da função. As funções executadas no kernel-space são identificadas por [k] e as funções executadas no espaço do usuário são identificadas por [.].

13.4.4. Por que perf exibe alguns nomes de funções como endereços de funções em bruto

Para funções do núcleo, perf usa as informações do arquivo /proc/kallsyms para mapear as amostras para seus respectivos nomes de funções ou símbolos. Para funções executadas no espaço do usuário, entretanto, é possível ver endereços de funções em bruto, pois o binário é despojado.

O pacote debuginfo do executável deve ser instalado ou, se o executável for uma aplicação desenvolvida localmente, a aplicação deve ser compilada com informações de depuração ativadas (a opção -g no GCC) para exibir os nomes ou símbolos das funções em tal situação.

13.4.5. Habilitação de depuração e repositórios de fonte

Uma instalação padrão do Red Hat Enterprise Linux não habilita os repositórios de depuração e fonte. Estes repositórios contêm informações necessárias para depurar os componentes do sistema e medir seu desempenho.

Procedimento

  • Habilitar os canais do pacote de informações de origem e de depuração:

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    A parte $(uname -i) é automaticamente substituída por um valor correspondente para a arquitetura de seu sistema:

    Nome da arquiteturaValor

    Intel e AMD de 64 bits

    x86_64

    ARM de 64 bits

    aarch64

    IBM POWER

    ppc64le

    IBM Z

    s390x

13.4.6. Obtendo pacotes de debuginfo para uma aplicação ou biblioteca usando GDB

As informações de depuração são necessárias para depurar o código. Para o código que é instalado a partir de um pacote, o GNU Debugger (GDB) reconhece automaticamente as informações de depuração faltantes, resolve o nome do pacote e fornece conselhos concretos sobre como obter o pacote.

Pré-requisitos

  • A aplicação ou biblioteca que você deseja depurar deve ser instalada no sistema.
  • A GDB e a ferramenta debuginfo-install devem ser instaladas no sistema. Para detalhes, veja Configurando para aplicações de depuração.
  • Os canais que fornecem os pacotes debuginfo e debugsource devem ser configurados e habilitados no sistema.

Procedimento

  1. Inicie a GDB anexada à aplicação ou biblioteca que você deseja depurar. A GDB reconhece automaticamente as informações de depuração em falta e sugere um comando para executar.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. Sair da GDB: digite q e confirme com Enter.

    (gdb) q
  3. Execute o comando sugerido pela GDB para instalar os pacotes necessários debuginfo:

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    A ferramenta de gerenciamento de pacotes dnf fornece um resumo das mudanças, pede confirmação e, uma vez confirmada, baixa e instala todos os arquivos necessários.

  4. Caso a GDB não seja capaz de sugerir o pacote debuginfo, siga o procedimento descrito em Obtendo pacotes de debuginfo para uma aplicação ou biblioteca manualmente.

13.5. Contagem de eventos durante a execução do processo

Você pode usar o comando perf stat para contar eventos de hardware e software durante a execução do processo.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

13.5.1. O objetivo do estatuto de perf

O comando perf stat executa um comando especificado, mantém uma contagem contínua das ocorrências de eventos de hardware e software durante a execução dos comandos e gera estatísticas dessas contagens. Se você não especificar nenhum evento, então perf stat conta um conjunto de eventos comuns de hardware e software.

13.5.2. Contando eventos com o perf stat

Você pode usar perf stat para contar ocorrências de eventos de hardware e software durante a execução do comando e gerar estatísticas destas contagens. Por padrão, perf stat opera em modo por linha.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

Procedimento

  • Conte os eventos.

    • A execução do comando perf stat sem acesso root contará apenas os eventos que ocorrem no espaço do usuário:

      $ por stat ls

      Exemplo 13.2. Saída de perf stat sem acesso à raiz

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    1.28 msec task-clock:u               #    0.165 CPUs utilized
                       0      context-switches:u         #    0.000 M/sec
                       0      cpu-migrations:u           #    0.000 K/sec
                     104      page-faults:u              #    0.081 M/sec
               1,054,302      cycles:u                   #    0.823 GHz
               1,136,989      instructions:u             #    1.08  insn per cycle
                 228,531      branches:u                 #  178.447 M/sec
                  11,331      branch-misses:u            #    4.96% of all branches
      
             0.007754312 seconds time elapsed
      
             0.000000000 seconds user
             0.007717000 seconds sys

      Como você pode ver no exemplo anterior, quando perf stat corre sem acesso root, os nomes dos eventos são seguidos por :u, indicando que estes eventos foram contados apenas no espaço do usuário.

    • Para contar tanto os eventos de espaço do usuário quanto do kernel-space, você deve ter acesso à raiz ao rodar perf stat:

      # perf stat ls

      Exemplo 13.3. Saída de perf stat executado com acesso à raiz

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    3.09 msec task-clock                #    0.119 CPUs utilized
                      18      context-switches          #    0.006 M/sec
                       3      cpu-migrations            #    0.969 K/sec
                     108      page-faults               #    0.035 M/sec
               6,576,004      cycles                    #    2.125 GHz
               5,694,223      instructions              #    0.87  insn per cycle
               1,092,372      branches                  #  352.960 M/sec
                  31,515      branch-misses             #    2.89% of all branches
      
             0.026020043 seconds time elapsed
      
             0.000000000 seconds user
             0.014061000 seconds sys
      • Por padrão, perf stat opera em modo por fio. Para mudar para a contagem de eventos em toda a CPU, passe a opção -a para perf stat. Para contar eventos em toda a CPU, você precisa de acesso root:

        # perf stat -a ls

Recursos adicionais

  • A página do homem perf-stat(1).

13.5.3. Interpretação da produção estatística do perf

perf stat executa um comando especificado e conta as ocorrências de eventos durante a execução dos comandos e exibe as estatísticas dessas contagens em três colunas:

  1. O número de ocorrências contadas para um determinado evento
  2. O nome do evento que foi contado
  3. Quando métricas relacionadas estão disponíveis, uma relação ou porcentagem é exibida após o sinal de hash (#) na coluna mais à direita.

    • Por exemplo, ao executar no modo padrão, perf stat conta tanto os ciclos quanto as instruções e, portanto, calcula e exibe as instruções por ciclo na coluna mais à direita. Você pode ver um comportamento semelhante com relação às falhas de ramos como um percentual de todos os ramos, uma vez que ambos os eventos são contados por default.

13.5.4. Anexando o estatuto de perf a um processo em andamento

Você pode anexar perf stat a um processo em andamento. Isto instruirá perf stat a contar ocorrências de eventos somente nos processos especificados durante a execução de um comando.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

Procedimento

  • Anexar perf stat a um processo em andamento:

    US$ stat -p ID1,ID2 sleep seconds

    O exemplo anterior conta os eventos nos processos com os IDs de ID1 e ID2 por um período de tempo de seconds segundos, conforme ditado usando o comando sleep.

Recursos adicionais

  • A página do homem perf-stat(1).

13.6. Gravação e análise de perfis de desempenho com perf

A ferramenta perf permite que você registre dados de desempenho e os analise posteriormente.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

13.6.1. O propósito do registro de desempenho

O comando perf record mostra os dados de desempenho e os armazena em um arquivo, perf.data, que pode ser lido e visualizado com outros comandos perf. perf.data é gerado no diretório atual e pode ser acessado posteriormente, possivelmente em uma máquina diferente.

Se você não especificar um comando para perf record para gravar durante, ele irá gravar até que você pare o processo manualmente, pressionando Ctrl C. Você pode anexar perf record a processos específicos, passando a opção -p seguida de uma ou mais identificações de processo. Você pode rodar perf record sem acesso root, no entanto, fazendo isso, você só irá samplear os dados de desempenho no espaço do usuário. No modo padrão, perf record usa ciclos de CPU como evento de amostragem e opera no modo por linha com o modo de herança habilitado.

13.6.2. Gravação de um perfil de desempenho sem acesso à raiz

Você pode usar perf record sem acesso root a amostras e registros de dados de desempenho apenas no espaço do usuário.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

Procedimento

  • Amostragem e registro dos dados de desempenho:

    Registro de desempenho de US$ command

    Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.

Recursos adicionais

  • A página do homem perf-record(1).

13.6.3. Gravação de um perfil de desempenho com acesso à raiz

Você pode usar perf record com acesso root a dados de desempenho de amostra e registro tanto no espaço do usuário quanto no espaço do kernel simultaneamente.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.
  • Você tem acesso à raiz.

Procedimento

  • Amostragem e registro dos dados de desempenho:

    # registro de desempenho command

    Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.

Recursos adicionais

  • A página do homem perf-record(1).

13.6.4. Gravação de um perfil de desempenho em modo por UCP

Você pode usar perf record no modo por CPU para amostrar e registrar dados de desempenho tanto no espaço do usuário como no espaço do kernel simultaneamente em todos os threads de uma CPU monitorada. Por padrão, o modo por UCP monitora todas as CPUs online.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Amostragem e registro dos dados de desempenho:

    # registro perf -a command

    Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.

Recursos adicionais

  • A página do homem perf-record(1).

13.6.5. Captura de dados gráficos de chamada com registro de desempenho

Você pode configurar a ferramenta perf record para que ela registre qual função está chamando outras funções no perfil de desempenho. Isto ajuda a identificar um gargalo se vários processos estiverem chamando a mesma função.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Amostra e registro de dados de desempenho com a opção --call-graph:

    Registro de desempenho --call-graph method command
    • Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.
    • Substitua method por um dos seguintes métodos de desenrolamento:

      fp
      Utiliza o método do ponteiro da moldura. Dependendo da otimização do compilador, como com os binários construídos com a opção GCC --fomit-frame-pointer, isto pode não ser capaz de desenrolar a pilha.
      dwarf
      Utiliza as informações do DWARF Call Frame Information para desenrolar a pilha.
      lbr
      Utiliza o último hardware de registro de filial em processadores Intel.

Recursos adicionais

  • A página do homem perf-record(1).

13.6.6. Análise de dados perf.com relatório perf

Você pode usar perf report para exibir e analisar um arquivo perf.data.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.
  • Há um arquivo perf.data no diretório atual.
  • Se o arquivo perf.data foi criado com acesso root, você precisa rodar perf report com acesso root também.

Procedimento

  • Mostrar o conteúdo do arquivo perf.data para análise posterior:

    # relatório perf

    Exemplo 13.4. Exemplo de saída

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] __memset_avx2_erms
       2.13%  perf             [kernel.kallsyms]                 [k] smp_call_function_single
       1.53%  gnome-shell      libc-2.28.so                      [.] __strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] __memmove_avx_unaligned_erms
       0.89%  gnome-shell      libgobject-2.0.so.0.5600.4        [.] g_object_unref
       0.87%  kswapd0          [kernel.kallsyms]                 [k] page_referenced_one
       0.86%  gnome-shell      libc-2.28.so                      [.] __memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] __pthread_getspecific
       0.47%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] 0x0000000000013b1d
       0.45%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_free1
       0.45%  gnome-shell      libgobject-2.0.so.0.5600.4        [.] g_type_check_instance_is_fundamentally_a
       0.44%  gnome-shell      libc-2.28.so                      [.] malloc
       0.41%  swapper          [kernel.kallsyms]                 [k] apic_timer_interrupt
       0.40%  gnome-shell      ld-2.28.so                        [.] _dl_lookup_symbol_x
       0.39%  kswapd0          [kernel.kallsyms]                 [k] __raw_callee_save___pv_queued_spin_unlock

Recursos adicionais

  • A página do homem perf-report(1).

13.6.7. Interpretação da saída do relatório do perf

A tabela exibida ao executar o comando perf report ordena os dados em várias colunas:

A coluna "Custos indiretos
Indica que porcentagem das amostras globais foram coletadas nessa função específica.
A coluna 'Comando'
Diz a você de qual processo as amostras foram coletadas.
A coluna "Objeto Compartilhado
Mostra o nome da imagem ELF de onde vêm as amostras (o nome [kernel.kallsyms] é usado quando as amostras vêm do kernel).
A coluna "Símbolo
Exibe o nome ou símbolo da função.

No modo padrão, as funções são ordenadas em ordem decrescente com aquelas com a maior sobrecarga exibida primeiro.

13.6.8. Por que perf exibe alguns nomes de funções como endereços de funções em bruto

Para funções do núcleo, perf usa as informações do arquivo /proc/kallsyms para mapear as amostras para seus respectivos nomes de funções ou símbolos. Para funções executadas no espaço do usuário, entretanto, é possível ver endereços de funções em bruto, pois o binário é despojado.

O pacote debuginfo do executável deve ser instalado ou, se o executável for uma aplicação desenvolvida localmente, a aplicação deve ser compilada com informações de depuração ativadas (a opção -g no GCC) para exibir os nomes ou símbolos das funções em tal situação.

Nota

Não é necessário executar novamente perf record após a instalação do debuginfo associado a um executável. Basta executar de novo perf report.

13.6.9. Habilitação de depuração e repositórios de fonte

Uma instalação padrão do Red Hat Enterprise Linux não habilita os repositórios de depuração e fonte. Estes repositórios contêm informações necessárias para depurar os componentes do sistema e medir seu desempenho.

Procedimento

  • Habilitar os canais do pacote de informações de origem e de depuração:

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    A parte $(uname -i) é automaticamente substituída por um valor correspondente para a arquitetura de seu sistema:

    Nome da arquiteturaValor

    Intel e AMD de 64 bits

    x86_64

    ARM de 64 bits

    aarch64

    IBM POWER

    ppc64le

    IBM Z

    s390x

13.6.10. Obtendo pacotes de debuginfo para uma aplicação ou biblioteca usando GDB

As informações de depuração são necessárias para depurar o código. Para o código que é instalado a partir de um pacote, o GNU Debugger (GDB) reconhece automaticamente as informações de depuração faltantes, resolve o nome do pacote e fornece conselhos concretos sobre como obter o pacote.

Pré-requisitos

  • A aplicação ou biblioteca que você deseja depurar deve ser instalada no sistema.
  • A GDB e a ferramenta debuginfo-install devem ser instaladas no sistema. Para detalhes, veja Configurando para aplicações de depuração.
  • Os canais que fornecem os pacotes debuginfo e debugsource devem ser configurados e habilitados no sistema.

Procedimento

  1. Inicie a GDB anexada à aplicação ou biblioteca que você deseja depurar. A GDB reconhece automaticamente as informações de depuração em falta e sugere um comando para executar.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. Sair da GDB: digite q e confirme com Enter.

    (gdb) q
  3. Execute o comando sugerido pela GDB para instalar os pacotes necessários debuginfo:

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    A ferramenta de gerenciamento de pacotes dnf fornece um resumo das mudanças, pede confirmação e, uma vez confirmada, baixa e instala todos os arquivos necessários.

  4. Caso a GDB não seja capaz de sugerir o pacote debuginfo, siga o procedimento descrito em Obtendo pacotes de debuginfo para uma aplicação ou biblioteca manualmente.

Capítulo 14. Monitoramento do desempenho do sistema com perf

Como administrador de sistema você pode usar a ferramenta perf para coletar e analisar os dados de desempenho de seu sistema.

14.1. Gravação de um perfil de desempenho em modo por UCP

Você pode usar perf record no modo por CPU para amostrar e registrar dados de desempenho tanto no espaço do usuário como no espaço do kernel simultaneamente em todos os threads de uma CPU monitorada. Por padrão, o modo por UCP monitora todas as CPUs online.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Amostragem e registro dos dados de desempenho:

    # registro perf -a command

    Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.

Recursos adicionais

  • A página do homem perf-record(1).

14.2. Captura de dados gráficos de chamada com registro de desempenho

Você pode configurar a ferramenta perf record para que ela registre qual função está chamando outras funções no perfil de desempenho. Isto ajuda a identificar um gargalo se vários processos estiverem chamando a mesma função.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Amostra e registro de dados de desempenho com a opção --call-graph:

    Registro de desempenho --call-graph method command
    • Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.
    • Substitua method por um dos seguintes métodos de desenrolamento:

      fp
      Utiliza o método do ponteiro da moldura. Dependendo da otimização do compilador, como com os binários construídos com a opção GCC --fomit-frame-pointer, isto pode não ser capaz de desenrolar a pilha.
      dwarf
      Utiliza as informações do DWARF Call Frame Information para desenrolar a pilha.
      lbr
      Utiliza o último hardware de registro de filial em processadores Intel.

Recursos adicionais

  • A página do homem perf-record(1).

14.3. Identificação de CPUs ocupadas com perf

Ao investigar problemas de desempenho em um sistema, você pode usar a ferramenta perf para identificar as CPUs mais ocupadas, a fim de concentrar seus esforços.

14.3.1. Exibição de quais eventos de CPU foram contados com a estatística de perf

Você pode usar perf stat para exibir quais eventos de CPU foram contados, desativando a agregação de contagem de CPU. Você deve contar os eventos no modo de todo o sistema usando a bandeira -a para usar esta funcionalidade.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Conte os eventos com a agregação de contagem de CPU desativada:

    # perf stat -a -A dormir seconds

    O exemplo anterior mostra a contagem de um conjunto padrão de eventos comuns de hardware e software registrados durante um período de tempo de seconds segundos, como ditado pelo comando sleep, sobre cada CPU individual em ordem ascendente, começando por CPU0. Como tal, pode ser útil especificar um evento como os ciclos:

    # perf stat -a -A -e ciclos de sono seconds

14.3.2. Mostrando quais amostras de CPU foram coletadas com relatório de perf

O comando perf record mostra dados de desempenho e armazena esses dados em um arquivo perf.data que pode ser lido com o comando perf report. O comando perf record sempre registra quais amostras de CPU foram coletadas. Você pode configurar perf report para exibir estas informações.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.
  • Há um arquivo perf.data criado com perf record no diretório atual. Se o arquivo perf.data foi criado com acesso root, você precisa rodar perf report também com acesso root.

Procedimento

  • Mostrar o conteúdo do arquivo perf.data para uma análise mais detalhada durante a ordenação por CPU:

    # relatório do perf --classificar cpu
    • Você pode ordenar por CPU e comando para exibir informações mais detalhadas sobre onde o tempo da CPU está sendo gasto:

      # relatório perf --sort cpu,comm

      Este exemplo listará os comandos de todas as CPUs monitoradas por total overhead em ordem decrescente de uso overhead e identificará a CPU na qual o comando foi executado.

Recursos adicionais

14.3.3. Exibição de CPUs específicas durante a elaboração do perfil com perf top

Você pode configurar perf top para exibir CPUs específicas e seu uso relativo enquanto traça o perfil de seu sistema em tempo real.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Inicie a interface perf top enquanto ordena por CPU:

    # perf top --sort cpu

    Este exemplo listará as CPUs e suas respectivas despesas gerais em ordem decrescente de uso em tempo real.

    • Você pode classificar por CPU e comando para obter informações mais detalhadas sobre onde o tempo da CPU está sendo gasto:

      # perf top --sort cpu,comm

      Este exemplo listará os comandos por ordem decrescente de uso total e identificará a CPU na qual o comando foi executado em tempo real.

14.4. Monitoramento de CPUs específicas com perf

Você pode configurar a ferramenta perf para monitorar apenas CPUs específicas de interesse.

14.4.1. Monitoramento de CPUs específicas com registro de perf e relatório de perf

Você pode configurar perf record para apenas uma amostra específica de CPUs de interesse e analisar o arquivo perf.data gerado com perf report para análise posterior.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  1. Amostra e registra os dados de desempenho nas CPU's específicas, gerando um arquivo perf.data:

    • Usando uma lista separada por vírgulas de CPUs:

      # registro perf -C 0,1 sleep seconds

      O exemplo anterior mostra amostras e registra dados em CPUs 0 e 1 por um período de seconds segundos, conforme ditado pelo uso do comando sleep.

    • Usando uma gama de CPUs:

      # registro perf -C 0-2 sleep seconds

      O exemplo anterior mostra e registra dados em todas as CPUs de CPU 0 a 2 por um período de seconds segundos, conforme ditado pelo uso do comando sleep.

  2. Mostrar o conteúdo do arquivo perf.data para análise posterior:

    # relatório perf

    Este exemplo mostrará o conteúdo de perf.data. Se você estiver monitorando várias CPUs e quiser saber quais dados de CPU foram amostrados, veja Mostrando quais amostras de CPU foram coletadas com o relatório perf.

14.4.2. Exibição de CPUs específicas durante a elaboração do perfil com perf top

Você pode configurar perf top para exibir CPUs específicas e seu uso relativo enquanto traça o perfil de seu sistema em tempo real.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Inicie a interface perf top enquanto ordena por CPU:

    # perf top --sort cpu

    Este exemplo listará as CPUs e suas respectivas despesas gerais em ordem decrescente de uso em tempo real.

    • Você pode classificar por CPU e comando para obter informações mais detalhadas sobre onde o tempo da CPU está sendo gasto:

      # perf top --sort cpu,comm

      Este exemplo listará os comandos por ordem decrescente de uso total e identificará a CPU na qual o comando foi executado em tempo real.

14.5. Gerar um arquivo de dados perf.data que seja legível em um dispositivo diferente

Você pode usar a ferramenta perf para registrar dados de desempenho em um arquivo perf.data para ser analisado em um dispositivo diferente.

Pré-requisitos

Procedimento

  1. Capture dados de desempenho que você esteja interessado em investigar mais a fundo:

    # registro perf -a --call-graph fp sono seconds

    Este exemplo geraria um perf.data sobre todo o sistema por um período de seconds segundos, conforme ditado pelo uso do comando sleep. Ele também capturaria dados de gráficos de chamada usando o método do ponteiro de frame.

  2. Gerar um arquivo contendo os símbolos de depuração dos dados registrados:

    # arquivo perf

Etapas de verificação

  • Verifique se o arquivo foi gerado em seu diretório ativo atual:

    # ls perf.data*

    A saída exibirá cada arquivo em seu diretório atual que começa com perf.data. O arquivo será nomeado também:

    perf.data.tar.gz

    ou

    perf data.tar.bz2

Recursos adicionais

14.6. Análise de um arquivo de dados perf.data que foi criado em um dispositivo diferente

Você pode usar a ferramenta perf para analisar um arquivo perf.data que foi gerado em um dispositivo diferente.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.
  • Um arquivo perf.data e um arquivo associado gerado em um dispositivo diferente estão presentes no dispositivo atual que está sendo utilizado.

Procedimento

  1. Copie tanto o arquivo perf.data como o arquivo de arquivo em seu diretório ativo atual.
  2. Extraia o arquivo em ~/.debug:

    # mkdir -p ~/.debug
    # tar xf perf.data.tar.bz2 -C ~/.debug
    Nota

    O arquivo também pode ser nomeado perf.data.tar.gz.

  3. Abra o arquivo perf.data para uma análise mais detalhada:

    # relatório perf

Capítulo 15. Monitoramento do desempenho da aplicação com perf

Esta seção descreve como usar a ferramenta perf para monitorar o desempenho da aplicação.

15.1. Anexar registro de desempenho a um processo em andamento

Pré-requisitos

Você pode anexar perf record a um processo em andamento. Isto instruirá perf record a apenas amostrar e registrar dados de desempenho nos processos especificados.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Anexar perf record a um processo em andamento:

    Registro de $per -p ID1,ID2 sleep seconds

    O exemplo anterior mostra e registra os dados de desempenho dos processos com as identificações do processo ID1 e ID2 por um período de tempo de seconds segundos, conforme ditado usando o comando sleep. Você também pode configurar perf para registrar eventos em threads específicos:

    Registro de $per -t ID1,ID2 sleep seconds
    Nota

    Ao usar a bandeira -t e estipular os identificadores de linha, perf desabilita a herança por padrão. Você pode ativar a herança adicionando a opção --inherit.

15.2. Captura de dados gráficos de chamada com registro de desempenho

Você pode configurar a ferramenta perf record para que ela registre qual função está chamando outras funções no perfil de desempenho. Isto ajuda a identificar um gargalo se vários processos estiverem chamando a mesma função.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Amostra e registro de dados de desempenho com a opção --call-graph:

    Registro de desempenho --call-graph method command
    • Substitua command com o comando que você quer testar os dados durante. Se você não especificar um comando, então perf record fará uma amostragem dos dados até que você os interrompa manualmente, pressionando Ctrl+C.
    • Substitua method por um dos seguintes métodos de desenrolamento:

      fp
      Utiliza o método do ponteiro da moldura. Dependendo da otimização do compilador, como com os binários construídos com a opção GCC --fomit-frame-pointer, isto pode não ser capaz de desenrolar a pilha.
      dwarf
      Utiliza as informações do DWARF Call Frame Information para desenrolar a pilha.
      lbr
      Utiliza o último hardware de registro de filial em processadores Intel.

Recursos adicionais

  • A página do homem perf-record(1).

15.3. Análise de dados perf.com relatório perf

Você pode usar perf report para exibir e analisar um arquivo perf.data.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.
  • Há um arquivo perf.data no diretório atual.
  • Se o arquivo perf.data foi criado com acesso root, você precisa rodar perf report com acesso root também.

Procedimento

  • Mostrar o conteúdo do arquivo perf.data para análise posterior:

    # relatório perf

    Exemplo 15.1. Exemplo de saída

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] __memset_avx2_erms
       2.13%  perf             [kernel.kallsyms]                 [k] smp_call_function_single
       1.53%  gnome-shell      libc-2.28.so                      [.] __strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] __memmove_avx_unaligned_erms
       0.89%  gnome-shell      libgobject-2.0.so.0.5600.4        [.] g_object_unref
       0.87%  kswapd0          [kernel.kallsyms]                 [k] page_referenced_one
       0.86%  gnome-shell      libc-2.28.so                      [.] __memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] __pthread_getspecific
       0.47%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] 0x0000000000013b1d
       0.45%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_free1
       0.45%  gnome-shell      libgobject-2.0.so.0.5600.4        [.] g_type_check_instance_is_fundamentally_a
       0.44%  gnome-shell      libc-2.28.so                      [.] malloc
       0.41%  swapper          [kernel.kallsyms]                 [k] apic_timer_interrupt
       0.40%  gnome-shell      ld-2.28.so                        [.] _dl_lookup_symbol_x
       0.39%  kswapd0          [kernel.kallsyms]                 [k] __raw_callee_save___pv_queued_spin_unlock

Recursos adicionais

  • A página do homem perf-report(1).

Capítulo 16. Acesso à memória de perfil com perf mem

16.1. O propósito do perf mem

O sub-comando mem da ferramenta perf permite a amostragem dos acessos à memória (cargas e armazéns). O comando perf mem fornece informações sobre a latência da memória, tipos de acessos à memória, funções que causam acertos e erros no cache e, através do registro do símbolo de dados, os locais da memória onde esses acertos e erros ocorrem.

16.2. Acesso à memória de amostragem com perf mem

Você pode usar o site perf mem para experimentar acessos de memória em seu sistema. O comando toma as mesmas opções que perf record e perf report, assim como algumas opções exclusivas do subcomando mem. Os dados gravados são armazenados em um arquivo perf.data no diretório atual para análise posterior.

Pré-requisitos

  • Você tem a ferramenta de espaço do usuário perf instalada como descrito em Instalando o perf.

Procedimento

  1. Amostra os acessos à memória:

    # per mem record - um sono seconds

    Este exemplo mostra os acessos à memória em todas as CPUs por um período de seconds segundos, como ditado pelo comando sleep. Você pode substituir o comando sleep por qualquer comando durante o qual você queira amostrar os dados de acesso à memória. Por padrão, perf mem mostra tanto as cargas de memória quanto os armazéns. Você pode selecionar apenas uma operação de memória usando a opção -t e especificando ou "carregar" ou "armazenar" entre perf mem e record. Para cargas, são capturadas informações sobre o nível hierárquico da memória, acessos à memória TLB, bus snoops e bloqueios de memória.

  2. Abra o arquivo perf.data para análise:

    # relatório perf mem

    Se você tiver usado os comandos de exemplo, a saída é:

    Available samples
    35k cpu/mem-loads,ldlat=30/P
    54k cpu/mem-stores/P

    A linha cpu/mem-loads,ldlat=30/P denota os dados coletados sobre as cargas de memória e a linha cpu/mem-stores/P denota os dados coletados sobre os depósitos de memória. Destaque a categoria de interesse e pressione Enter para visualizar os dados:

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 4067062
    Overhead       Samples  Local Weight  Memory access             Symbol                                                                 Shared Object                 Data Symbol                                                     Data Object                            Snoop         TLB access              Locked
       0.07%            29  98            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            26  97            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            25  96            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%             1  2325          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9084                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.06%             1  2247          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%             1  2166          L1 or L1 hit              [.] 0x00000000038140d6                                                 libxul.so                     [.] 0x00007ffd7b84b4a8                                          [stack]                                None          L1 or L2 hit            No
       0.05%             1  2117          Uncached or N/A hit       [k] check_for_unclaimed_mmio                                           [kernel.kallsyms]             [k] 0xffffb092c1842300                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%            22  95            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1898          L1 or L1 hit              [.] 0x0000000002a30e07                                                 libxul.so                     [.] 0x00007f610422e0e0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1878          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.04%            18  94            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.04%             1  1593          Local RAM or RAM hit      [.] 0x00000000026f907d                                                 libxul.so                     [.] 0x00007f3336d50a80                                          anon                                   Hit           L2 miss                 No
       0.03%             1  1399          L1 or L1 hit              [.] 0x00000000037cb5f1                                                 libxul.so                     [.] 0x00007fbe81ef5d78                                          libxul.so                              None          L1 or L2 hit            No
       0.03%             1  1229          LFB or LFB hit            [.] 0x0000000002962aad                                                 libxul.so                     [.] 0x00007fb6f1be2b28                                          anon                                   None          L2 miss                 No
       0.03%             1  1202          LFB or LFB hit            [.] __pthread_mutex_lock                                               libpthread-2.29.so            [.] 0x00007fb75583ef20                                          anon                                   None          L1 or L2 hit            No
       0.03%             1  1193          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.03%             1  1191          L1 or L1 hit              [k] azx_get_delay_from_lpib                                            [kernel.kallsyms]             [k] 0xffffb092ca7efcf0                                          [kernel.kallsyms]                      None          L1 or L2 hit            No

    Alternativamente, você pode classificar seus resultados para investigar diferentes aspectos de interesse ao exibir os dados. Por exemplo, para classificar os dados sobre as cargas de memória por tipo de acessos de memória que ocorrem durante o período de amostragem, em ordem decrescente de despesas gerais que eles contabilizam:

    # perf mem -t load report --sort=mem

    Por exemplo, a saída pode ser:

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 40670
    Overhead       Samples  Memory access
      31.53%          9725  LFB or LFB hit
      29.70%         12201  L1 or L1 hit
      23.03%          9725  L3 or L3 hit
      12.91%          2316  Local RAM or RAM hit
       2.37%           743  L2 or L2 hit
       0.34%             9  Uncached or N/A hit
       0.10%            69  I/O or N/A hit
       0.02%           825  L3 miss

Recursos adicionais

  • Para uma explicação das opções de comando específicas para o subcomando mem, consulte a página de manual perf-mem(1).

16.3. Interpretação da saída do relatório perf mem

A tabela exibida executando o comando perf mem report sem nenhum modificador ordena os dados em várias colunas:

A coluna "Custos indiretos
Indica a porcentagem de amostras totais coletadas nessa função específica.
A coluna "Amostras
Exibe o número de amostras contabilizadas por essa linha.
A coluna "Peso local
Exibe a latência de acesso nos ciclos centrais do processador.
A coluna 'Acesso à Memória'
Exibe o tipo de acesso à memória que ocorreu.
A coluna "Símbolo
Exibe o nome ou símbolo da função.
A coluna "Objeto Compartilhado
Mostra o nome da imagem ELF de onde vêm as amostras (o nome [kernel.kallsyms] é usado quando as amostras vêm do kernel).
A coluna 'Símbolo de dados
Exibe o endereço do local da memória que a fila estava alvejando.
Importante

Muitas vezes, devido à alocação dinâmica da memória ou da memória em pilha sendo acessada, a coluna 'Símbolo de Dados' exibirá um endereço bruto.

A coluna "Snoop
Exibe as transações de ônibus.
A coluna "Acesso TLB"
Exibe acessos à memória TLB.
A coluna "Trancado
Indica se uma função estava ou não bloqueada na memória.

No modo padrão, as funções são ordenadas em ordem decrescente com aquelas com a maior sobrecarga exibida primeiro.

Capítulo 17. Detecção de compartilhamento falso com o perf c2c

17.1. O objetivo do perf c2c

O subcomando c2c da ferramenta perf permite a análise Cache-to-Cache (C2C) de dados compartilhados. Você pode usar o comando perf c2c para inspecionar a contenção da linha de cache para detectar tanto o compartilhamento verdadeiro quanto o falso.

A contenção da linha de cache ocorre quando um núcleo de processador em um sistema de multiprocessamento simétrico (SMP) modifica os itens de dados na mesma linha de cache que está em uso por outros processadores. Todos os outros processadores que usam esta linha de cache devem então invalidar sua cópia e solicitar uma atualizada. Isto pode levar a um desempenho degradado.

The perf c2c command provides the following information: * Cache lines where contention has been detected * Processes reading and writing the data * Instructions causing the contention * The Non-Uniform Memory Access (NUMA) nodes involved in the contention

17.2. Falso compartilhamento

O compartilhamento falso ocorre quando um núcleo de processador em um sistema de multiprocessamento simétrico (SMP) modifica os itens de dados na mesma linha de cache que está em uso por outros processadores para acessar outros itens de dados que não estão sendo compartilhados entre os processadores. Esta modificação inicial exige que os outros processadores que usam a linha de cache invalidem sua cópia e solicitem uma atualizada, apesar dos processadores não precisarem, ou mesmo necessariamente terem acesso a, uma versão atualizada do item de dados modificado.

17.3. Detecção de contenção de linha de cache com o perf c2c

Use o comando perf c2c para detectar a contenção da linha de cache em um sistema. O comando perf c2c suporta as mesmas opções que perf record, assim como algumas opções exclusivas do subcomando c2c. Os dados registrados são armazenados em um arquivo perf.data no diretório atual para análise posterior.

Pré-requisitos

  • A ferramenta de espaço do usuário perf está instalada. Para mais informações, consulte Instalando o perf.

Procedimento

  • Use perf c2c para detectar a contenção da linha de cache:

    # registro perf c2c -a sleep seconds

    Este exemplo mostra e registra dados de contenção de linha de cache em todas as CPU's por um período de seconds como ditado pelo comando sleep. Você pode substituir o comando sleep por qualquer comando sobre o qual você queira coletar dados de contenção da linha de cache.

Recursos adicionais

  • Para uma explicação das opções de comando específicas para o subcomando c2c, consulte a página de manual perf-c2c(1).

17.4. Visualizando um arquivo de dados perf.data gravado com o registro perf c2c

Pré-requisitos

Procedimento

  1. Abra o arquivo perf.data para uma análise mais detalhada:

    # relatório perf c2c --stdio

    Este comando visualiza o arquivo perf.data em vários gráficos dentro do terminal:

    =================================================
               Trace Event Information
    =================================================
     Total records                     :     329219
     Locked Load/Store Operations      :      14654
     Load Operations                   :      69679
     Loads - uncacheable               :          0
     Loads - IO                        :          0
     Loads - Miss                      :       3972
     Loads - no mapping                :          0
     Load Fill Buffer Hit              :      11958
     Load L1D hit                      :      17235
     Load L2D hit                      :         21
     Load LLC hit                      :      14219
     Load Local HITM                   :       3402
     Load Remote HITM                  :      12757
     Load Remote HIT                   :       5295
     Load Local DRAM                   :        976
     Load Remote DRAM                  :       3246
     Load MESI State Exclusive         :       4222
     Load MESI State Shared            :          0
     Load LLC Misses                   :      22274
     LLC Misses to Local DRAM          :        4.4%
     LLC Misses to Remote DRAM         :       14.6%
     LLC Misses to Remote cache (HIT)  :       23.8%
     LLC Misses to Remote cache (HITM) :       57.3%
     Store Operations                  :     259539
     Store - uncacheable               :          0
     Store - no mapping                :         11
     Store L1D Hit                     :     256696
     Store L1D Miss                    :       2832
     No Page Map Rejects               :       2376
     Unable to parse data source       :          1
    
    =================================================
       Global Shared Cache Line Event Information
    =================================================
     Total Shared Cache Lines          :         55
     Load HITs on shared lines         :      55454
     Fill Buffer Hits on shared lines  :      10635
     L1D hits on shared lines          :      16415
     L2D hits on shared lines          :          0
     LLC hits on shared lines          :       8501
     Locked Access on shared lines     :      14351
     Store HITs on shared lines        :     109953
     Store L1D hits on shared lines    :     109449
     Total Merged records              :     126112
    
    =================================================
                     c2c details
    =================================================
     Events                            : cpu/mem-loads,ldlat=30/P
    	                                    : cpu/mem-stores/P
     Cachelines sort on                : Remote HITMs
     Cacheline data groupping          : offset,pid,iaddr
    
    =================================================
    	   Shared Data Cache Line Table
    =================================================
    #
    #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
    # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
    # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
    #
          0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
          1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
          2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
          3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
          4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7
    
    =================================================
          Shared Cache Line Distribution Pareto
    =================================================
    #
    #        ----- HITM -----  -- Store Refs --        Data address                               ---------- cycles ----------       cpu                                     Shared
    #   Num      Rmt      Lcl   L1 Hit  L1 Miss              Offset      Pid        Code address  rmt hitm  lcl hitm      load       cnt               Symbol                Object                  Source:Line  Node{cpu list}
    # .....  .......  .......  .......  .......  ..................  .......  ..................  ........  ........  ........  ........  ...................  ....................  ...........................  ....
    #
      -------------------------------------------------------------
          0     9834     2269   109036      468            0x602180
      -------------------------------------------------------------
              65.51%   55.88%   75.20%    0.00%                 0x0    14604            0x400b4f     27161     26039     26017         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:144   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.41%    0.35%    0.00%    0.00%                 0x0    14604            0x400b56     18088     12601     26671         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.00%    0.00%   24.80%  100.00%                 0x0    14604            0x400b61         0         0         0         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   7.50%    9.92%    0.00%    0.00%                0x20    14604            0x400ba7      2470      1729      1897         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:154   1{122}  2{144}
    	  17.61%   20.89%    0.00%    0.00%                0x28    14604            0x400bc1      2294      1575      1649         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:158   2{53}  3{170}
    	   8.97%   12.96%    0.00%    0.00%                0x30    14604            0x400bdb      2325      1897      1828         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:162   0{96}  3{171}
    
      -------------------------------------------------------------
          1     2832     1119        0        0            0x602100
      -------------------------------------------------------------
    	  29.13%   36.19%    0.00%    0.00%                0x20    14604            0x400bb3      1964      1230      1788         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:155   1{122}  2{144}
    	  43.68%   34.41%    0.00%    0.00%                0x28    14604            0x400bcd      2274      1566      1793         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:159   2{53}  3{170}
    	  27.19%   29.40%    0.00%    0.00%                0x30    14604            0x400be7      2045      1247      2011         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:163   0{96}  3{171}

17.5. Interpretação da saída do relatório perf c2c

A visualização exibida ao executar o comando perf c2c report --stdio ordena os dados em várias tabelas:

Informações sobre eventos de rastreamento
Esta tabela fornece um resumo de alto nível de todas as amostras de carga e armazenamento, que são coletadas pelo comando perf c2c record.
Informações sobre eventos da Linha Global Shared Cache
Esta tabela fornece estatísticas sobre as linhas de cache compartilhadas.
c2c Detalhes
Esta tabela fornece informações sobre quais eventos foram amostrados e como os dados do perf c2c report são organizados dentro da visualização.
Tabela de Linha de Cache de Dados Compartilhados
Esta tabela fornece um resumo de uma linha para as linhas de cache mais quentes onde o compartilhamento falso é detectado e é classificado em ordem decrescente pela quantidade de HITMs remotos detectados por linha de cache por padrão.
Distribuição de Linha de Cache compartilhada Pareto

Estas tabelas fornecem uma variedade de informações sobre cada linha de cache com contendas:

  • As linhas do cache estão numeradas na coluna "NUM", começando em 0.
  • O endereço virtual de cada linha de cache está contido na coluna "Offset do endereço de dados" e seguido posteriormente pelo offset na linha de cache onde ocorreram diferentes acessos.
  • A coluna "Pid" contém a identificação do processo.
  • A coluna "Endereço do código" contém o endereço do código do ponteiro de instruções.
  • As colunas sob a etiqueta "ciclos" mostram as latências médias de carga.
  • A coluna "cpu cnt" mostra quantas amostras diferentes de CPUs vieram (essencialmente, quantas CPUs diferentes estavam esperando pelos dados indexados naquele determinado local).
  • A coluna "Símbolo" exibe o nome ou símbolo da função.
  • A coluna "Shared Object" mostra o nome da imagem ELF de onde vêm as amostras (o nome [kernel.kallsyms] é usado quando as amostras vêm do kernel).
  • A coluna "Fonte:Linha" exibe o arquivo fonte e o número da linha.
  • A coluna "Lista de Nó" mostra de quais CPUs específicas vieram amostras para cada nó.

17.6. Detecção de compartilhamento falso com o perf c2c

Pré-requisitos

Procedimento

  1. Abra o arquivo perf.data para uma análise mais detalhada:

    # relatório perf c2c --stdio

    Isto abre o arquivo perf.data no terminal.

  2. Na tabela "Trace Event Information", localize a linha contendo os valores para "LLC Misses to Remote Cache (HITM)":

    =================================================
                Trace Event Information
    =================================================
      Total records                     :     329219
      Locked Load/Store Operations      :      14654
      Load Operations                   :      69679
      Loads - uncacheable               :          0
      Loads - IO                        :          0
      Loads - Miss                      :       3972
      Loads - no mapping                :          0
      Load Fill Buffer Hit              :      11958
      Load L1D hit                      :      17235
      Load L2D hit                      :         21
      Load LLC hit                      :      14219
      Load Local HITM                   :       3402
      Load Remote HITM                  :      12757
      Load Remote HIT                   :       5295
      Load Local DRAM                   :        976
      Load Remote DRAM                  :       3246
      Load MESI State Exclusive         :       4222
      Load MESI State Shared            :          0
      Load LLC Misses                   :      22274
      LLC Misses to Local DRAM          :        4.4%
      LLC Misses to Remote DRAM         :       14.6%
      LLC Misses to Remote cache (HIT)  :       23.8%
      LLC Misses to Remote cache (HITM) : 57.3%
      Store Operations                  :     259539
      Store - uncacheable               :          0
      Store - no mapping                :         11
      Store L1D Hit                     :     256696
      Store L1D Miss                    :       2832
      No Page Map Rejects               :       2376
      Unable to parse data source       :          1

    A porcentagem na coluna de valores da linha "LLC Misses to Remote Cache (HITM)" representa a porcentagem de LLC misses que estavam ocorrendo através dos nós NUMA em linhas de cache modificadas e é um indicador chave de que ocorreu falso compartilhamento.

  3. Inspecione a coluna "Rmt" do campo "LLC Load Hitm" do campo "Shared Data Cache Line Table":

      =================================================
                 Shared Data Cache Line Table
      =================================================
      #
      #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
      # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
      # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
      #
            0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
            1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
            2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
            3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
            4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7

    Esta tabela é classificada em ordem decrescente pela quantidade de HITMs remotos detectados por linha de cache. Um número alto na coluna "Rmt" da seção "LLC Load Hitm" indica falso compartilhamento e requer uma inspeção adicional da linha de cache na qual ocorreu a depuração da atividade de falso compartilhamento.

Capítulo 18. Começando com flamegraphs

Como administrador do sistema, você pode usar flamegraphs para criar visualizações dos dados de desempenho do sistema registrados com a ferramenta perf. Como desenvolvedor de software, você pode usar flamegraphs para criar visualizações de dados de desempenho de aplicativos gravados com a ferramenta perf.

A amostragem de traços de pilha é uma técnica comum para traçar o desempenho da CPU com a ferramenta perf. Infelizmente, os resultados dos traços da pilha de perfis com perf podem ser extremamente verbosos e trabalhosos de análise. flamegraphs são visualizações criadas a partir de dados gravados com perf para tornar a identificação de hot code-paths mais rápida e fácil.

18.1. Instalação de flamegrafos

Para começar a utilizar flamegraphs, instale o pacote necessário:

Procedimento

  • Instale o pacote flamegraphs:

    # yum instalar js-d3-flame-graph

18.2. Criação de flamegrafos em todo o sistema

Este procedimento descreve como visualizar os dados de desempenho registrados em todo um sistema usando flamegraphs.

Pré-requisitos

Procedimento

  • Registrar os dados e criar a visualização:

    # perf script flamegraph -a -F 99 sono 60

    Este comando mostra e registra dados de desempenho sobre todo o sistema por 60 segundos, conforme estipulado pelo uso do comando sleep, e então constrói a visualização que será armazenada no diretório ativo atual como flamegraph.html. O comando irá amostrar por padrão os dados de chamada de dados e toma os mesmos argumentos que a ferramenta perf, neste caso particular:

    -a
    Estipula para registrar dados sobre todo o sistema.
    -F
    Para definir a freqüência de amostragem por segundo.

Etapas de verificação

  • Para análise, veja o flamegraph gerado:

    # xdg-open flamegraph.html

    Este comando abre o flamegraph no navegador padrão:

allcpus flamegraph

18.3. Criação de flamegrafos sobre processos específicos

Você pode usar flamegraphs para visualizar os dados de desempenho registrados em processos específicos de execução.

Pré-requisitos

Procedimento

  • Registrar os dados e criar a visualização:

    # perf script flamegraph -a -F 99 -p ID1,ID2 dormir 60

    Este comando registra amostras e dados de desempenho dos processos com os ID's do processo ID1 e ID2 por 60 segundos, conforme estipulado pelo uso do comando sleep, e depois constrói a visualização que será armazenada no diretório ativo atual como flamegraph.html. O comando irá amostrar por padrão os dados de chamadas de autógrafos e leva os mesmos argumentos que a ferramenta perf, neste caso particular:

    -a
    Estipula para registrar dados sobre todo o sistema.
    -F
    Para definir a freqüência de amostragem por segundo.
    -p
    Estipular identificações de processo específicas para amostragem e registro de dados.

Etapas de verificação

  • Para análise, veja o flamegraph gerado:

    # xdg-open flamegraph.html

    Este comando anterior abre o flamegraph no navegador padrão:

flamegraph

18.4. Interpretação de flamegrafos

Cada caixa no flamegraph representa uma função diferente na pilha. O eixo y mostra a profundidade da pilha com a caixa mais alta em cada pilha sendo a função que estava realmente na UCP e tudo abaixo dela sendo ancestral. O eixo x mostra a população da amostra dos dados do gráfico de chamada. Os filhos de uma pilha em uma determinada fila são exibidos com base no número de amostras coletadas de cada função respectiva em ordem decrescente ao longo do eixo x; o eixo x does not representa a passagem do tempo. Quanto mais ampla for uma caixa individual, mais freqüente ela estava na UCP ou parte de um ancestral da UCP no momento em que os dados estavam sendo amostrados.

IMPORTANTE
As caixas que representam funções de espaço do usuário podem ser etiquetadas como Unknown em flamegraphs porque o binário da função é despojado. O pacote debuginfo do executável deve ser instalado ou, se o executável for uma aplicação desenvolvida localmente, a aplicação deve ser compilada com informações de depuração, a opção -g no GCC, para exibir os nomes ou símbolos da função em tal situação.

flamegraph

Procedimento

  • Para revelar os nomes das funções que podem não ter sido exibidas anteriormente e investigar melhor os dados, clique em uma caixa dentro do flamegraph para ampliar a pilha naquele determinado local:

ampliado em flamegrafia

  • Para retornar à visualização padrão do flamegraph, clique no botão Redefinir Zoom.

Capítulo 19. Alocação de memória de perfil com numastat

Com a ferramenta numastat, você pode exibir estatísticas sobre a alocação de memória em um sistema. A ferramenta numastat exibe os dados para cada nó NUMA separadamente. Você pode usar estas informações para investigar o desempenho da memória de seu sistema ou a eficácia de diferentes políticas de memória em seu sistema.

19.1. Estatísticas numastat por padrão

Por padrão, a ferramenta numastat exibe estatísticas sobre essas categorias de dados para cada nó NUMA:

numa_hit
O número de páginas que foram alocadas com sucesso a este nó.
numa_miss
O número de páginas que foram alocadas neste nó por causa da baixa memória no nó pretendido. Cada evento numa_miss tem um evento correspondente numa_foreign em outro nó.
numa_foreign
O número de páginas inicialmente destinadas a este nó que foram atribuídas a outro nó em seu lugar. Cada evento numa_foreign tem um evento correspondente numa_miss em outro nó.
interleave_hit
O número de páginas de política de intercalação atribuídas com sucesso a este nó.
local_node
O número de páginas alocadas com sucesso neste nó por um processo neste nó.
other_node
O número de páginas alocadas neste nó por um processo em outro nó.
Nota

Os valores altos numa_hit e baixos numa_miss (relativos uns aos outros) indicam um ótimo desempenho.

19.2. Alocação de memória de perfil com numastat

Perfilar a alocação de memória do sistema usando a ferramenta numastat.

Pré-requisitos

  • Você tem o pacote numactl instalado.

Procedimento

  1. Faça o perfil da alocação de memória do seu sistema:

    $ numastat
                                 node0         node1
    numa_hit                  76557759      92126519
    numa_miss                 30772308      30827638
    numa_foreign              30827638      30772308
    interleave_hit              106507        103832
    local_node                76502227      92086995
    other_node                30827840      30867162

Recursos adicionais

  • A página do homem numastat(8).

Capítulo 20. Configuração de um sistema operacional para otimizar a utilização da CPU

Esta seção descreve como configurar o sistema operacional para otimizar a utilização da CPU através de suas cargas de trabalho.

20.1. Ferramentas para monitoramento e diagnóstico de problemas do processador

A seguir estão as ferramentas disponíveis no Red Hat Enterprise Linux 8 para monitorar e diagnosticar problemas de desempenho relacionados ao processador:

  • turbostat imprime resultados de contador em intervalos especificados para ajudar os administradores a identificar comportamentos inesperados nos servidores, tais como uso excessivo de energia, falha em entrar em estados de sono profundo ou interrupções de gerenciamento do sistema (SMIs) sendo criadas desnecessariamente.
  • numactl oferece uma série de opções para gerenciar a afinidade entre processador e memória. O pacote numactl inclui a biblioteca libnuma que oferece uma interface de programação simples para a política NUMA suportada pelo kernel, e pode ser usado para sintonia mais fina do que a aplicação numactl.
  • a ferramentanumastat exibe estatísticas de memória por nó do sistema operacional e seus processos, e mostra aos administradores se a memória do processo está espalhada por um sistema ou se está centralizada em nós específicos. Esta ferramenta é fornecida pelo pacote numactl.
  • numad é um daemon automático de gestão de afinidade NUMA. Ele monitora a topologia NUMA e o uso de recursos dentro de um sistema, a fim de melhorar dinamicamente a alocação e o gerenciamento de recursos NUMA.
  • /proc/interrupts exibe o número da solicitação de interrupção (IRQ), o número de solicitações de interrupção similares tratadas por cada processador no sistema, o tipo de interrupção enviada e uma lista separada por vírgula dos dispositivos que respondem à solicitação de interrupção listada.
  • pqos está disponível no pacote intel-cmt-cat. Ele monitora o cache da CPU e a largura de banda de memória em processadores Intel recentes. Ele monitora:

    • As instruções por ciclo (IPC).
    • A contagem do cache de último nível MISSES.
    • O tamanho em kilobytes que o programa executando em uma determinada CPU ocupa na LLC.
    • A largura de banda para a memória local (MBL).
    • A largura de banda para memória remota (MBR).
  • a ferramentax86_energy_perf_policy permite aos administradores definir a importância relativa do desempenho e da eficiência energética. Estas informações podem então ser usadas para influenciar os processadores que suportam esta característica quando selecionam opções que se alternam entre desempenho e eficiência energética.
  • a ferramentataskset é fornecida pelo pacote util-linux. Ela permite aos administradores recuperar e definir a afinidade do processador de um processo em execução, ou lançar um processo com uma afinidade de processador especificada.

Recursos adicionais

  • Para mais informações, consulte as páginas de homens de turbostat, numactl, numastat, numa, numad, pqos, x86_energy_perf_policy, e taskset.

20.2. Determinação da topologia do sistema

Na computação moderna, a idéia de uma CPU é enganosa, pois a maioria dos sistemas modernos tem vários processadores. A topologia do sistema é a forma como esses processadores estão conectados uns aos outros e a outros recursos do sistema. Isto pode afetar o desempenho do sistema e das aplicações, e as considerações de ajuste de um sistema.

20.2.1. Tipos de topologia de sistema

A seguir estão os dois tipos primários de topologia utilizados na computação moderna:

Topologia Simétrica Multi-Processador (SMP)
A topologia SMP permite que todos os processadores tenham acesso à memória no mesmo período de tempo. Entretanto, como o acesso à memória compartilhada e igualitária força inerentemente o acesso à memória em série de todas as CPUs, as restrições de escala do sistema SMP são agora geralmente vistas como inaceitáveis. Por esta razão, praticamente todos os sistemas de servidores modernos são máquinas NUMA.
Topologia de Acesso à Memória Não-Uniforme (NUMA)

A topologia NUMA foi desenvolvida mais recentemente do que a topologia SMP. Em um sistema NUMA, múltiplos processadores são agrupados fisicamente em um soquete. Cada soquete tem uma área dedicada de memória e processadores que têm acesso local a essa memória, estes são referidos coletivamente como um nó. Os processadores no mesmo nó têm acesso de alta velocidade ao banco de memória desse nó, e acesso mais lento aos bancos de memória que não estão em seu nó.

Portanto, há uma penalidade de desempenho ao acessar a memória não-local. Assim, aplicações sensíveis ao desempenho em um sistema com topologia NUMA devem acessar memória que esteja no mesmo nó que o processador que executa a aplicação, e devem evitar acessar memória remota sempre que possível.

Aplicações com múltiplas roscas sensíveis ao desempenho podem se beneficiar de serem configuradas para executar em um nó NUMA específico em vez de em um processador específico. Se isto é adequado depende de seu sistema e dos requisitos de sua aplicação. Se vários threads de aplicação acessarem os mesmos dados em cache, então a configuração desses threads para execução no mesmo processador pode ser adequada. Entretanto, se várias threads que acessam e armazenam dados diferentes executam no mesmo processador, cada thread pode despejar os dados em cache acessados por uma thread anterior. Isto significa que cada thread 'falha' o cache e desperdiça tempo de execução, recuperando os dados da memória e substituindo-os no cache. Use a ferramenta perf para verificar se há um número excessivo de falhas no cache.

20.2.2. Exibição de topologias de sistemas

Há uma série de comandos que ajudam a entender a topologia de um sistema. Este procedimento descreve como determinar a topologia de um sistema.

Procedimento

  • Para exibir uma visão geral da topologia de seu sistema:

    $ numactl --hardware
    available: 4 nodes (0-3)
    node 0 cpus: 0 4 8 12 16 20 24 28 32 36
    node 0 size: 65415 MB
    node 0 free: 43971 MB
    [...]
  • Reunir as informações sobre a arquitetura da CPU, tais como o número de CPUs, fios, núcleos, soquetes e nós NUMA:

    $ lscpu
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                40
    On-line CPU(s) list:   0-39
    Thread(s) per core:    1
    Core(s) per socket:    10
    Socket(s):             4
    NUMA node(s):          4
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 47
    Model name:            Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
    Stepping:              2
    CPU MHz:               2394.204
    BogoMIPS:              4787.85
    Virtualization:        VT-x
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              256K
    L3 cache:              30720K
    NUMA node0 CPU(s):     0,4,8,12,16,20,24,28,32,36
    NUMA node1 CPU(s):     2,6,10,14,18,22,26,30,34,38
    NUMA node2 CPU(s):     1,5,9,13,17,21,25,29,33,37
    NUMA node3 CPU(s):     3,7,11,15,19,23,27,31,35,39
  • Para ver uma representação gráfica de seu sistema:

    # yum install hwloc-gui
    # lstopo

    Figura 20.1. A saída lstopo

    lstopo
  • Para ver a saída textual detalhada:

    # yum install hwloc
    # lstopo-no-graphics
    Machine (15GB)
      Package L#0 + L3 L#0 (8192KB)
        L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
            PU L#0 (P#0)
            PU L#1 (P#4)
           HostBridge L#0
        PCI 8086:5917
            GPU L#0 "renderD128"
            GPU L#1 "controlD64"
            GPU L#2 "card0"
        PCIBridge
            PCI 8086:24fd
              Net L#3 "wlp61s0"
        PCIBridge
            PCI 8086:f1a6
        PCI 8086:15d7
            Net L#4 "enp0s31f6"

Recursos adicionais

  • Para mais informações, consulte as páginas de manual numactl, lscpu e lstopo.

20.3. Política de programação de sintonia

No Red Hat Enterprise Linux, a menor unidade de execução de processo é chamada de thread. O programador do sistema determina qual processador executa uma thread, e por quanto tempo a thread funciona. Entretanto, como a principal preocupação do agendador é manter o sistema ocupado, ele pode não agendar threads de maneira ideal para o desempenho da aplicação.

Por exemplo, digamos que uma aplicação em um sistema NUMA está rodando no Nó A quando um processador no Nó B se torna disponível. Para manter o processador no Nó B ocupado, o programador move uma das threads da aplicação para o Nó B. Entretanto, a thread da aplicação ainda requer acesso à memória no Nó A. Mas, esta memória levará mais tempo para ser acessada porque a thread agora está rodando no Nó B e a memória do Nó A não é mais local para a thread. Assim, pode levar mais tempo para que a thread termine de rodar no nó B do que levaria para esperar que um processador no nó A ficasse disponível, e então executar a thread no nó original com acesso à memória local.

As aplicações sensíveis ao desempenho muitas vezes se beneficiam do designer ou administrador que determina onde os fios são executados. O programador Linux implementa uma série de políticas de programação que determinam onde e por quanto tempo um thread é executado. A seguir estão as duas principais categorias de políticas de agendamento:

  • Políticas normais: Os fios normais são usados para tarefas de prioridade normal.
  • Políticas em tempo real: As políticas em tempo real são utilizadas para tarefas sensíveis ao tempo que devem ser concluídas sem interrupções. Os fios em tempo real não estão sujeitos a cortes de tempo. Isto significa que a rosca corre até que bloqueie, saia, ceda voluntariamente, ou seja, é preterida por uma rosca de maior prioridade. A rosca de prioridade mais baixa em tempo real é programada antes de qualquer rosca com uma política normal. Para mais informações, consulte Seção 20.3.1, “Programação estática de prioridades com SCHED_FIFO” e Seção 20.3.2, “Agendamento prioritário redondo com SCHED_RR”.

20.3.1. Programação estática de prioridades com SCHED_FIFO

O SCHED_FIFO, também chamado de programação estática de prioridades, é uma política em tempo real que define uma prioridade fixa para cada linha. Esta política permite que os administradores melhorem o tempo de resposta de eventos e reduzam a latência. É recomendável não executar esta política por um período de tempo prolongado para tarefas sensíveis ao tempo.

Quando SCHED_FIFO estiver em uso, o agendador escaneia a lista de todos os tópicos SCHED_FIFO em ordem de prioridade e agenda o tópico de prioridade mais alta que está pronto para rodar. O nível de prioridade de um tópico SCHED_FIFO pode ser qualquer número inteiro de 1 a 99, onde 99 é tratado como a prioridade mais alta. A Red Hat recomenda começar com um número mais baixo e aumentar a prioridade somente quando você identificar problemas de latência.

Atenção

Como as roscas em tempo real não estão sujeitas ao corte do tempo, a Red Hat não recomenda estabelecer uma prioridade como 99. Isto mantém seu processo no mesmo nível de prioridade que as roscas de migração e de vigilância; se sua rosca entrar em um loop computacional e estas roscas estiverem bloqueadas, elas não poderão funcionar. Os sistemas com um único processador acabarão ficando pendurados nesta situação.

Os administradores podem limitar a largura de banda SCHED_FIFO para impedir que programadores de aplicações em tempo real iniciem tarefas em tempo real que monopolizam o processador.

A seguir estão alguns dos parâmetros utilizados nesta política:

/proc/sys/kernel/sched_rt_period_us
Este parâmetro define o período de tempo, em microssegundos, que é considerado como cem por cento da largura de banda do processador. O valor padrão é 1000000 μs, ou 1 second.
/proc/sys/kernel/sched_rt_runtime_us
Este parâmetro define o período de tempo, em microssegundos, que é dedicado à execução de roscas em tempo real. O valor padrão é 950000 μs, ou 0.95 seconds.

20.3.2. Agendamento prioritário redondo com SCHED_RR

O SCHED_RR é uma variante de roupão redondo do site SCHED_FIFO. Esta política é útil quando vários fios precisam ser executados no mesmo nível de prioridade.

Como SCHED_FIFO, SCHED_RR é uma política em tempo real que define uma prioridade fixa para cada linha. O programador escaneia a lista de todos os tópicos SCHED_RR em ordem de prioridade e programa o tópico de prioridade mais alta que está pronto para rodar. Entretanto, ao contrário de SCHED_FIFO, as roscas que têm a mesma prioridade são programadas em estilo round-robin dentro de uma determinada faixa de tempo.

Você pode definir o valor desta fatia de tempo em milissegundos com o parâmetro sched_rr_timeslice_ms kernel no arquivo /proc/sys/kernel/sched_rr_timeslice_ms. O valor mais baixo é 1 millisecond.

20.3.3. Programação normal com SCHED_OTHER

O SCHED_OTHER é a política padrão de agendamento no Red Hat Enterprise Linux 8. Esta política usa o Programador Completamente Justo (CFS) para permitir o acesso justo do processador a todos os threads agendados com esta política. Esta política é mais útil quando há um grande número de threads ou quando o fluxo de dados é uma prioridade, pois permite o agendamento mais eficiente de threads ao longo do tempo.

Quando esta política está em uso, o programador cria uma lista de prioridades dinâmica baseada em parte no valor de simpatia de cada linha de processo. Os administradores podem alterar o valor de agradabilidade de um processo, mas não podem alterar diretamente a lista de prioridades dinâmicas do agendador.

20.3.4. Definição de políticas de agendamento

Verifique e ajuste as políticas e prioridades do programador usando a ferramenta de linha de comando chrt. Ela pode iniciar novos processos com as propriedades desejadas, ou alterar as propriedades de um processo em execução. Também pode ser usado para definir a política em tempo de execução.

Procedimento

  1. Veja o ID do processo (PID) dos processos ativos:

    # ps

    Use a opção --pid ou -p com o comando ps para visualizar os detalhes do PID em particular.

  2. Verifique a política de programação, PID, e prioridade de um processo em particular:

    # chrt -p 468
    pid 468's current scheduling policy: SCHED_FIFO
    pid 468's current scheduling priority: 85
    
    # chrt -p 476
    pid 476's current scheduling policy: SCHED_OTHER
    pid 476's current scheduling priority: 0

    Aqui, 468 e 476 são PID de um processo.

  3. Estabelecer a política de programação de um processo:

    1. Por exemplo, para definir o processo com o PID 1000 para SCHED_FIFO, com prioridade para 50:

      # chrt -f -p 50 1000
    2. Por exemplo, para definir o processo com o PID 1000 para SCHED_OTHER, com prioridade para 0:

      # chrt -o -p 0 1000
    3. Por exemplo, para definir o processo com o PID 1000 para SCHED_RR, com prioridade para 10:

      # chrt -r -p 10 1000
    4. Para iniciar um novo pedido com uma política e prioridade particular, especifique o nome do pedido:

      # chrt -f 36 /bin/my-app

Recursos adicionais

20.3.5. Opções de política para o comando chrt

Para definir a política de agendamento de um processo, use a opção de comando apropriada:

Tabela 20.1. Opções de política para o Comando chrt
Opção curtaOpção longaDescrição

-f

--fifo

Estabelecer cronograma para SCHED_FIFO

-o

--other

Estabelecer cronograma para SCHED_OTHER

-r

--rr

Estabelecer cronograma para SCHED_RR

20.3.6. Mudando a prioridade dos serviços durante o processo de inicialização

Usando o serviço systemd, é possível estabelecer prioridades em tempo real para os serviços lançados durante o processo de inicialização. O unit configuration directives é usado para alterar a prioridade de um serviço durante o processo de inicialização.

A mudança de prioridade do processo de inicialização é feita utilizando as seguintes diretrizes na seção de serviços:

CPUSchedulingPolicy=
Define a política de programação da CPU para os processos executados. É utilizada para definir as políticas other, fifo e rr.
CPUSchedulingPriority=
Define a prioridade de programação da CPU para os processos executados. A faixa de prioridade disponível depende da política de agendamento de CPU selecionada. Para políticas de programação em tempo real, um número inteiro entre 1 (prioridade mais baixa) e 99 (prioridade mais alta) pode ser usado.

O procedimento seguinte descreve como alterar a prioridade de um serviço, durante o processo de inicialização, utilizando o serviço mcelog.

Pré-requisitos

  1. Instale o pacote sintonizado:

    # yum instalar afinado
  2. Habilitar e iniciar o serviço sintonizado:

    # systemctl habilitado --agora sintonizado

Procedimento

  1. Veja as prioridades de agendamento dos fios em execução:

    # tuna --show_threads
                          thread       ctxt_switches
        pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
      1      OTHER     0     0xff      3181          292         systemd
      2      OTHER     0     0xff       254            0        kthreadd
      3      OTHER     0     0xff         2            0          rcu_gp
      4      OTHER     0     0xff         2            0      rcu_par_gp
      6      OTHER     0        0         9            0 kworker/0:0H-kblockd
      7      OTHER     0     0xff      1301            1 kworker/u16:0-events_unbound
      8      OTHER     0     0xff         2            0    mm_percpu_wq
      9      OTHER     0        0       266            0     ksoftirqd/0
    [...]
  2. Criar um arquivo de diretório de configuração de serviços suplementar mcelog e inserir o nome e a prioridade da política neste arquivo:

    # cat <<-EOF > /etc/systemd/system/mcelog.system.d/priority.conf
    
    >
    [SERVICE]
    CPUSchedulingPolicy=_fifo_
    CPUSchedulingPriority=_20_
    EOF
  3. Recarregar a configuração dos scripts do sistema:

    # systemctl daemon-reload
  4. Reinicie o serviço de mcelog:

    # systemctl restart mcelog

Etapas de verificação

  • Exibir a prioridade mcelog definida pela edição systemd:

    # tuna -t mcelog -P
    thread       ctxt_switches
      pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
    826     FIFO    20  0,1,2,3        13            0          mcelog

Recursos adicionais

  • Para mais informações, consulte as páginas de homem de systemd e tuna.
  • Para obter mais informações sobre a faixa de prioridade, consulte Descrição da faixa de prioridade.

20.3.7. Mapa prioritário

As prioridades são definidas em grupos, com alguns grupos dedicados a certas funções do núcleo.

Tabela 20.2. Descrição da faixa de prioridade
PrioridadeTópicosDescrição

1

Roscas de núcleo de baixa prioridade

Esta prioridade é geralmente reservada para as tarefas que precisam estar logo acima do SCHED_OTHER.

2 - 49

Disponível para uso

A gama utilizada para as prioridades de aplicação típicas.

50

Valor padrão do HardIRQ

 

51 - 98

Tópicos de alta prioridade

Use esta faixa para roscas que são executadas periodicamente e devem ter tempos de resposta rápidos. Não utilize esta faixa para roscas vinculadas à CPU, pois você morrerá de fome ao interromper.

99

Cães de guarda e migração

Linhas do sistema que devem funcionar com a maior prioridade.

20.3.8. perfil de partição da cpu

O perfil cpu-partitioning é usado para isolar as CPUs das interrupções no nível do sistema. Uma vez isoladas essas CPUs, é possível alocá-las para aplicações específicas. Isto é muito útil em ambientes de baixa latência ou em ambientes onde você deseja extrair o máximo desempenho do seu hardware.

Este perfil também permite designar CPUs domésticas. Uma CPU doméstica é usada para executar todos os serviços, daemons, processos shell e fios do kernel.

Você pode configurar o perfil cpu-partitioning no arquivo /etc/tuned/cpu-partitioning-variables.conf usando as seguintes opções de configuração:

isolated_cores=cpu-list
Lista CPUs a serem isoladas. A lista de CPUs isoladas é separada por vírgula ou você pode especificar um intervalo usando um traço, como 3-5. Esta opção é obrigatória. Qualquer CPU em falta nesta lista é automaticamente considerada uma CPU doméstica.
no_balance_cores=cpu-list
Lista as CPUs que não são consideradas pelo núcleo durante o balanceamento de carga do processo em todo o sistema. Esta opção é opcional. Esta é normalmente a mesma lista que a isolated_cores.

20.3.9. Recursos adicionais

  • Para mais informações, consulte as páginas de homens de sched, sched_setaffinity, sched_getaffinity, sched_setscheduler, sched_getscheduler, cpuset, tuna, chrt, systemd, e tuned-profiles-cpu-partitioning.

20.4. Configurando o tempo de tick kernel

Por default, o Red Hat Enterprise Linux 8 usa um kernel sem tickless, que não interrompe CPUs ociosas a fim de reduzir o uso de energia e permitir que novos processadores tirem vantagem dos estados de sono profundo.

O Red Hat Enterprise Linux 8 também oferece uma opção dinâmica sem tickless, que é útil para cargas de trabalho sensíveis à latência, tais como computação de alto desempenho ou computação em tempo real. Por default, a opção dinâmica sem tickless está desativada. Este procedimento descreve como ativar de forma persistente o comportamento dinâmico sem tickless.

Procedimento

  1. Para permitir um comportamento dinâmico sem tickless em certos núcleos, especifique esses núcleos na linha de comando do kernel com o parâmetro nohz_full. Em um sistema de 16 núcleos, anexar este parâmetro no arquivo /etc/default/grub:

    nohz_full=1-15

    Isto permite um comportamento dinâmico sem cócegas nos núcleos 1 a 15, movendo-se todo o tempo para o único núcleo não especificado (núcleo 0).

  2. Para ativar persistentemente o comportamento dinâmico sem cócegas, regenerar a configuração do GRUB2 usando o arquivo padrão editado. Em sistemas com firmware BIOS, executar o seguinte comando:

    # grub2-mkconfig -o /etc/grub2.cfg

    Em sistemas com firmware UEFI, executar o seguinte comando:

    # grub2-mkconfig -o /etc/grub2-efi.cfg
  3. Quando o sistema inicia, mova manualmente os fios rcu para o núcleo não sensível à latência, neste caso, o núcleo 0:

    # for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; done
  4. Opcional: Use o parâmetro isolcpus na linha de comando do kernel para isolar certos núcleos das tarefas de espaço do usuário.
  5. Opcional: Ajuste a afinidade da CPU para os fios do kernel write-back bdi-flush para o núcleo de manutenção da casa:

    echo 1 > /sys/bus/workqueue/devices/writeback/cpumask

Etapas de verificação

  • Quando o sistema for reinicializado, verifique se dynticks está habilitado:

    # grep dynticks var/log/dmesg
    [    0.000000] NO_HZ: Full dynticks CPUs: 2-5,8-11
  • Verificar se a configuração dinâmica sem tickless está funcionando corretamente:

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1

    Aqui, stress é um programa que gira sobre a CPU para 1 second.

  • Um possível substituto para stress é um roteiro que executa:

    while :; do d=1; done

    A configuração padrão do temporizador do kernel mostra 1000 ticks em uma CPU ocupada:

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
    1000 irq_vectors:local_timer_entry
  • Com o núcleo dinâmico sem tickless configurado, você deve ver 1 tick em seu lugar:

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
    1 irq_vectors:local_timer_entry

20.5. Ajuste de sistemas de afinidade de interrupção

Um pedido de interrupção ou IRQ é um sinal para atenção imediata enviado de uma peça de hardware para um processador. A cada dispositivo de um sistema é atribuído um ou mais números IRQ que permitem que ele envie interrupções únicas. Quando as interrupções são ativadas, um processador que recebe uma solicitação de interrupção pausa imediatamente a execução do tópico de aplicação atual, a fim de atender à solicitação de interrupção.

Como a interrupção interrompe a operação normal, altas taxas de interrupção podem degradar severamente o desempenho do sistema. É possível reduzir o tempo de interrupção configurando a afinidade da interrupção ou enviando uma série de interrupções de menor prioridade em um lote (coalescendo uma série de interrupções).

Os pedidos de interrupção têm uma propriedade de afinidade associada, smp_affinity, que define os processadores que tratam do pedido de interrupção. Para melhorar o desempenho da aplicação, atribuir afinidade de interrupção e afinidade de processo ao mesmo processador, ou processadores no mesmo núcleo. Isto permite que as linhas de interrupção e de aplicação especificadas compartilhem as linhas de cache.

Em sistemas que suportam a direção de interrupção, modificando a propriedade smp_affinity de um pedido de interrupção configura o hardware para que a decisão de fazer uma interrupção com um determinado processador seja tomada no nível do hardware sem intervenção do kernel.

20.5.1. O balanceamento é interrompido manualmente

Se sua BIOS exporta sua topologia NUMA, o serviço irqbalance pode servir automaticamente as solicitações de interrupção no nó que é local para o serviço de solicitação de hardware.

Procedimento

  1. Verifique quais dispositivos correspondem às solicitações de interrupção que você deseja configurar.
  2. Encontre a especificação de hardware para sua plataforma. Verifique se o chipset em seu sistema suporta interrupções de distribuição.

    1. Se isso acontecer, você pode configurar a interrupção da entrega como descrito nos passos seguintes. Além disso, verifique qual algoritmo seu chipset usa para equilibrar as interrupções. Algumas BIOSes têm opções para configurar a interrupção da entrega.
    2. Caso contrário, seu chipset sempre roteia todas as interrupções para uma única CPU estática. Você não pode configurar qual CPU é utilizada.
  3. Verifique qual modo de Controlador de Interrupção Programável Avançado (APIC) está em uso em seu sistema:

    $ journalctl --dmesg | grep APIC

    Aqui,

    • Se seu sistema usa um modo diferente de flat, você pode ver uma linha similar a Setting APIC routing to physical flat.
    • Se você não puder ver tal mensagem, seu sistema usa o modo flat.

      Se seu sistema usa o modo x2apic, você pode desativá-lo adicionando a opção nox2apic à linha de comando do kernel na configuração bootloader.

      Somente o modo flat não-físico (flat) suporta a distribuição de interrupções para várias CPUs. Este modo está disponível somente para sistemas que tenham até 8 CPUs.

  4. Calcule o smp_affinity mask. Para mais informações sobre como calcular o smp_affinity mask, ver Seção 20.5.2, “Colocando a máscara smp_affinity”.

20.5.2. Colocando a máscara smp_affinity

O valor smp_affinity é armazenado como uma máscara de bit hexadecimal representando todos os processadores do sistema. Cada bit configura uma CPU diferente. O bit menos significativo é a CPU 0. O valor padrão da máscara é f, o que significa que uma solicitação de interrupção pode ser tratada em qualquer processador do sistema. Ajustar este valor para 1 significa que apenas o processador 0 pode lidar com a interrupção.

Procedimento

  1. Em binário, use o valor 1 para CPUs que lidam com as interrupções. Por exemplo, para definir CPU 0 e CPU 7 para lidar com as interrupções, use 0000000010000001 como o código binário:

    Tabela 20.3. Bits binários para CPUs
    CPU1514131211109876543210

    Binário

    0

    0

    0

    0

    0

    0

    0

    0

    1

    0

    0

    0

    0

    0

    0

    1

  2. Converter o código binário em hexadecimal:

    Por exemplo, para converter o código binário usando Python:

    >>> hex(int('0000000010000001', 2))
    
    '0x81'

    Em sistemas com mais de 32 processadores, você deve delimitar os valores smp_affinity para grupos discretos de 32 bits. Por exemplo, se você quiser apenas os primeiros 32 processadores de um sistema com 64 processadores para atender a uma solicitação de interrupção, use 0xffffffff,00000000.

  3. O valor da afinidade de interrupção para uma determinada solicitação de interrupção é armazenado no arquivo /proc/irq/irq_number/smp_affinity associado. Coloque a máscara smp_affinity neste arquivo:

    # máscara echo > /proc/irq/irq_number/smp_affinity

20.5.3. Recursos adicionais

  • Para mais informações, consulte as páginas de homens de irqbalance, journalctl e taskset.

Capítulo 21. Configuração da RHEL para otimizar o acesso aos recursos da rede

Esta seção descreve como configurar a RHEL para apresentar o acesso otimizado aos recursos da rede através de suas cargas de trabalho. Os problemas de desempenho da rede às vezes são resultado de mau funcionamento do hardware ou de infra-estrutura defeituosa. A resolução destes problemas está além do escopo deste documento. O serviço Tuned fornece vários perfis diferentes para melhorar o desempenho em vários casos específicos de uso:

  • latency-performance
  • network-latency
  • network-throughput

21.1. Ferramentas para monitoramento e diagnóstico de problemas de desempenho

A seguir estão as ferramentas disponíveis no Red Hat Enterprise Linux 8, que são usadas para monitorar o desempenho do sistema e diagnosticar problemas de desempenho relacionados com o subsistema de rede:

  • ss é um utilitário de linha de comando. Ele imprime informações estatísticas sobre soquetes, permite aos administradores avaliar o desempenho do dispositivo ao longo do tempo. Por padrão, ss exibe soquetes TCP abertos que não escutam e que têm conexões estabelecidas. Usando opções de linha de comando, os administradores podem filtrar estatísticas sobre soquetes específicos. A Red Hat recomenda ss sobre o depreciado netstat no Red Hat Enterprise Linux
  • ip permite aos administradores gerenciar e monitorar rotas, dispositivos, políticas de roteamento e túneis. O comando de monitoramento ip pode monitorar continuamente o estado dos dispositivos, endereços e rotas. Use a opção -j para exibir a saída no formato JSON, que pode ser fornecida a outras utilidades para automatizar o processamento de informações.
  • dropwatch é uma ferramenta interativa, fornecida pelo pacote dropwatch. Ela monitora e registra os pacotes que são descartados pelo kernel.
  • ethtool é um utilitário que permite aos administradores visualizar e editar as configurações da placa de interface de rede. Use esta ferramenta para observar as estatísticas, tais como o número de pacotes descartados por aquele dispositivo, de certos dispositivos. Usando o ethtool -S device name comando, veja o status dos contadores de um dispositivo especificado do dispositivo que você deseja monitorar.
  • O arquivo /proc/net/snmp exibe dados que o agente snmp utiliza para monitoramento e gerenciamento de IP, ICMP, TCP e UDP. O exame regular deste arquivo ajuda os administradores a identificar valores incomuns e assim identificar potenciais problemas de desempenho. Por exemplo, um aumento nos erros de entrada do UDP (InErrors) no arquivo /proc/net/snmp pode indicar um gargalo em uma fila de recebimento de soquetes.
  • nstat é uma ferramenta de linha de comando, que monitora o SNMP do kernel e as estatísticas da interface de rede. Esta ferramenta lê dados do arquivo /proc/net/snmp e imprime as informações em um formato legível por humanos.
  • Por padrão, os scripts SystemTap, fornecidos pelo pacote systemtap-cliente, estão instalados no diretório /usr/share/systemtap/examples/network:

    • nettop.stp: a cada 5 segundos, o script exibe uma lista de processos (identificador e comando do processo) com o número de pacotes enviados e recebidos e a quantidade de dados enviados e recebidos pelo processo durante esse intervalo.
    • socket-trace.stp: Instrumenta cada uma das funções do arquivo net/socket.c do kernel Linux, e exibe dados de rastreamento.
    • dropwatch.stp: a cada 5 segundos, o script exibe o número de buffers de soquete liberados em locais no núcleo. Use a opção --all-modules para ver nomes simbólicos.
    • latencytap.stp: Este roteiro registra o efeito que diferentes tipos de latência têm sobre um ou mais processos. Ele imprime uma lista de tipos de latência a cada 30 segundos, ordenados em ordem decrescente pelo tempo total que o processo ou processos passaram esperando. Isto pode ser útil para identificar a causa tanto do armazenamento quanto da latência da rede.

    A Red Hat recomenda o uso da opção --all-modules com este script para melhor habilitar o mapeamento de eventos de latência. Por padrão, este script é instalado no diretório /usr/share/systemtap/examples/profiling.

  • BPF Compiler Collection (BCC) é uma biblioteca, que facilita a criação dos programas ampliados Berkeley Packet Filter (eBPF). A principal utilidade dos programas eBPF é analisar o desempenho do sistema operacional e o desempenho da rede sem ter problemas de overhead ou de segurança.

Recursos adicionais

21.2. Gargalos em uma recepção de pacotes

Embora a pilha de rede seja em grande parte auto-optimizadora, há uma série de pontos durante o processamento de pacotes de rede que podem se tornar gargalos e reduzir o desempenho. A seguir estão as questões que podem causar gargalos:

The buffer or ring buffer of the network card
O buffer de hardware pode ser um gargalo se o kernel deixar cair um grande número de pacotes. Use o utilitário ethtool para monitorar um sistema para pacotes descartados.
The hardware or software interrupt queues
As interrupções podem aumentar a latência e a contenção do processador. Para informações sobre como o processador lida com as interrupções, consulte Ajuste de sistemas de Afinidade de Interrupção.
The socket receive queue of the application
Um grande número de pacotes que não são copiados ou por um aumento nos erros de entrada do UDP (InErrors) no arquivo /proc/net/snmp, indica um gargalo na fila de recepção de uma aplicação.

Se um buffer de hardware deixar cair um grande número de pacotes, as poucas soluções potenciais são as seguintes:

Slow the input traffic
Filtrar o tráfego de entrada, reduzir o número de grupos multicast unidos, ou reduzir a quantidade de tráfego de transmissão para diminuir a taxa a que a fila preenche.
Resize the hardware buffer queue

Redimensionar a fila de amortecedores de hardware: Reduzir o número de pacotes que estão sendo descartados, aumentando o tamanho da fila para que ela não transborde tão facilmente. Você pode modificar os parâmetros rx/tx do dispositivo de rede com o comando ethtool:

ethtool --set-ring device-name value

Change the drain rate of the queue
  • Diminuir a taxa de enchimento da fila filtrando ou soltando pacotes antes que eles cheguem à fila, ou baixando o peso do dispositivo. Filtrar o tráfego de entrada ou baixar o peso do dispositivo da placa de interface de rede para diminuir o tráfego de entrada.

    O peso do dispositivo se refere ao número de pacotes que um dispositivo pode receber de uma vez em um único acesso programado do processador. Você pode aumentar a taxa de drenagem de uma fila aumentando o peso de seu dispositivo que é controlado pela configuração do kernel dev_weight. Para alterar temporariamente este parâmetro, altere o conteúdo do arquivo /proc/sys/net/core/dev_weight, ou para alterar permanentemente, use o comando sysctl, que é fornecido pelo pacote procps-ng.

  • Aumentar o comprimento da fila de soquetes da aplicação: Esta é normalmente a maneira mais fácil de melhorar a taxa de drenagem de uma fila de soquetes, mas é pouco provável que seja uma solução a longo prazo. Se uma fila de soquetes receber uma quantidade limitada de tráfego em rajadas, o aumento da profundidade da fila de soquetes para corresponder ao tamanho das rajadas de tráfego pode impedir que os pacotes sejam descartados. Para aumentar a profundidade de uma fila, aumente o tamanho do buffer de recepção do soquete fazendo uma das seguintes mudanças:

    • Aumentar o valor do parâmetro /proc/sys/net/core/rmem_default: Este parâmetro controla o tamanho padrão do buffer de recepção utilizado pelos soquetes. Este valor deve ser menor ou igual ao valor do parâmetro proc/sys/net/core/rmem_max.
    • Use o setsockopt para configurar um valor maior SO_RCVBUF: Este parâmetro controla o tamanho máximo em bytes do buffer de recepção de um soquete. Use a chamada ao sistema getsockopt para determinar o valor atual do buffer.

Alterar a taxa de drenagem de uma fila é geralmente a maneira mais simples de mitigar o mau desempenho da rede. Entretanto, o aumento do número de pacotes que um dispositivo pode receber de uma vez utiliza o tempo adicional do processador, durante o qual nenhum outro processo pode ser programado, o que pode causar outros problemas de desempenho.

Recursos adicionais

  • Para mais informações, consulte as páginas de manual ss, socket e ethtool.
  • O arquivo /proc/net/snmp.

21.3. Configuração de pesquisas de opinião pública ocupadas

Se a análise revelar alta latência, seu sistema pode se beneficiar do recebimento de pacotes baseado em pesquisas e não em interrupções.

A pesquisa ocupada ajuda a reduzir a latência no caminho de recepção da rede, permitindo que o código da camada do soquete faça a pesquisa da fila de recepção de um dispositivo de rede, e desativa as interrupções da rede. Isto elimina os atrasos causados pela interrupção e a mudança de contexto resultante. Entretanto, também aumenta a utilização da CPU. A pesquisa ocupada também impede a CPU de dormir, o que pode acarretar consumo adicional de energia. O comportamento de pesquisas ocupadas é suportado por todos os drivers do dispositivo.

21.3.1. Possibilitando pesquisas de opinião pública ocupadas

Por padrão, a votação ocupada está desativada. Este procedimento descreve como habilitar as pesquisas de opinião pública ocupadas.

Procedimento

  1. Certifique-se de que a opção de compilação CONFIG_NET_RX_BUSY_POLL esteja habilitada:

    # cat /boot/config-$(uname -r) | grep CONFIG_NET_RX_BUSY_POLL
    CONFIG_NET_RX_BUSY_POLL=y
  2. Possibilitar pesquisas de opinião pública ocupadas

    1. Para permitir uma votação ocupada em tomadas específicas, defina o valor do kernel sysctl.net.core.busy_poll para um valor diferente de 0:

      # echo "net.core.busy_poll=50" > /etc/sysctl.d/95-enable-busy-polling-for-sockets.conf
      # sysctl -p /etc/sysctl.d/95-enable-busy-polling-for-sockets.conf

      Este parâmetro controla o número de microssegundos para esperar por pacotes na sondagem do soquete e selecionar syscalls. A Red Hat recomenda um valor de 50.

    2. Adicione a opção de soquete SO_BUSY_POLL ao soquete.
    3. Para permitir pesquisas de opinião em todo o mundo, defina o sysctl.net.core.busy_read para um valor diferente de 0:

      # echo "net.core.busy_read=50" > /etc/sysctl.d/95-enable-busy-polling-globally.conf
      # sysctl -p /etc/sysctl.d/95-enable-busy-polling-globally.conf

      O parâmetro net.core.busy_read controla o número de microssegundos para esperar por pacotes na fila do dispositivo para leituras de soquetes. Ele também define o valor padrão do SO_BUSY_POLL option. A Red Hat recomenda um valor de 50 para um pequeno número de soquetes, e um valor de 100 para um grande número de soquetes. Para números extremamente grandes de soquetes, por exemplo, mais de várias centenas, use ao invés disso a chamada ao sistema epoll.

Etapas de verificação

  • Verificar se a pesquisa está habilitada

    # ethtool -k device | grep "busy-poll"
    busy-poll: on [fixed]
    
    # cat /proc/sys/net/core/busy_read
    50

Recursos adicionais

21.4. Escala do lado da recepção

Receive-Side Scaling (RSS), também conhecido como recepção em várias filas, distribui o processamento de recepção da rede por várias filas de recepção baseadas em hardware, permitindo que o tráfego de entrada da rede seja processado por várias CPUs. RSS pode ser usado para aliviar gargalos no processamento de interrupção de recepção causados pela sobrecarga de uma única CPU e para reduzir a latência da rede. Por padrão, o RSS é ativado.

O número de filas ou CPUs que devem processar a atividade de rede para RSS são configuradas no driver do dispositivo de rede apropriado:

  • Para o motorista bnx2x, ele está configurado no parâmetro num_queues.
  • Para o motorista sfc, ele está configurado no parâmetro rss_cpus.

Independentemente disso, ela é tipicamente configurada no /sys/class/net/device/queues/rx-queue/ onde device é o nome do dispositivo de rede (como enp1s0) e rx-queue é o nome da fila de recepção apropriada.

O daemon irqbalance pode ser usado em conjunto com RSS para reduzir a probabilidade de transferência de memória entre nós e de salto de linha de cache. Isto reduz a latência do processamento de pacotes de rede.

21.4.1. Visualizando as filas de pedidos de interrupção

Ao configurar o RSS, a Red Hat recomenda limitar o número de filas a uma por núcleo físico da CPU. Hiperfilas são freqüentemente representadas como núcleos separados em ferramentas de análise, mas a configuração de filas para todos os núcleos, incluindo núcleos lógicos, tais como hiperfilas, não se mostrou benéfica para o desempenho da rede.

Quando ativado, o RSS distribui o processamento da rede igualmente entre as CPUs disponíveis com base na quantidade de processamento que cada CPU tem em fila de espera. Entretanto, use os parâmetros --show-rxfh-indir e --set-rxfh-indir do utilitário ethtool, para modificar como a RHEL distribui a atividade da rede, e pesar certos tipos de atividade de rede como mais importantes do que outros.

Este procedimento descreve como visualizar as filas de pedidos de interrupção.

Procedimento

  • Para determinar se sua placa de interface de rede suporta RSS, verifique se as filas de pedidos de interrupção múltipla estão associadas à interface em /proc/interrupts:

    # egrep 'CPU|p1p1' /proc/interrupts
     CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
    89:   40187       0       0       0       0       0   IR-PCI-MSI-edge   p1p1-0
    90:       0     790       0       0       0       0   IR-PCI-MSI-edge   p1p1-1
    91:       0       0     959       0       0       0   IR-PCI-MSI-edge   p1p1-2
    92:       0       0       0    3310       0       0   IR-PCI-MSI-edge   p1p1-3
    93:       0       0       0       0     622       0   IR-PCI-MSI-edge   p1p1-4
    94:       0       0       0       0       0    2475   IR-PCI-MSI-edge   p1p1-5

    A saída mostra que o driver NIC criou 6 filas de recepção para a interface p1p1 (p1p1-0 até p1p1-5). Também mostra quantas interrupções foram processadas por cada fila, e qual CPU atendeu a interrupção. Neste caso, há 6 filas porque, por padrão, este driver NIC específico cria uma fila por CPU, e este sistema tem 6 CPUs. Este é um padrão bastante comum entre os drivers de DNIs.

  • Para listar a fila de pedidos de interrupção para um dispositivo PCI com o endereço 0000:01:00.0:

    # ls -1 /sys/devices/*/*/0000:01:00.0/msi_irqs
    101
    102
    103
    104
    105
    106
    107
    108
    109

21.5. Receber a direção de pacotes

O RPS (Receive Packet Steering) é similar ao RSS, pois é usado para direcionar pacotes para CPUs específicas para processamento. Entretanto, o RPS é implementado no nível de software e ajuda a evitar que a fila de hardware de uma única placa de interface de rede se torne um gargalo no tráfego da rede. O RPS tem várias vantagens em relação ao RSS baseado em hardware:

  • O RPS pode ser usado com qualquer placa de interface de rede.
  • É fácil adicionar filtros de software ao RPS para lidar com novos protocolos.
  • O RPS não aumenta a taxa de interrupção do hardware do dispositivo de rede. No entanto, ele introduz interrupções inter-processador.

O RPS é configurado por dispositivo de rede e recebe fila, na /sys/class/net/device/queues/rx-queue/rps_cpus onde device é o nome do dispositivo de rede, como enp1s0 e rx-queue é o nome da fila de recepção apropriada, como rx-0.

O valor padrão do arquivo rps_cpus é 0. Isso desativa o RPS, e a CPU lida com a interrupção da rede e também processa o pacote. Para ativar o RPS, configure o arquivo rps_cpus apropriado com as CPUs que devem processar os pacotes a partir do dispositivo de rede especificado e receber a fila.

Os arquivos rps_cpus utilizam bitmaps de CPU delimitados por vírgulas. Portanto, para permitir que uma CPU possa lidar com interrupções para a fila de recepção em uma interface, defina o valor de suas posições no bitmap para 1. Por exemplo, para lidar com interrupções com CPUs 0, 1, 2, e 3, defina o valor do rps_cpus para f, que é o valor hexadecimal para 15. Em representação binária, 15 é 00001111 (1 2 4 8).

Para dispositivos de rede com filas de transmissão únicas, o melhor desempenho pode ser alcançado configurando o RPS para usar CPUs no mesmo domínio de memória. Em sistemas que não sejam do tipoNUMA, isto significa que todas as CPUs disponíveis podem ser utilizadas. Se a taxa de interrupção da rede for extremamente alta, excluindo a CPU que lida com as interrupções da rede também pode melhorar o desempenho.

Para dispositivos de rede com múltiplas filas, normalmente não há benefício em configurar tanto RPS quanto RSS, já que o RSS é configurado para mapear uma CPU para cada fila de recepção por padrão. Entretanto, o RPS ainda pode ser benéfico se houver menos filas de hardware do que CPUs, e o RPS é configurado para usar CPUs no mesmo domínio de memória.

21.6. Receber a direção do fluxo

A Direção de Fluxo de Recepção (RFS) estende o comportamento RPS para aumentar a taxa de acerto do cache da CPU e assim reduzir a latência da rede. Onde o RPS encaminha os pacotes com base unicamente no comprimento da fila, o RFS usa o RPS back end para calcular a CPU mais apropriada, depois encaminha os pacotes com base na localização da aplicação que consome o pacote. Isto aumenta a eficiência do cache da CPU.

Os dados recebidos de um único remetente não são enviados a mais de uma CPU. Se a quantidade de dados recebidos de um único remetente for maior do que uma única CPU pode lidar, configure um tamanho de estrutura maior para reduzir o número de interrupções e, portanto, a quantidade de trabalho de processamento para a CPU. Alternativamente, considere as opções de descarregar NIC ou CPUs mais rápidas.

Considere o uso de numactl ou taskset em conjunto com RFS para fixar aplicações em núcleos específicos, soquetes ou nós NUMA. Isto pode ajudar a evitar que os pacotes sejam processados fora de ordem.

21.6.1. Habilitando a Direção do Fluxo de Recepção

Por padrão, a Direção de Fluxo de Recepção (RFS) está desativada. Este procedimento descreve como ativar a RFS.

Procedimento

  1. Ajuste o valor do kernel net.core.rps_sock_flow_entries para o número máximo esperado de conexões ativas concomitantemente:

    # echo \i1"net.core.rps_sock_flow_entries=32768\i1 > /etc/sysctl.d/95-enable-rps.conf

    A Red Hat recomenda um valor de 32768 para cargas moderadas do servidor. Todos os valores inseridos são arredondados para a potência mais próxima de 2 na prática.

  2. Fixar persistentemente o valor do net.core.rps_sock_flow_entries:

    # sysctl -p /etc/sysctl.d/95-enable-rps.conf
  3. Para definir temporariamente o valor do sys/class/net/device/queues/rx-queue/rps_flow_cnt arquivo ao valor do (rps_sock_flow_entries/N), onde N é o número de filas de recebimento em um dispositivo:

    # echo 2048 > /sys/class/net/device/queues/rx-queue/rps_flow_cnt

    Substitua device pelo nome do dispositivo de rede que você deseja configurar (por exemplo, enp1s0), e rx-queue pela fila de recepção que você deseja configurar (por exemplo, rx-0). _ Substitua N pelo número de filas de recepção configuradas. Por exemplo, se o rps_flow_entries estiver configurado em 32768 e houver 16 configurado com filas de recepção, o rps_flow_cnt = 32786/16= 2048 (ou seja, o número de filas de recepção configuradas), rps_flow_cnt = rps_flow_enties/N ).

    Para dispositivos de fila única, o valor de rps_flow_cnt é o mesmo que o valor de rps_sock_flow_entries.

  4. Habilitar constantemente a RFS em todos os dispositivos de rede, criar o arquivo /etc/udev/rules.d/99-persistent-net.rules e adicionar o seguinte conteúdo:

    SUBSYSTEM=="net", ACTION=="add", RUN{program}+="/bin/bash -c 'for x in /sys/$DEVPATH/queues/rx-*; do echo 2048 > $x/rps_flow_cnt;  done'"
  5. Opcional: Para habilitar o RPS em um dispositivo de rede específico:

    SUBSYSTEM==="net", ACTION===="move", NAME=="device name{program} =="/bin/bash -c 'for x in /sys/$DEVPATH/queues/rx-*; do echo 2048 > $x/rps_flow_cnt; done'"

    Substituir device name pelo nome real do dispositivo de rede.

Etapas de verificação

  • Verificar se a RFS está habilitada:

    # cat /proc/sys/net/core/rps_sock_flow_entries
    32768
    
    # cat /sys/class/net/device/queues/rx-queue/rps_flow_cnt
    2048

Recursos adicionais

  • Para mais informações, consulte a página de manual sysctl.

21.7. RFS Acelerado

A RFS acelerada aumenta a velocidade da RFS ao acrescentar assistência de hardware. Como RFS, os pacotes são encaminhados com base na localização da aplicação que consome o pacote. Ao contrário das RFS tradicionais, no entanto, os pacotes são enviados diretamente para uma CPU que é local para o thread que consome os dados:

  • ou a CPU que está executando a aplicação
  • ou uma CPU local para essa CPU na hierarquia do cache

A RFS acelerada só está disponível se as seguintes condições forem atendidas:

  • O NIC deve apoiar o RFS acelerado. A RFS acelerada é suportada por cartões que exportam a função ndo_rx_flow_steer() net_device . Verifique a folha de dados da DNI para assegurar-se de que esta função é suportada.
  • ntuple a filtragem deve ser habilitada. Para informações sobre como habilitar esses filtros, consulte Seção 21.7.1, “Habilitação dos filtros de ntuplo”.

Uma vez satisfeitas estas condições, o mapeamento da CPU para fila é deduzido automaticamente com base na configuração RFS tradicional. Ou seja, o mapeamento CPU para fila é deduzido com base nas afinidades IRQ configuradas pelo motorista para cada fila de recepção. Para maiores informações sobre a habilitação das RFS tradicionais, veja Seção 21.6.1, “Habilitando a Direção do Fluxo de Recepção”.

21.7.1. Habilitação dos filtros de ntuplo

Use o comando ethtool -k para verificar se os filtros ntuple estão habilitados.

Procedimento

  1. Mostrar o status atual do filtro ntuple:

    # ethtool -k enp1s0 | grep ntuple-filters
    
    ntuple-filters: off
  2. Habilite os filtros ntuple:

    # ethtool -k enp1s0 ntuple on
Nota

Se a saída é ntuple-filters: off [fixed], então a filtragem ntuple está desativada e não é possível configurá-la:

# ethtool -k enp1s0 | grep ntuple-filters
ntuple-filters: off [fixed]

Etapas de verificação

  • Certifique-se de que os filtros ntuple estejam habilitados:

    # ethtool -k enp1s0 | grep ntuple-filters
    ntuple-filters: on

Recursos adicionais

  • Para mais informações, consulte a página de manual ethtool.

Capítulo 22. Configuração de um sistema operacional para otimizar o acesso à memória

Esta seção descreve como configurar o sistema operacional para otimizar o acesso à memória através de cargas de trabalho, e as ferramentas que você pode usar para fazê-lo.

22.1. Ferramentas para monitoramento e diagnóstico de problemas de memória do sistema

As seguintes ferramentas estão disponíveis no Red Hat Enterprise Linux 8 para monitorar o desempenho do sistema e diagnosticar problemas de desempenho relacionados à memória do sistema:

  • vmstat, fornecido pelo pacote procps-ng, exibe relatórios dos processos de um sistema, memória, paginação, bloqueio de E/S, armadilhas, discos e atividade da CPU. Fornece um relatório instantâneo da média desses eventos desde que a máquina foi ligada pela última vez, ou desde o relatório anterior.
  • valgrind é uma estrutura que fornece instrumentação para os binários de espaço do usuário. Instale esta ferramenta, usando o comando yum install valgrind. Ela inclui uma série de ferramentas, que você pode usar para traçar o perfil e analisar o desempenho do programa, como por exemplo:

    • a opçãomemcheck é a ferramenta padrão valgrind. Ela detecta e relata uma série de erros de memória que podem ser difíceis de detectar e diagnosticar, como por exemplo:

      • Acesso à memória que não deve ocorrer
      • Uso de valor indefinido ou não-inicializado
      • Memória de pilha incorretamente liberada
      • Sobreposição de ponteiros
      • Vazamentos de memória

        Nota

        A Memcheck só pode comunicar estes erros, não pode evitar que eles ocorram. Entretanto, memcheck registra uma mensagem de erro imediatamente antes que o erro ocorra.

    • a opçãocachegrind simula a interação da aplicação com a hierarquia de cache de um sistema e o preditor de filiais. Ela reúne estatísticas para a duração da execução da aplicação e fornece um resumo para o console.
    • a opçãomassif mede o espaço de pilha utilizado por uma aplicação específica. Ela mede tanto o espaço útil quanto qualquer espaço adicional alocado para fins de escrituração e alinhamento.

Recursos adicionais

  • Para mais informações, consulte a página de manual vmstat e valgrind.
  • Para mais informações sobre a estrutura valgrind, consulte o arquivo /usr/share/doc/valgrind-version/valgrind_manual.pdf.

22.2. Visão geral da memória de um sistema

O Kernel Linux é projetado para maximizar a utilização dos recursos de memória de um sistema (RAM). Devido a estas características de projeto, e dependendo dos requisitos de memória da carga de trabalho, parte da memória do sistema está em uso dentro do kernel em nome da carga de trabalho, enquanto que uma pequena parte da memória é livre. Esta memória livre é reservada para alocações especiais do sistema, e para outros serviços de sistema de baixa ou alta prioridade. O restante da memória do sistema é dedicado à própria carga de trabalho, e dividido nas duas categorias a seguir:

File memory

As páginas adicionadas nesta categoria representam partes de arquivos em armazenamento permanente. Estas páginas, a partir do cache de páginas, podem ser mapeadas ou não mapeadas nos espaços de endereço de uma aplicação. Você pode usar aplicativos para mapear arquivos em seus espaços de endereços usando as chamadas do sistema mmap, ou para operar em arquivos através das chamadas do sistema de leitura ou gravação em buffer de E/S.

Chamadas de sistema I/O em buffer, assim como aplicações que mapeiam páginas diretamente, podem reaproveitar páginas não mapeadas. Como resultado, estas páginas são armazenadas no cache pelo kernel, especialmente quando o sistema não está executando nenhuma tarefa intensiva de memória, para evitar a reemissão de dispendiosas operações de E/S sobre o mesmo conjunto de páginas.

Anonymous memory
As páginas nesta categoria estão em uso por um processo alocado dinamicamente, ou não estão relacionadas a arquivos em armazenamento permanente. Este conjunto de páginas faz backup das estruturas de controle na memória de cada tarefa, tais como a pilha de aplicações e as áreas de pilha.

Figura 22.1. Padrões de uso de memória

Memory usage patterns

22.3. Otimizando a utilização da memória de um sistema

Esta seção fornece informações sobre parâmetros do kernel relacionados à memória e como usá-los para melhorar a utilização da memória de um sistema. A seguir estão os parâmetros do kernel relacionados à memória disponíveis no Red Hat Enterprise Linux 8:

22.3.1. Parâmetros de memória virtual

Os parâmetros da memória virtual estão listados no diretório /proc/sys/vm, a menos que indicado o contrário.

Os parâmetros de memória virtual disponíveis são os seguintes:

vm.dirty_ratio
É um valor percentual. Quando esta porcentagem da memória total do sistema é modificada, o sistema começa a gravar as modificações no disco com a operação pdflush. O valor padrão é 20 por cento.
vm.dirty_background_ratio
Um valor percentual. Quando esta porcentagem da memória total do sistema é modificada, o sistema começa a gravar as modificações no disco em segundo plano. O valor padrão é 10 por cento.
vm.overcommit_memory

Define as condições que determinam se um pedido de memória grande é aceito ou negado. O valor padrão é 0.

Por padrão, o kernel executa um tratamento heurístico de excesso de memória através da estimativa da quantidade de memória disponível e de pedidos falhos que são muito grandes. Entretanto, como a memória é alocada usando um algoritmo heurístico em vez de um algoritmo preciso, a sobrecarga de memória é possível com esta configuração.

Definindo o valor do parâmetro overcommit_memory:

  • Quando este parâmetro é ajustado para 1, o kernel não executa nenhuma manipulação de excesso de memória. Isto aumenta a possibilidade de sobrecarga de memória, mas melhora o desempenho para tarefas que exigem muita memória.
  • Quando este parâmetro é ajustado para 2, o kernel nega pedidos de memória iguais ou maiores que a soma do espaço swap total disponível e a porcentagem de RAM física especificada no overcommit_ratio. Isto reduz o risco de excesso de memória, mas é recomendado apenas para sistemas com áreas de swap maiores do que sua memória física.
vm.overcommit_ratio
Especifica a porcentagem de RAM física considerada quando overcommit_memory é definido como 2. O valor padrão é 50.
vm.max_map_count
Define o número máximo de áreas do mapa de memória que um processo pode utilizar. O valor padrão é 65530. Aumente este valor se sua aplicação precisar de mais áreas do mapa de memória.
vm.min_free_kbytes

Define o tamanho do pool de páginas livres reservadas. É também responsável pela definição dos limites min_page, low_page e high_page que regem o comportamento dos algoritmos de recuperação de páginas do kernel do Linux. Também especifica o número mínimo de kilobytes a serem mantidos livres em todo o sistema. Isto calcula um valor específico para cada zona de pouca memória, a cada uma das quais é atribuído um número de páginas livres reservadas em proporção ao seu tamanho.

Definindo o valor do parâmetro vm.min_free_kbytes:

  • Aumentar o valor do parâmetro reduz efetivamente a memória utilizável do conjunto de trabalho da aplicação. Portanto, você pode querer usá-la apenas para cargas de trabalho orientadas pelo kernel, onde os buffers de driver precisam ser alocados em contextos atômicos.
  • A diminuição do valor do parâmetro pode tornar o kernel incapaz de atender as solicitações do sistema, se a memória ficar muito contendida no sistema.

    Atenção

    Os valores extremos podem ser prejudiciais ao desempenho do sistema. Ajustar o vm.min_free_kbytes para um valor extremamente baixo impede que o sistema recupere a memória efetivamente, o que pode resultar em falhas no sistema e interrupções no serviço ou outros serviços do kernel. No entanto, o ajuste do vm.min_free_kbytes para um valor muito alto aumenta consideravelmente a atividade de recuperação do sistema, causando latência de alocação devido a um falso estado de recuperação direta. Isto pode fazer com que o sistema entre imediatamente em um estado fora de memória.

    O parâmetro vm.min_free_kbytes também define uma página de recuperação de marca d'água, chamada min_pages. Esta marca d'água é usada como um fator ao determinar as duas outras marcas d'água de memória, low_pages, e high_pages, que governam os algoritmos de recuperação de páginas.

/proc/PID/oom_adj

No caso de um sistema ficar sem memória e o parâmetro panic_on_oom for definido como 0, a função oom_killer mata processos, começando com o processo que tem o mais alto oom_score, até que o sistema se recupere.

O parâmetro oom_adj determina o oom_score de um processo. Este parâmetro é definido por identificador de processo. Um valor de -17 desabilita o oom_killer para esse processo. Outros valores válidos variam de -16 a 15.

Nota

Os processos criados por um processo ajustado herdam o oom_score desse processo.

vm.swappiness

O valor de swappiness, que varia de 0 a 100, controla o grau em que o sistema favorece a recuperação de memória do pool de memória anônimo, ou do pool de memória cache de páginas.

Definindo o valor do parâmetro swappiness:

  • Os valores mais altos favorecem as cargas de trabalho de arquivos mapeados e, ao mesmo tempo, a troca da memória mapeada anônima de RAM dos processos de acesso menos ativo. Isto é útil para servidores de arquivos ou aplicações de streaming que dependem de dados, de arquivos no armazenamento, para residir na memória a fim de reduzir a latência de E/S para as solicitações de serviço.
  • Valores baixos favorecem cargas de trabalho anônimas enquanto se recupera o cache da página (memória mapeada por arquivo). Esta configuração é útil para aplicações que não dependem muito das informações do sistema de arquivos e utilizam muito a memória privada e dinamicamente alocada, tais como aplicações matemáticas e de números, e poucos supervisores de virtualização de hardware como o QEMU.

    O valor padrão do parâmetro vm.swappiness é 30.

    Atenção

    A configuração do vm.swappiness para 0 evita agressivamente a troca de memória anônima para um disco, o que aumenta o risco de processos serem mortos pela função oom_killer quando sob carga de trabalho intensiva de memória ou E/S.

Recursos adicionais

22.3.2. Parâmetros do sistema de arquivo

Os parâmetros do sistema de arquivos estão listados no diretório /proc/sys/fs. A seguir estão os parâmetros de sistema de arquivo disponíveis:

aio-max-nr
Define o número máximo permitido de eventos em todos os contextos de entrada/saída assíncronos ativos. O valor padrão é 65536, e modificar este valor não pré-aloca nem redimensiona nenhuma estrutura de dados do kernel.
file-max

Determina o número máximo de alças de arquivo para todo o sistema. O valor padrão no Red Hat Enterprise Linux 8 é 8192 ou um décimo das páginas de memória livre disponíveis no momento em que o kernel inicia, o que for maior.

A elevação deste valor pode resolver erros causados pela falta de arquivos disponíveis.

Recursos adicionais

  • Para mais informações, consulte a página de manual sysctl.

22.3.3. Parâmetros do núcleo

Os valores padrão para os parâmetros do kernel estão localizados no diretório /proc/sys/kernel/. Estes valores são calculados pelo kernel no momento da inicialização, dependendo dos recursos disponíveis no sistema.

A seguir estão os parâmetros de kernel disponíveis usados para estabelecer limites para as chamadas ao sistema msg* e shm* Sistema V IPC (sysvipc):

msgmax
Define o tamanho máximo permitido em bytes de qualquer mensagem em uma única fila de mensagens. Este valor não deve exceder o tamanho da fila (msgmnb). Use o comando sysctl msgmax para determinar o valor atual msgmax em seu sistema.
msgmnb
Define o tamanho máximo em bytes de uma única fila de mensagens. Use o comando sysctl msgmnb para determinar o valor atual msgmnb em seu sistema.
msgmni
Define o número máximo de identificadores de filas de mensagens e, portanto, o número máximo de filas. Use o comando sysctl msgmni para determinar o valor atual msgmni em seu sistema.
shmall
Define a quantidade total de páginas de memória compartilhada que podem ser usadas no sistema de uma só vez. Por exemplo, uma página é 4096 bytes na arquitetura AMD64 e Intel 64. Use o comando sysctl shmall para determinar o valor atual shmall em seu sistema.
shmmax
Define o tamanho máximo em bytes de um único segmento de memória compartilhada permitido pelo kernel. Use o comando sysctl shmmax para determinar o valor atual shmmax em seu sistema.
shmmni
Define o número máximo de segmentos de memória compartilhada em todo o sistema. O valor padrão é 4096 em todos os sistemas.

Recursos adicionais

  • Para mais informações, consulte a página de manual sysvipc e sysctl.

Capítulo 23. Configuração de páginas enormes

A memória física é gerenciada em pedaços de tamanho fixo chamados páginas. Na arquitetura x86_64, suportada pelo Red Hat Enterprise Linux 8, o tamanho padrão de uma página de memória é 4 KB. Este tamanho de página default provou ser adequado para sistemas operacionais de propósito geral, como o Red Hat Enterprise Linux, que suporta muitos tipos diferentes de cargas de trabalho.

Entretanto, aplicações específicas podem se beneficiar do uso de páginas maiores em certos casos. Por exemplo, uma aplicação que funciona com um conjunto de dados grande e relativamente fixo de centenas de megabytes ou mesmo dezenas de gigabytes pode ter problemas de desempenho ao utilizar 4 páginas KB. Tais conjuntos de dados podem exigir uma enorme quantidade de 4 páginas KB, o que pode levar a sobrecarga no sistema operacional e na CPU.

Esta seção fornece informações sobre enormes páginas disponíveis no Red Hat Enterprise Linux 8 e como você pode configurá-las.

23.1. Características de páginas enormes disponíveis

Com o Red Hat Enterprise Linux 8, você pode usar páginas enormes para aplicações que funcionam com grandes conjuntos de dados, e melhorar o desempenho de tais aplicações.

A seguir estão os enormes métodos de página, que são suportados no Red Hat Enterprise Linux 8:

HugeTLB pages

As páginas HugeTLB também são chamadas de páginas enormes estáticas. Há duas maneiras de reservar as páginas HugeTLB:

Transparent HugePages (THP)

Com THP, o núcleo atribui automaticamente páginas enormes a processos, e portanto não há necessidade de reservar manualmente as páginas enormes estáticas. Os dois modos de operação no THP são os seguintes:

23.2. Parâmetros para reservar páginas HugeTLB no momento da inicialização

Use os seguintes parâmetros para influenciar o comportamento da página HugeTLB no momento da inicialização:

Tabela 23.1. Parâmetros usados para configurar páginas HugeTLB no momento da inicialização
ParâmetroDescriçãoValor padrão

hugepages

Define o número de páginas enormes e persistentes configuradas no kernel no momento da inicialização.

Em um sistema NUMA, páginas enormes, que têm este parâmetro definido, são divididas igualmente entre os nós.

Você pode atribuir páginas enormes a nós específicos em tempo de execução, alterando o valor dos nós no arquivo /sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages.

O valor padrão é 0.

Para atualizar este valor na inicialização, altere o valor deste parâmetro no arquivo /proc/sys/vm/nr_hugepages.

hugepagesz

Define o tamanho de páginas enormes e persistentes configuradas no kernel no momento da inicialização.

Os valores válidos são 2 MB e 1 GB. O valor padrão é 2 MB.

default_hugepagesz

Define o tamanho padrão de páginas enormes e persistentes configuradas no kernel no momento da inicialização.

Os valores válidos são 2 MB e 1 GB. O valor padrão é 2 MB.

23.3. Parâmetros para reservar páginas HugeTLB em tempo de execução

Use os seguintes parâmetros para influenciar o comportamento da página HugeTLB em tempo de execução:

Tabela 23.2. Parâmetros usados para configurar páginas HugeTLB em tempo de execução
ParâmetroDescriçãoNome do arquivo

nr_hugepages

Define o número de páginas enormes de um tamanho especificado atribuído a um nó NUMA especificado.

/sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages

nr_overcommit_hugepages

Define o número máximo de páginas enormes adicionais que podem ser criadas e utilizadas pelo sistema através de uma memória de compromisso excessivo.

Escrever qualquer valor diferente de zero neste arquivo indica que o sistema obtém esse número de páginas enormes do pool de páginas normal do kernel se o pool de páginas enorme e persistente estiver esgotado. Como estas páginas enormes excedentes ficam sem uso, elas são então liberadas e retornam ao pool normal de páginas do kernel.

/proc/sys/vm/nr_overcommit_hugepages

23.4. Configuração do HugeTLB no momento da inicialização

O tamanho da página, que o subsistema HugeTLB suporta, depende da arquitetura. A arquitetura x86_64 suporta 2 MB de páginas enormes e 1 GB de páginas gigantescas.

Este procedimento descreve como reservar uma página de 1 GB no momento da inicialização.

Procedimento

  1. Criar um pool HugeTLB para 1 GB de páginas, anexando a seguinte linha às opções de linha de comando do kernel no arquivo /etc/default/grub como root:

    padrão_hugepagesz=1G hugepagesz=1G
  2. Regenerar a configuração GRUB2 usando o arquivo padrão editado:

    1. Se seu sistema utiliza firmware BIOS, execute o seguinte comando:

      # grub2-mkconfig -o /boot/grub2/grub.cfg
    2. Se seu sistema utiliza a estrutura UEFI, execute o seguinte comando:

      # grub2-mkconfig -o /boot/efi/efi/EFI/redhat/grub.cfg
  3. Crie um novo arquivo chamado hugetlb-gigantic-pages.service no diretório /usr/lib/systemd/system/ e adicione o seguinte conteúdo:

    [Unit]
    Description=HugeTLB Gigantic Pages Reservation
    DefaultDependencies=no
    Before=dev-hugepages.mount
    ConditionPathExists=/sys/devices/system/node
    ConditionKernelCommandLine=hugepagesz=1G
    
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/usr/lib/systemd/hugetlb-reserve-pages.sh
    
    [Install]
    WantedBy=sysinit.target
  4. Crie um novo arquivo chamado hugetlb-reserve-pages.sh no diretório /usr/lib/systemd/ e adicione o seguinte conteúdo:

    Ao adicionar o seguinte conteúdo, substitua number_of_pages pelo número de páginas de 1GB que você deseja reservar, e node pelo nome do nó no qual reservar estas páginas.

    #!/bin/sh
    
    nodes_path=/sys/devices/system/node/
    if [ ! -d $nodes_path ]; then
        echo "ERROR: $nodes_path does not exist"
        exit 1
    fi
    
    reserve_pages()
    {
        echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
    }
    
    reserve_pages number_of_pages node

    Por exemplo, para reservar duas páginas de 1GB em node0 e uma página de 1GB em node1, substituir o number_of_pages por 2 para node0 e 1 para node1:

    reserve_pages 2 node0
    reserve_pages 1 node1
  5. Criar um roteiro executável:

    # chmod x /usr/lib/systemd/hugetlb-reserve-pages.sh
  6. Habilitar a reserva antecipada da bota:

    # systemctl permite páginas hugetlb-gigantic-pages
Nota
  • Você pode tentar reservar mais páginas de 1GB em tempo de execução, escrevendo para nr_hugepages a qualquer momento. Entretanto, tais reservas podem falhar devido à fragmentação da memória. A maneira mais confiável de reservar páginas de 1GB é usando este script hugetlb-reserve-pages.sh, que roda cedo durante a inicialização.
  • Reservar páginas enormes estáticas pode efetivamente reduzir a quantidade de memória disponível para o sistema e impedi-lo de utilizar adequadamente toda a sua capacidade de memória. Embora um pool de páginas enormes reservadas possa ser benéfico para aplicações que o utilizam, um pool de páginas enormes reservadas ou não utilizadas eventualmente será prejudicial ao desempenho geral do sistema. Ao definir um grande pool de páginas reservadas, certifique-se de que o sistema possa utilizar adequadamente toda a sua capacidade de memória.

Recursos adicionais

  • Para mais informações, consulte a documentação pertinente do kernel, que está instalada no arquivo /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt.
  • Para mais informações, consulte a página de manual systemd.service.

23.5. Configuração do HugeTLB em tempo de execução

Este procedimento descreve como adicionar vinte 2048 kB páginas enormes a node2.

Procedimento

  1. Exibir as estatísticas da memória:

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total add
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0      0      0      0
    HugePages_Free        0      0      0      0      0
    HugePages_Surp        0      0      0      0      0
  2. Adicione o número de páginas enormes de um tamanho especificado ao nó:

    # echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages

    Para reservar páginas com base em suas exigências, substitua:

    • 20 com o número de páginas enormes que você deseja reservar,
    • 2048kB com o tamanho das enormes páginas,
    • node2 com o nó no qual você deseja reservar as páginas.

Etapas de verificação

  • Certifique-se de que o número de páginas enormes seja adicionado:

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0     40      0     40
    HugePages_Free        0      0     40      0     40
    HugePages_Surp        0      0      0      0      0

Recursos adicionais

  • Para mais informações, consulte a página de manual numastat.

23.6. Possibilitando abraços transparentes

O THP é habilitado por default no Red Hat Enterprise Linux 8. No entanto, você pode habilitar ou desabilitar o THP. Este procedimento descreve como habilitar o THP.

Procedimento

  1. Verifique o status atual do THP:

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. Habilite o THP:

    # echo sempre > /sys/kernel/mm/transparent_hugepage/enabled
  3. Para evitar que as aplicações destinem mais recursos de memória do que o necessário, desabilite as enormes páginas transparentes em todo o sistema e habilite-as apenas para as aplicações que o solicitem explicitamente através do site madvise:

    # echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
Nota

S vezes, fornecer baixa latência para alocações de curta duração tem maior prioridade do que obter imediatamente o melhor desempenho com alocações de longa duração. Nesses casos, você pode desativar a compactação direta, deixando o THP ativado.

A compactação direta é uma compactação síncrona de memória durante a enorme alocação de páginas. A desativação da compactação direta não oferece garantia de economia de memória, mas pode diminuir o risco de latências mais altas durante falhas freqüentes de página. Observe que se a carga de trabalho se beneficia significativamente do THP, o desempenho diminui. Desativar a compactação direta:

# echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

Recursos adicionais

  • Para mais informações, consulte a página de manual madvise.

23.7. Desabilitando as páginas de abraços transparentes

O THP é habilitado por default no Red Hat Enterprise Linux 8. No entanto, você pode habilitar ou desabilitar o THP. Este procedimento descreve como desabilitar o THP.

Procedimento

  1. Verifique o status atual do THP:

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. Desativar o THP:

    # echo nunca > /sys/kernel/mm/transparent_hugepage/enabled

23.8. Impacto do tamanho da página no tamanho do buffer da tradução

A leitura de mapeamentos de endereços da tabela de páginas é demorada e barata, por isso as CPUs são construídas com um cache para endereços recém-utilizados, chamado de "Translation Lookaside Buffer" (TLB). Entretanto, a TLB padrão só pode armazenar em cache um certo número de mapeamentos de endereços.

Se um mapeamento de endereço solicitado não estiver na TLB, chamado de TLB miss, o sistema ainda precisa ler a tabela de páginas para determinar o mapeamento de endereço físico para virtual. Devido à relação entre os requisitos de memória da aplicação e o tamanho das páginas usadas para o mapeamento de endereços em cache, as aplicações com requisitos de memória grandes têm mais probabilidade de sofrer degradação de desempenho por falhas na TLB do que as aplicações com requisitos mínimos de memória. Portanto, é importante evitar falhas de TLB sempre que possível.

Tanto as características HugeTLB como as Transparent Huge Page permitem que as aplicações utilizem páginas maiores do que 4 KB. Isto permite que endereços armazenados na TLB referenciem mais memória, o que reduz as falhas na TLB e melhora o desempenho da aplicação.

Capítulo 24. Começando com SystemTap

Como administrador de sistema, você pode usar o SystemTap para identificar as causas subjacentes de um bug ou problema de desempenho em um sistema Linux em execução.

Como desenvolvedor de aplicações, você pode usar o SystemTap para monitorar em detalhes como sua aplicação se comporta dentro do sistema Linux.

24.1. O propósito do SystemTap

SystemTap é uma ferramenta de rastreamento e sondagem que você pode usar para estudar e monitorar as atividades de seu sistema operacional (particularmente, o núcleo) com detalhes finos. O SystemTap fornece informações semelhantes à saída de ferramentas como netstat, ps, top, e iostat. Entretanto, o SystemTap fornece mais opções de filtragem e análise para as informações coletadas. Nos scripts do SystemTap, você especifica as informações que o SystemTap reúne.

O SystemTap visa complementar o conjunto existente de ferramentas de monitoramento Linux, fornecendo aos usuários a infra-estrutura para rastrear a atividade do kernel e combinando esta capacidade com dois atributos:

Flexibility
a estrutura SystemTap permite desenvolver scripts simples para investigar e monitorar uma grande variedade de funções do kernel, chamadas de sistema e outros eventos que ocorrem no espaço do kernel. Com isso, o SystemTap não é tanto uma ferramenta, mas um sistema que permite desenvolver suas próprias ferramentas forenses e de monitoramento específicas do kernel.
Ease-of-Use
SystemTap permite monitorar a atividade do kernel sem ter que recompilar o kernel ou reiniciar o sistema.

24.2. Implementando o SystemTap

Para usar o SystemTap, você deve instalar os pacotes associados do SystemTap e do kernel.

24.2.1. Habilitação de depuração e repositórios de fonte

Uma instalação padrão do Red Hat Enterprise Linux não habilita os repositórios de depuração e fonte. Estes repositórios contêm informações necessárias para depurar os componentes do sistema e medir seu desempenho.

Procedimento

  • Habilitar os canais do pacote de informações de origem e de depuração:

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    A parte $(uname -i) é automaticamente substituída por um valor correspondente para a arquitetura de seu sistema:

    Nome da arquiteturaValor

    Intel e AMD de 64 bits

    x86_64

    ARM de 64 bits

    aarch64

    IBM POWER

    ppc64le

    IBM Z

    s390x

24.2.2. Instalando o SystemTap

Para começar a usar o SystemTap, instale os pacotes necessários. Para usar o SystemTap em mais de um kernel onde um sistema tem múltiplos kernels instalados, instale os pacotes de kernel necessários correspondentes para a versão each do kernel.

Pré-requisitos

Procedimento

  1. Instale os pacotes SystemTap necessários:

    # yum instalar systemtap
  2. Instalar os pacotes de kernel necessários:

    1. Usando stap-prep:

      # stap-prep-prep
    2. Se stap-prep não funcionar, instale os pacotes de kernel necessários manualmente:

      # yum install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -i)-$(uname -r) kernel-devel-$(uname -r)

      $(uname -i) é automaticamente substituído com a plataforma de hardware de seu sistema e $(uname -r) é automaticamente substituído com a versão de seu kernel em execução.

Etapas de verificação

  • Se o kernel a ser sondado com SystemTap estiver em uso atualmente, teste se sua instalação foi bem sucedida:

    # stap -v -e 'probe kernel.function(vfs_read') {printf({"read performed"); exit()}

    Uma implementação bem sucedida do SystemTap resulta em um resultado semelhante ao seguinte:

    Pass 1: parsed user script and 45 library script(s) in 340usr/0sys/358real ms.
    Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 290usr/260sys/568real ms.
    Pass 3: translated to C into "/tmp/stapiArgLX/stap_e5886fa50499994e6a87aacdc43cd392_399.c" in 490usr/430sys/938real ms.
    Pass 4: compiled C into "stap_e5886fa50499994e6a87aacdc43cd392_399.ko" in 3310usr/430sys/3714real ms.
    Pass 5: starting run. 1
    read performed 2
    Pass 5: run completed in 10usr/40sys/73real ms. 3

    As últimas três linhas de saída (começando com Pass 5) indicam que:

    1
    O SystemTap criou com sucesso a instrumentação para sondar o núcleo e executou a instrumentação.
    2
    SystemTap detectou o evento especificado (neste caso, uma leitura VFS).
    3
    SystemTap executou um manipulador válido (texto impresso e depois o fechou sem erros).

24.3. Cross-instrumentação do SystemTap

24.3.1. SystemTap de instrumentação cruzada

Quando você executa um script SystemTap, um módulo do kernel é construído a partir desse script. O SystemTap então carrega o módulo para o kernel.

Normalmente, os scripts do SystemTap só podem ser executados em sistemas onde o SystemTap é implantado. Para executar o SystemTap em dez sistemas, o SystemTap precisa ser implantado em todos esses sistemas. Em alguns casos, isto pode não ser viável nem desejado. Por exemplo, a política corporativa pode proibir a instalação de pacotes que forneçam compiladores ou informações de depuração em máquinas específicas, o que impedirá a implantação do SystemTap.

Para contornar este problema, use cross-instrumentation. A instrumentação cruzada é o processo de geração de módulos de instrumentação SystemTap a partir de um script SystemTap em um sistema para ser usado em outro sistema. Este processo oferece os seguintes benefícios:

  • Os pacotes de informação do núcleo para várias máquinas podem ser instalados em uma única máquina host.
Cuidado

Os bugs de embalagem do grão podem impedir isso. Nesses casos, os pacotes kernel-debuginfo e kernel-devel para os pacotes host system e target system devem corresponder. Caso isso ocorra, informe o erro em https://bugzilla.redhat.com/.

  • Cada target machine necessita apenas de um pacote a ser instalado para utilizar o módulo de instrumentação SystemTap gerado: systemtap-runtime.
Importante

O host system deve ser a mesma arquitetura e rodar a mesma distribuição de Linux que o target system, para que o instrumentation module construído funcione.

Terminologia
instrumentation module
O módulo do kernel construído a partir de um script SystemTap; o módulo SystemTap é construído no host system, e será carregado no target kernel do site target system.
host system
O sistema no qual os módulos de instrumentação (dos scripts SystemTap) são compilados, para serem carregados em target systems.
target system
O sistema no qual o instrumentation module está sendo construído (a partir dos scripts do SystemTap).
target kernel
O núcleo do target system. Este é o kernel que carrega e executa o instrumentation module.

24.3.2. Inicializando a instrumentação cruzada do SystemTap

Inicializar a instrumentação cruzada do SystemTap para construir módulos de instrumentação SystemTap a partir de um script SystemTap em um sistema e usá-los em outro sistema que não tenha o SystemTap totalmente implantado.

Pré-requisitos

  • O SystemTap está instalado no site host system como descrito em Instalando o SystemTap.
  • Tanto o host system quanto o target system são a mesma arquitetura.
  • Tanto o host system quanto o target system estão rodando a mesma versão principal do Red Hat Enterprise Linux (como o Red Hat Enterprise Linux 8), eles can estão rodando diferentes versões menores (como 8.1 e 8.2).
Cuidado

Os bugs de embalagem do kernel podem impedir que vários pacotes kernel-debuginfo e kernel-devel sejam instalados em um sistema. Nesses casos, a versão menor para os pacotes host system e target system deve coincidir. Caso isso ocorra, informe o bug em https://bugzilla.redhat.com/.

Procedimento

  1. Determinar o kernel rodando em cada target system:

    $ uname -r

    Repita esta etapa para cada um target system.

  2. Instale o pacote necessário para executar módulos pré-compilados em cada um target system:

    # yum instalar systemtap-runtime
  3. No site host system, instale o target kernel e pacotes relacionados para cada target system pelo método descrito na instalação do SystemTap.
  4. Construa um módulo de instrumentação no host system, copie para e execute no target system também:

    1. Usando implementação remota:

      # stap --remote target_system script

      Este comando implementa remotamente o script especificado no site target system. Você deve garantir que uma conexão SSH possa ser feita ao target system a partir do host system para que isto seja bem sucedido.

    2. Manualmente:

      1. Construa o módulo de instrumentação no site host system:

        # stap -r kernel_version script -m module_name -p 4

        Aqui, kernel_version refere-se à versão do target kernel determinada no passo 1, script refere-se ao roteiro a ser convertido em instrumentation module, e module_name é o nome desejado do instrumentation module. A opção -p4 diz ao SystemTap para não carregar e executar o módulo compilado.

      2. Uma vez compilado o instrumentation module, copie-o para o sistema de destino e carregue-o usando o seguinte comando:

        # staprun module_name.ko
        Nota

        A execução de um módulo pré-compilado requer apenas o pacote systemtap-runtime.

24.4. Sistema em execuçãoRoteiros de mapas

24.4.1. Privilégios para executar o SystemTap

A execução de scripts SystemTap requer privilégios elevados do sistema mas, em alguns casos, os usuários não privilegiados podem precisar executar a instrumentação SystemTap em sua máquina.

Para permitir que os usuários executem o SystemTap sem acesso root, adicione usuários a both destes grupos de usuários:

stapdev

Os membros deste grupo podem usar stap para executar scripts SystemTap, ou staprun para executar módulos de instrumentação SystemTap.

A execução do stap envolve a compilação de scripts SystemTap em módulos do kernel e o seu carregamento no kernel. Isto requer privilégios elevados ao sistema, que são concedidos aos membros do stapdev. Infelizmente, tais privilégios também concedem acesso efetivo à raiz aos membros do stapdev. Como tal, somente concedem a stapdev membros do grupo aos usuários que podem ser confiados com acesso à raiz.

stapusr
Os membros deste grupo só podem usar staprun para executar os módulos de instrumentação do SystemTap. Além disso, eles só podem rodar esses módulos a partir do /lib/modules/kernel_version/systemtap/ diretório. Este diretório deve ser de propriedade apenas do usuário root, e deve poder ser escrito apenas pelo usuário root.

24.4.2. Sistema em execuçãoRoteiros de mapas

Você pode executar scripts SystemTap a partir de entradas padrão ou a partir de um arquivo.

Os exemplos de scripts que são distribuídos com a instalação do SystemTap podem ser encontrados no diretório /usr/share/systemtap/examples.

Pré-requisitos

  1. O SystemTap e os pacotes de kernel necessários associados são instalados como descrito na instalação do SystemTap.
  2. Para executar os scripts SystemTap como um usuário normal, adicione o usuário aos grupos SystemTap:

    # usermod --append --groups
    stapdev,stapusr user-name

Procedimento

  • Execute o script SystemTap:

    • A partir da entrada padrão:

      # echo "probe timer.s(1) {exit()}" | stap -

      Este comando instrui stap a executar o script passado por echo para a entrada padrão. Para adicionar as opções stap, insira-as antes do caracter -. Por exemplo, para tornar os resultados deste comando mais verbosos, o comando é:

      # echo "probe timer.s(1) {exit()}" | stap -v -
    • A partir de um arquivo:

      # stap file_name

Capítulo 25. Analisando o desempenho do sistema com a Coleção de Compiladores BPF

Como administrador de sistemas, use a biblioteca BPF Compiler Collection (BCC) para criar ferramentas para analisar o desempenho de seu sistema operacional Linux e coletar informações, que podem ser difíceis de obter através de outras interfaces.

25.1. Uma introdução ao BCC

BPF Compiler Collection (BCC) é uma biblioteca, que facilita a criação dos programas ampliados de Filtro de Pacotes Berkeley (eBPF). A principal utilidade dos programas eBPF é analisar o desempenho do sistema operacional e o desempenho da rede sem ter problemas de overhead ou de segurança.

BCC elimina a necessidade de os usuários conhecerem detalhes técnicos profundos do eBPF, e fornece muitos pontos de partida prontos para uso, tais como o pacote bcc-tools com programas eBPF pré-criados.

Nota

Os programas eBPF são acionados em eventos, tais como E/S de disco, conexões TCP e criações de processo. É improvável que os programas causem o colapso, loop ou tornem-se insensíveis por funcionarem em uma máquina virtual segura no kernel.

25.2. Instalando o pacote bcc-tools

Esta seção descreve como instalar o pacote bcc-tools, que também instala a biblioteca BPF Compiler Collection (BCC) como uma dependência.

Pré-requisitos

Procedimento

  1. Instale bcc-tools:

    # yum install bcc-tools

    As ferramentas BCC estão instaladas no diretório /usr/share/bcc/tools/.

  2. Opcionalmente, inspecionar as ferramentas:

    # ll /usr/share/bcc/tools/
    ...
    -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
    -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
    -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
    -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
    drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
    -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
    -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
    -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
    ...

    O diretório doc na lista acima contém documentação para cada ferramenta.

25.3. Utilização de ferramentas bcc selecionadas para análises de desempenho

Esta seção descreve como usar certos programas pré-criados da biblioteca da BPF Compiler Collection (BCC) para analisar de forma eficiente e segura o desempenho do sistema em cada evento. O conjunto de programas pré-criados na biblioteca do BCC pode servir como exemplos para a criação de programas adicionais.

Pré-requisitos

Usando o execsnoop para examinar os processos do sistema
  1. Executar o programa execsnoop em um terminal:

    # /usr/share/bcc/tools/execsnoop
  2. Em outro terminal executar, por exemplo:

    $ ls /usr/share/bcc/tools/doc/

    O acima exposto cria um processo de curta duração do comando ls.

  3. O terminal rodando execsnoop mostra a saída semelhante ao seguinte:

    PCOMM	PID    PPID   RET ARGS
    ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
    sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
    ...

    O programa execsnoop imprime uma linha de saída para cada novo processo, o que consome recursos do sistema. Ele até detecta processos de programas que rodam muito em breve, tais como ls, e a maioria das ferramentas de monitoramento não os registrariam.

    A saída execsnoop exibe os seguintes campos:

    • PCOMM - O nome do processo pai. (ls)
    • PID - A identificação do processo. (8382)
    • PPID - O ID do processo pai. (8287)
    • RET - O valor de retorno da chamada ao sistema exec() (0), que carrega o código do programa em novos processos.
    • ARGS - A localização do programa iniciado com argumentos.

Para ver mais detalhes, exemplos e opções para execsnoop, consulte o arquivo /usr/share/bcc/tools/doc/execsnoop_example.txt.

Para mais informações sobre exec(), consulte as páginas do manual exec(3).

Usando o opensnoop para rastrear quais arquivos um comando abre
  1. Executar o programa opensnoop em um terminal:

    # /usr/share/bcc/tools/opensnoop -n uname

    A saída de impressões acima para arquivos, que são abertos somente pelo processo do comando uname.

  2. Em outro terminal executar:

    $ uname

    O comando acima abre certos arquivos, que são capturados na próxima etapa.

  3. O terminal rodando opensnoop mostra a saída semelhante ao seguinte:

    PID    COMM 	FD ERR PATH
    8596   uname 	3  0   /etc/ld.so.cache
    8596   uname 	3  0   /lib64/libc.so.6
    8596   uname 	3  0   /usr/lib/locale/locale-archive
    ...

    O programa opensnoop observa a chamada do sistema open() em todo o sistema, e imprime uma linha de saída para cada arquivo que uname tentou abrir pelo caminho.

    A saída opensnoop exibe os seguintes campos:

    • PID - A identificação do processo. (8596)
    • COMM - O nome do processo. (uname)
    • FD - O descritor de arquivo - um valor que open() retorna para se referir ao arquivo aberto. (3)
    • ERR - Qualquer erro.
    • PATH - A localização dos arquivos que open() tentou abrir.

      Se um comando tentar ler um arquivo inexistente, então a coluna FD retorna -1 e a coluna ERR imprime um valor correspondente ao erro relevante. Como resultado,