Por que medir antes de aceitar
Um cluster pode cumprir toda a lista de especificações e, mesmo assim, rodar o código do laboratório mais devagar que o esperado. A causa costuma estar no que a lista deixou de fora.
Os casos típicos são memória pouca por núcleo, rede saturada quando a simulação usa vários nós, disco lento na hora de gravar resultados e bibliotecas compiladas sem otimização.
O aceite por benchmark muda o que se confere na entrega. A pergunta deixa de ser se cada peça chegou e passa a ser se o conjunto entrega o desempenho combinado. A meta vai para o contrato antes da compra, é medida depois da instalação e fica registrada num relatório da instituição.
O teste principal: o código do grupo
O teste que mais importa é o código que o grupo usa de verdade. Para servir de critério de aceite, ele precisa de quatro coisas:
- Um caso de teste representativo. Uma simulação real em tamanho reduzido, que rode entre alguns minutos e algumas horas. Um caso curto demais mede só a inicialização.
- Uma medição de referência. O tempo desse caso no equipamento atual ou num ambiente de teste, com a versão do código e as opções de compilação anotadas.
- Uma meta numérica. Tempo máximo de execução ou ganho mínimo sobre a referência, com o número de nós e a tolerância.
- Um resultado conferido. A saída da simulação precisa bater com a referência dentro da tolerância numérica do código. Rodar rápido com resultado errado reprova.
Se o código usa vários nós, meça também o tempo com 1, 2, 4 e 8 nós. Quando o tempo para de cair a partir de certo ponto, o limite está na rede ou no próprio código, e isso aparece antes da compra.
Os testes padrão
Quatro testes de uso livre, conhecidos na área, olham cada parte do cluster em separado. Eles ajudam a investigar quando o código do grupo fica abaixo da meta.
| Teste | O que mede | Ajuda a investigar |
|---|---|---|
| HPL (Linpack) | Desempenho do sistema em álgebra linear densa | Processadores, memória e rede trabalhando juntos. É o teste da lista TOP500. |
| STREAM | Banda de memória de cada nó | Memória instalada fora do ideal, com canais vazios. |
| OSU Micro-Benchmarks | Latência e banda das mensagens MPI entre nós | Cabos, placas ou configuração de rede. |
| IOR | Leitura e escrita no armazenamento compartilhado | Disco ou sistema de arquivos abaixo do necessário. |
Para cada teste, o contrato fixa a meta e o modo de execução: número de nós, versão, parâmetros principais e quantas repetições contam.
Como escrever as metas
Uma meta bem escrita pode ser repetida por qualquer pessoa da equipe, seguindo o roteiro, com o mesmo resultado dentro da tolerância.
- Tolerância. O desempenho varia de uma execução para outra. Use a mediana de três ou cinco execuções e uma margem combinada.
- Ambiente congelado. Anote as versões do sistema, do compilador, da biblioteca MPI e do código.
- O que acontece se falhar. Prazo para ajuste, troca ou acréscimo de componentes por conta do fornecedor e, no limite, desconto ou devolução.
- Aceite em duas fases. O provisório confirma a instalação. O definitivo vem depois de um período de uso real sem falhas graves, por exemplo 30 dias.
Roteiro do dia do aceite
- Conferência física: equipamentos, números de série e cabeamento comparados ao projeto.
- Estabilidade: todos os nós sob carga por algumas horas, sem erro de memória ou de rede.
- Testes padrão: HPL, STREAM, OSU e IOR, com os parâmetros do contrato.
- Código do grupo: o caso de teste, com a mesma versão e as mesmas opções da medição de referência, e o resultado conferido.
- Filas: tarefas enviadas por usuários comuns, com limites, prioridades e relatório de uso funcionando.
- Relatório: resultados, versões e comandos, assinado pelas duas partes.
O relatório fica com a instituição e serve de base para acompanhar o desempenho do cluster nos anos seguintes.
Perguntas frequentes
Qual a diferença entre o HPL e o benchmark do meu código?
O HPL mede o desempenho do sistema em álgebra linear densa e serve para comparar máquinas, como na lista TOP500. O benchmark do seu código mede o que importa para o grupo: quanto tempo a sua simulação leva e se o resultado está certo. Os dois entram no aceite, com pesos diferentes.
E se o cluster não atingir a meta?
O contrato deve prever o caminho: ajuste de configuração dentro de um prazo, troca ou acréscimo de componentes por conta do fornecedor e, no limite, desconto ou devolução. Sem essa cláusula, a meta vira intenção.