IPC e frequência de clock da CPU: como comparar corretamente os processadores de alojamento

IPC da CPU: instruções por ciclo de relógio

IPC da CPU significa «Instructions per Cycle», ou seja, instruções por ciclo de relógio. Para um intervalo de medição delimitado, o número de instruções de máquina concluídas é normalmente dividido pelo número de ciclos da CPU contados nesse mesmo intervalo. Um IPC de 2 significa, neste contexto, uma média de duas instruções concluídas por cada ciclo contado.

O valor é um Característica da execução, não sendo um indicador fixo para todas as tarefas de um processador. O mesmo sistema pode atingir um IPC diferente num cálculo com dados facilmente disponíveis do que numa consulta à base de dados, que muitas vezes tem de aguardar dados da memória principal. Também o conjunto de dados em questão e a secção do programa em análise influenciam o resultado.

Uma cache mantém os dados frequentemente utilizados próximos da CPU. Se, em vez disso, um núcleo tiver de aguardar acessos à memória mais lentos, as unidades de execução podem ficar temporariamente ociosas. Da mesma forma, as dependências entre instruções e os desvíos no fluxo do programa influenciam a quantidade de trabalho que pode ser executada simultaneamente. Um IPC baixo é, por isso, motivo para uma investigação mais aprofundada, mas ainda não constitui um diagnóstico definitivo.

Além disso, uma instrução de máquina não é uma unidade padronizada para um pedido na Web concluído. O compilador, o conjunto de instruções e a vetorização podem fazer com que programas diferentes necessitem de um número diferente de instruções para a mesma tarefa. Por isso, um IPC mais elevado, por si só, não comprova nem um tempo de resposta mais curto nem um maior número de pedidos por segundo.

Para uma comparação, é fundamental saber qual é a aplicação e qual é a gama de medição subjacente a esse valor. Um valor IPC sem estas informações não permite determinar se os sistemas estão, de facto, a realizar o mesmo trabalho. Encontrará mais informações básicas sobre a interação entre a frequência de relógio, os núcleos e a hierarquia de memória no artigo sobre Arquitetura da CPU na hospedagem.

Compreender a frequência de clock do servidor e o «Boost»

A frequência de clock indica quantos ciclos uma CPU executa por segundo. Um gigahertz, ou GHz, corresponde a mil milhões de ciclos por segundo. Por si só, este valor não indica quantas instruções um programa executa nesses ciclos nem quanto trabalho útil realiza com elas.

Nas fichas técnicas, é frequente encontrar uma Frequência fundamental e um aumento máximo. A frequência base serve como valor de especificação; o aumento refere-se a uma frequência mais elevada possível em condições adequadas. Ambas as indicações não substituem a observação da frequência efetivamente atingida durante a utilização concreta e a respetiva carga.

Um exemplo é o AMD EPYC 9655: para este modelo, a AMD indica 96 núcleos, 192 threads, uma frequência base de 2,6 GHz e um boost máximo de até 4,5 GHz. Estes valores descrevem as características e as especificações de frequência do processador. Não correspondem a um IPC medido nem constituem prova de um determinado débito de alojamento.

Para a série EPYC 9005, a AMD define o impulso máximo como a frequência máxima que um único núcleo pode atingir em condições normais de funcionamento do servidor. Os até 4,5 GHz do 9655 não constituem, portanto, uma garantia de que todos os 96 núcleos mantenham esta frequência de forma contínua. Os limites de potência e temperatura influenciam o comportamento sob carga.

Para uma tarefa individual de curta duração, pode ser relevante uma frequência temporariamente mais elevada; por outro lado, no caso de uma carga paralela prolongada, o que importa é a potência que o sistema fornece ao longo de todo o período de funcionamento. Outros modelos da série apresentam frequências e número de núcleos diferentes. Uma comparação baseada apenas no valor mais elevado em GHz ignoraria estas diferenças e a aplicação concreta.

Núcleos, threads e CPUs virtuais

Em termos simplificados, um processo é uma instância de programa em execução. Nele, um ou mais threads executam instruções. Um núcleo físico da CPU dispõe do hardware necessário para executar esse trabalho; os sistemas operativos identificam, consoante o processador, uma ou mais threads lógicas da CPU por núcleo. As threads lógicas do mesmo núcleo partilham, assim, partes do seu hardware.

Uma tarefa com uma secção fortemente serial não pode distribuir essa parte arbitrariamente por vários núcleos. Nesse caso, o que importa é a rapidez com que o thread executante realiza o trabalho concreto. Por outro lado, as solicitações Web independentes podem, frequentemente, ser processadas em paralelo: nesse caso, os núcleos adicionais disponíveis podem contribuir para o rendimento global, desde que não haja outros recursos que imponham limitações.

O número de threads lógicos não deve ser confundido com o número de núcleos físicos independentes. O EPYC 9655, por exemplo, tem 96 núcleos físicos e 192 threads, segundo o fabricante. O facto de ter 192 threads não implica nem uma duplicação do desempenho em relação a 96 threads, nem um determinado débito para um servidor web.

Num servidor virtual, o fornecedor disponibiliza ao sistema operativo convidado vCPUs pronta. Uma vCPU não é automaticamente um núcleo físico de utilização exclusiva: a sua atribuição ao hardware do anfitrião pode variar consoante a oferta, e o tempo de processamento pode ser partilhado com outros convidados ou estar sujeito a limites.

Pergunta a colocar antes de se optar pela atribuição concreta de recursos: o tempo de CPU está garantido ou é partilhado? Existem limites de desempenho permanentes e como é que as vCPUs são atribuídas? Um número elevado de vCPUs só ajuda uma aplicação paralela na medida em que haja efetivamente tempo de computação suficiente disponível; para uma secção serial, não substitui a execução rápida num thread.

Calcular em conjunto o IPC e a frequência de relógio

O IPC e a frequência de relógio descrevem aspetos diferentes do desempenho da CPU. Para um intervalo de medição adequadamente delimitado, é possível associar, de forma aproximada, o seu efeito: Instruções por segundo correspondem ao IPC multiplicado pelos ciclos efetivos da CPU por segundo. O IPC refere-se, neste contexto, às instruções concluídas e aos ciclos contados no mesmo intervalo.

Exemplo de cálculo ilustrativo, não se trata de uma medição: partindo do pressuposto de um valor constante de 2,0 instruções por ciclo e 3,0 GHz, obtém-se, matematicamente, 6,0 mil milhões de instruções por segundo. Mesmo com 1,5 IPC a 4,0 GHz, o resultado é de 6,0 mil milhões. Neste exemplo, a frequência mais elevada compensa, portanto, o IPC mais baixo no cálculo.

No entanto, o facto de as taxas de instruções serem iguais não significa que ambos os sistemas processem o mesmo número de pedidos na Web. Para a mesma tarefa, os programas podem necessitar de um número diferente de instruções, dependendo do compilador, do conjunto de instruções e das instruções utilizadas. Por isso, uma instrução não corresponde a uma quantidade uniforme de trabalho executado pela aplicação.

O tempo de resposta de um site também não pode ser determinado diretamente a partir do produto. Um thread pode estar à espera de dados do suporte de armazenamento ou de uma resposta da rede; entretanto, a sua taxa de instruções não explica todo o tempo decorrido. No caso de uma máquina virtual, acrescenta-se o facto de esta não receber necessariamente tempo de CPU em todos os momentos.

Para se poder fazer uma comparação, é, portanto, necessário identificar qual o código e qual o período em análise. A fórmula ajuda a classificar a execução ativa; para a decisão relativa à hospedagem, são ainda necessárias as tarefas concluídas e os respetivos tempos de resposta, no âmbito de um perfil de pedidos comparável.

Classificar a ficha técnica e os indicadores-chave

Uma ficha técnica fornece indicações úteis para a escolha de um processador para alojamento web. No entanto, os dados respondem a questões diferentes: o IPC descreve um comportamento na respetiva gama de medição, enquanto os dados relativos à frequência e ao número de núcleos especificam as características de um modelo de processador. Só quando considerados em conjunto com a aplicação é que se tornam critérios de comparação úteis.

O EPYC 9655 ilustra como essas especificações se relacionam: segundo a AMD, o modelo possui 96 núcleos e 192 threads, uma frequência base de 2,6 GHz e um boost máximo de até 4,5 GHz. Os 4,5 GHz não representam uma frequência garantida para todos os núcleos sob carga contínua, nem uma taxa de transferência de hospedagem medida.

Uma classificação com base no GHz máximo ocultaria a quantidade de trabalho que os diferentes processadores realizam por ciclo e por tarefa. Por outro lado, uma classificação com base no número de núcleos ignora o facto de nem todas as aplicações conseguirem distribuir o seu trabalho em paralelo com a mesma eficácia. Ambos os dados são pontos de partida, não avaliações definitivas do desempenho.

Por isso, quando se trata de ofertas, presta atenção ao Variante do modelo e quais os recursos que estão efetivamente disponíveis. Para uma comparação fiável, precisas também de um perfil de carga adequado e de resultados obtidos com software e configuração comparáveis. As especificações dos diferentes modelos não devem ser confundidas com um valor máximo assumido para toda a família de produtos.

Escolher a CPU do alojamento em função do perfil de carga

A escolha da CPU adequada para alojamento depende das tarefas que o servidor deverá realizar. Uma tarefa única de longa duração apresenta requisitos diferentes dos de muitas solicitações web independentes. A tabela traduz perfis de carga típicos num parâmetro de referência prioritário e numa questão que deve ser esclarecida antes da escolha.

No caso de uma tarefa individual, o desempenho do thread que a executa é particularmente importante quando uma grande parte do trabalho decorre em série. Um maior número de núcleos não reduz automaticamente essa parte. Um breve pico de desempenho também não é prova suficiente para uma tarefa de longa duração: o que é decisivo é o seu tempo de execução medido nas condições previstas.

Por outro lado, muitas consultas independentes podem ser processadas em paralelo. Neste caso, além do desempenho por thread, o que conta é o número de recursos disponíveis simultaneamente e a evolução dos tempos de resposta à medida que a carga aumenta. A soma dos valores nominais em GHz não substitui uma comparação do Rendimento total com o mesmo grau de paralelismo.

Numa base de dados com um conjunto de dados de trabalho de grande dimensão, os acessos à memória podem atrasar a execução se os dados necessários não forem fornecidos de forma eficaz a partir das caches. Um IPC baixo pode ser motivo para análises mais aprofundadas, mas não prova, por si só, a existência de um estrangulamento na memória. Por isso, verifica também as consultas, o conjunto de dados e a configuração da memória antes de substituíres a CPU.

No caso do VPS, existe ainda a Compromisso de recursos É fundamental: uma vCPU não corresponde automaticamente a um núcleo físico exclusivo. É necessário esclarecer a atribuição, os possíveis limites da CPU e a partilha com outros convidados. Só com estas informações é que se pode comparar de forma significativa um teste de aplicação com uma oferta num servidor dedicado.

Planear testes de aplicação comparáveis

Uma comparação significativa começa com a tua aplicação, e não com um valor isolado da CPU. Define a mesma versão de software, o mesmo conjunto de dados e a mesma configuração para ambas as ofertas de alojamento. A SPEC considera que a própria aplicação na própria infraestrutura é o padrão ideal para a escolha do produto.

Em seguida, define um Perfil da solicitação, que reflita da melhor forma possível a utilização futura: por exemplo, quais as páginas ou pontos finais da API que são acedidos e quantas solicitações chegam simultaneamente. Mantém a paralelidade e os limites de recursos comparáveis entre as execuções. Caso uma oferta estabeleça outros limites, documenta-os expressamente, em vez de atribuir a diferença apenas à CPU.

Preveja uma fase de aquecimento para que, por exemplo, a aplicação seja iniciada e as caches possam ser preenchidas. Posteriormente, várias execuções com duração suficiente ajudam a distinguir as flutuações de curto prazo de uma diferença recorrente. Registe também se, durante a medição, estavam a ser executadas outras tarefas nos sistemas.

Registe, para além do rendimento, o Distribuição dos tempos de resposta e os erros. Uma média mais elevada de pedidos concluídos por segundo pouco serve, por si só, se alguns pedidos demorarem muito tempo a ser processados ou falharem com maior frequência. Por isso, compare também os percentis elevados do tempo de resposta, mantendo o mesmo nível de paralelismo.

Os resultados publicados do SPEC-CPU2017 podem servir como orientação complementar. O SPECspeed mede o tempo necessário para a execução de tarefas, enquanto o SPECrate mede o débito; estas duas métricas não são diretamente intercambiáveis. Compare resultados da mesma métrica e tenha em conta a configuração do sistema e o software. O conjunto de testes da CPU não reflete a rede e as E/S de um serviço de alojamento completo.

Verificar o IPC e a frequência durante o funcionamento

Para criar o teu próprio ambiente de teste Linux, podes utilizar o perf para registar as instruções e os ciclos concluídos de um programa existente e testado. No exemplo seguinte, testprogramm Um espaço reservado: substitui-o pelo teu programa de teste e, se for o caso, pelos seus argumentos. O comando é uma sugestão de medição, não um teste já executado.

perf stat -e '{instructions,cycles}' -- testprogramm

As chaves agrupam os acontecimentos numa Grupo de contadores em conjunto. Devem ser registadas simultaneamente, o que pode reduzir os erros decorrentes da multiplexação com desfasamento temporal. Divida o número de instruções contadas pelo número de ciclos contados para obter o IPC para este intervalo de medição; o «perf» também pode apresentar este valor diretamente.

A disponibilidade dos eventos e a possibilidade de os ler dependem do hardware, do kernel, das autorizações e, se for o caso, do ambiente de virtualização. Um grupo de eventos indisponível ou que não possa ser contabilizado em conjunto não permite uma comparação fiável. Não altere as definições de segurança apenas para este exemplo.

Também a indicação de uma frequência requer contexto: scaling_cur_freq De acordo com a documentação do kernel, em muitos casos corresponde ao último estado solicitado pelo controlador e não necessariamente à frequência de hardware efetivamente atingida. O valor, que nem sempre está disponível, cpuinfo_cur_freq por outro lado, deve indicar a frequência atual detetada pelo hardware. Mais informações sobre o Regulador da CPU em servidores de alojamento explica o controlo do escalonamento de frequência.

Um IPC baixo é um indício para a realização de análises mais aprofundadas, mas não constitui um diagnóstico definitivo. Os acessos à memória podem abrandar a execução; da mesma forma, é necessário verificar qual a parte do programa que foi medida e se existem outros fatores que possam influenciar o resultado. Por isso, compara o valor do contador com o comportamento da aplicação e o seu acesso aos dados.

Identificar o gargalo e decidir pela atualização

Começa por um sintoma concreto: as consultas ficam lentas sob carga, a taxa de erros aumenta ou uma tarefa específica demora demasiado tempo? Anota quando o problema ocorre e quais as tarefas que estão a ser executadas em simultâneo. Só assim será possível verificar se um maior desempenho da CPU pode, de facto, reduzir o atraso em questão.

Verifica, em primeiro lugar, o espaço disponível e o espaço utilizado tempo de CPU. Uma tarefa que exige um esforço computacional contínuo pode beneficiar de uma execução mais rápida ou de um maior grau de paralelismo utilizável. No entanto, a elevada carga de trabalho, por si só, não explica qual o código que a provoca, nem se o tempo de resposta se deve principalmente a essa tarefa. Por isso, compare este resultado com o débito e os tempos de resposta da mesma fase de carga.

Em seguida, analise as necessidades de memória e os acessos aos dados. Se uma base de dados tiver de aceder frequentemente a dados fora da cache da CPU, pode ficar à espera da memória; um IPC baixo pode indicar isso, mas não prova a causa. A falta de memória de trabalho, os acessos a dispositivos de armazenamento ou serviços externos lentos também podem influenciar o atraso observado.

Num VPS, a Compromisso de recursos Quanto ao diagnóstico: questione a atribuição das vCPUs, os possíveis limites da CPU e a partilha com outros convidados. Um servidor dedicado oferece uma atribuição diferente de recursos físicos, mas também nesse caso a aplicação, a configuração e o perfil de carga determinam o resultado. Compare ambas as ofertas, se possível, utilizando o mesmo teste de aplicação.

Considera uma atualização da CPU se as medições indicarem um gargalo na CPU e se o novo plano for realmente capaz de fornecer o tempo de processamento necessário. Se o atraso se dever principalmente à memória, ao suporte de dados ou a um serviço externo, faz mais sentido aprofundar a análise nessas áreas. Regista o estado inicial para que possas avaliar posteriormente qualquer alteração de forma comparável.

Não interprete os valores máximos de boost como uma frequência contínua garantida para todos os núcleos, nem um valor de IPC como uma característica universal da CPU. Da mesma forma, um único valor de utilização não é suficiente para um diagnóstico completo de gargalos. A decisão deve ser tomada com base na tarefa concreta e nos recursos efetivamente disponíveis, e não com base num único valor de pico.