Comparação de desempenho entre SLES 15 e RHEL 9 em servidores corporativos

Não existe um vencedor universal em termos de desempenho entre o SUSE Linux Enterprise Server 15 e o Red Hat Enterprise Linux 9. Uma resposta definitiva depende do pacote de serviços ou versão secundária específica, do hardware, das atualizações do kernel, do perfil de otimização, da pilha de aplicativos e da carga de trabalho. O guia de otimização atual do SUSE SLES 15 SP7 e a documentação do Red Hat RHEL 9 descrevem as capacidades de otimização; eles não estabelecem um resultado de comparação direta de velocidade, controlado e de uso geral.

Essa distinção é importante porque a documentação do SLES 15 SP7 identifica uma base de kernel Linux 6.4, enquanto a Red Hat documenta o RHEL 9 como baseado no kernel 5.14 e observa que incorpora alterações mais recentes em seu fluxo de kernel. Esses rótulos de versão, por si só, não preveem qual distribuição executará um banco de dados, serviço web ou máquina virtual mais rapidamente. Considere-os como informações sobre o produto e, em seguida, realize testes de desempenho com a carga de trabalho que você realmente planeja executar.

O que pode ser verificado sobre o SLES 15 e o RHEL 9?

Antes de comparar as máquinas, registre as versões exatas instaladas e o perfil ativo em cada uma. Por exemplo, colete as informações de versão cat /etc/os-release, uname -rperfil e sudo tuned-adm activeversão do sistema. Use a versão exibida em vez do nome comercial "SLES 15" ou "RHEL 9" como rótulo de teste.

A versão mais recente do kernel do SLES 15 SP7 o torna mais rápido que o RHEL 9?

Não por si só. As versões base do kernel não são um indicador de desempenho. A Red Hat mantém um fluxo estável de kernels com versões principais e implementa correções e recursos selecionados em versões anteriores; portanto, um kernel do RHEL 9 com versão 5.14 pode conter funcionalidades de versões upstream mais recentes. A SUSE também mantém e atualiza seu próprio fluxo de kernels suportado. O comportamento do aplicativo depende das correções, drivers, suporte de hardware, configuração e caminho de código específicos utilizados pela carga de trabalho.

Ação: registre a versão completa do pacote do kernel e o nível de lançamento para ambos os sistemas de teste. Ao investigar um recurso ou driver, verifique as notas de lançamento e a matriz de suporte de cada fornecedor para aquele lançamento específico, em vez de comparar apenas os dois primeiros números de uname -r.

Os perfis padrão do TuneD são equivalentes?

Não se deve presumir equivalência. O TuneD existe em ambos os ecossistemas, mas o conjunto de perfis instalados, a recomendação automática, o conteúdo dos perfis e as configurações locais podem ser diferentes. O guia do SUSE SLES 15 SP7 descreve as recomendações de perfil com base na configuração do sistema. A documentação do Red Hat RHEL 9 também afirma que a seleção automática de perfil depende do tipo de máquina e das configurações do sistema. Mesmo quando ambos os hosts reportam um perfil com o mesmo nome, verifique o que ele altera antes de tratar as configurações como idênticas.

Ação: execute o comando sudo tuned-adm activeem sudo tuned-adm listcada host. Salve a saída e quaisquer arquivos de perfil personalizados. Para uma comparação com a “instalação padrão”, mantenha as configurações padrão suportadas por cada fornecedor e documente-as. Para uma comparação com o “melhor desempenho possível”, otimize cada sistema operacional separadamente, seguindo as orientações do fornecedor, e relate os perfis e configurações utilizados.

Não aplique todos os perfis de desempenho de uma só vez. Os perfis podem entrar em conflito — por exemplo, uma configuração de armazenamento focada em throughput pode ser prejudicada por outra configuração que aumente o tempo de inatividade do disco. Altere uma variável relevante por vez, confirme se o serviço permanece estável e mantenha um registro de reversão.

Qual sistema provavelmente terá melhor desempenho para sua carga de trabalho?

A carga de trabalho geralmente importa mais do que um rótulo de distribuição genérico. Estas são prioridades de teste, não promessas sobre qual fornecedor sairá vencedor:

• Aplicações com uso intensivo de CPU: utilize o compilador, o ambiente de execução, as bibliotecas e as configurações de segurança de produção. Meça o trabalho concluído por segundo e o tempo de CPU. Um microbenchmark pode ajudar a explicar uma diferença, mas não substitui um teste da aplicação.
• Bancos de dados e serviços que consomem muita memória: utilize uma versão de banco de dados, esquema, tamanho do conjunto de trabalho, concorrência e política de persistência representativos. Monitore as transações por segundo, juntamente com a latência mediana e a latência de cauda; uma taxa média mais alta pode mascarar solicitações mais lentas.
• Serviços que exigem muito armazenamento: mantenha o mesmo modelo de unidade, firmware do controlador, sistema de arquivos, opções de montagem, conjunto de dados e profundidade da fila. Meça a proporção real de leitura/gravação e a distribuição de latência, não apenas a taxa de transferência sequencial máxima.
• Serviços de rede: mantenha a placa de rede (NIC), o firmware, o caminho do switch, o MTU, as configurações de offload e a carga do cliente consistentes. Meça a taxa de transferência e a latência do aplicativo com a quantidade de conexões esperada.
• Máquinas virtuais ou contêineres: compare no mesmo hipervisor ou pilha de contêineres, com a mesma alocação de CPU e memória, políticas de host, perfil de convidado e imagem. Inclua densidade e contenção de recursos, se isso refletir um ambiente de produção.
• Sistemas sensíveis à energia: registre a energia por unidade de trabalho concluída, não apenas a velocidade máxima. Um sistema que consome menos energia, embora leve mais tempo, pode não usar menos energia total para uma tarefa em lote.

Se você não sabe para onde o tempo está indo, analise o desempenho do aplicativo ou monitore o uso da CPU, a pressão na memória, a espera de E/S, a saturação da rede e as filas de execução antes de realizar ajustes. Caso contrário, um perfil de CPU mais rápido não resolverá um gargalo de armazenamento.

Como realizar uma comparação justa?

Primeiro, decida qual pergunta você está respondendo. “Qual sistema é mais rápido imediatamente após a instalação?” é diferente de “Qual sistema é mais rápido após ajustes de produção com suporte?”. Não compare a configuração otimizada de uma distribuição com as configurações padrão de outra e chame o resultado de comparação de sistemas operacionais.

1. Combine a plataforma: use modelos de servidor idênticos sempre que possível, com a mesma versão de CPU, quantidade de memória, BIOS/firmware, armazenamento, placa de rede e limites de energia.
2. Congele os detalhes do software: anote o pacote de serviços e o nível de atualização do SLES, a versão secundária e o nível de atualização do RHEL, o pacote do kernel, a versão do aplicativo, o ambiente de execução/compilador, o firmware e as mitigações de segurança relevantes.
3. Configuração de controle: registre os perfis do TuneD, o governador da CPU ou o modo de energia, as configurações de NUMA e páginas grandes, as opções de sistema de arquivos e montagem e os parâmetros do aplicativo. Mantenha-os nos valores padrão para um teste imediato ou ajuste ambos os sistemas intencionalmente para um teste otimizado.
4. Utilize dados e carga semelhantes aos de produção: faça o teste com duração suficiente para atingir um comportamento estável e inclua a concorrência e o tamanho dos dados relevantes. Defina o estado do cache e o procedimento de aquecimento para que cada execução comece de forma comparável.
5. Repita e relate a variação: alterne a ordem dos testes sempre que possível, repita as execuções e mostre a mediana mais a dispersão entre as execuções. Relate a taxa de transferência juntamente com a latência p95/p99, o consumo de recursos e os erros, quando relevantes.
6. Mantenha um registro reproduzível: publique a configuração do sistema, a versão do benchmark, os comandos ou scripts, as diferenças de ajuste e os resultados brutos. Se um resultado for para um benchmark público padronizado, siga as regras de relatório atuais desse benchmark.

As regras do SPEC CPU 2017 exigem a divulgação completa das condições relevantes para o desempenho e detalhes de configuração suficientes para reproduzir um resultado público. Esse é um padrão útil mesmo ao testar uma carga de trabalho interna. Um benchmark com uma única pontuação inexplicável não é suficiente para determinar se o resultado foi proveniente do sistema operacional, das flags do compilador, das configurações da BIOS ou de hardware diferente.

O que se sabe, o que depende da sua configuração e o que permanece sem comprovação?

• Sabe-se que a documentação atual do SLES 15 SP7 e do RHEL 9 descreve diferentes fluxos de kernel e configurações de desempenho baseadas no TuneD. Ambos os fornecedores documentam ferramentas para ajuste específico de cargas de trabalho.
• Depende do ambiente: taxa de transferência, latência, consumo de energia, tempo de inicialização, densidade de máquinas virtuais, comportamento do driver e o esforço necessário para manter a otimização consistente. Esses fatores variam de acordo com o hardware, a aplicação, a versão do software e a política operacional.
• A documentação analisada não estabeleceu: que o SLES 15 seja categoricamente mais rápido que o RHEL 9, que o RHEL 9 seja categoricamente mais rápido que o SLES 15, ou que uma versão base do kernel garanta vantagem de desempenho para todas as cargas de trabalho.

Escolha a distribuição que atenda aos seus requisitos de certificação, suporte, ciclo de vida e operacionais e, em seguida, valide o desempenho com uma prova de conceito controlada. Se a diferença medida for menor que a variação entre execuções, considere os sistemas equivalentes para essa carga de trabalho e tome a decisão com base na capacidade de suporte, compatibilidade e necessidades de administração.

Referências oficiais

• SUSE: Guia de Análise e Ajuste do Sistema SLES 15 SP7
• SUSE: Notas de lançamento do SLES 15 SP7
• Red Hat: Gerenciando, monitorando e atualizando o kernel do RHEL 9
• Red Hat: Primeiros passos com o TuneD no RHEL 9
• Red Hat: Personalizando perfis TuneD
• ESPECIFICAÇÕES: Regras de Execução e Relatório da CPU 2017
• ESPECIFICAÇÕES: Visão geral da CPU 2017 e uso justo