...

AMD EPYC ou Intel Xeon: escolher a plataforma certa para o alojamento web

No que diz respeito ao alojamento web, não há um vencedor claro entre o AMD EPYC e o Intel Xeon. A plataforma adequada adapta-se ao perfil de carga: A densidade de núcleos e os limites são importantes na hospedagem partilhada, bem como o desempenho por worker ativo em aplicações dinâmicas, enquanto os nós VPS e de bases de dados requerem, sobretudo, memória RAM, disposição NUMA e topologia de E/S. Por isso, compare modelos específicos do EPYC 9005 e do Xeon 6, juntamente com a plataforma de servidor, com base em medições reproduzíveis, em vez de se basear no número de núcleos, na frequência de clock ou em benchmarks isolados.

Perfis de alojamento antes da comparação de CPU

A hospedagem web não constitui uma carga de trabalho uniforme para a CPU. Uma plataforma para milhares de pequenas contas segue regras diferentes das de um nó para máquinas virtuais ou de um servidor de bases de dados. Antes de comparar o AMD EPYC e o Intel Xeon, devem, portanto, estar definidos o perfil de consultas, o número de clientes ativos em simultâneo, as necessidades de RAM, a E/S de armazenamento e os tempos de resposta aceitáveis. Só esta combinação torna os dados técnicos de um processador relevantes para a aquisição.

hospedagem compartilhada processa muitas tarefas independentes entre si em PHP, CMS e e-mail, com picos de carga frequentemente curtos. Uma elevada densidade de núcleos pode ajudar, mas limites eficazes para o tempo de CPU, processos, memória e E/S são igualmente importantes. Sem esses limites, uma única conta pode ocupar recursos escassos e prejudicar os tempos de resposta de outros clientes. A segregação planeável de clientes é, neste contexto, frequentemente mais importante do que um valor de pico num teste sintético multicore.

No caso dos CMS e lojas online geridos, os requisitos são mais variados. Pedidos PHP dinâmicos, cache de objetos, consultas à base de dados, tarefas cron e acessos de administração ocorrem, por vezes, em simultâneo. Para algumas aplicações exigentes, é possível Desempenho por núcleo pode ser mais importante do que o número máximo de núcleos; por outro lado, quando há um número elevado e constante de workers PHP-FPM independentes, a paralelização ganha importância. O que continua a ser decisivo é se o servidor Web, os processos PHP e a base de dados estão devidamente dimensionados.

Uma loja WooCommerce ilustra bem essa separação: um servidor web com cache consegue fornecer imagens estáticas de produtos de forma muito eficiente. No entanto, o cesto de compras, o processo de checkout e o stock geram execução personalizada de PHP e acessos à base de dados. Um maior número de núcleos de CPU não elimina o tempo de espera se as consultas não encontrarem índices, se o buffer pool for demasiado pequeno ou se a latência do NVMe aumentar sob carga. Por isso, a latência das solicitações, os tempos de resposta da base de dados e os tempos de espera de E/S devem ser registados separadamente.

Os nós VPS e na nuvem necessitam, para além da capacidade de computação, sobretudo de RAM suficiente, largura de banda de armazenamento, rede e uma distribuição de recursos transparente. O «CPU-pinning», a memória reservada, a atribuição NUMA e o QoS de armazenamento influenciam a experiência dos utilizadores de forma mais significativa do que o logótipo do fabricante. Os sistemas de bases de dados, Redis e sistemas próximos do armazenamento avaliam ainda o conjunto de trabalho (working set), o tamanho da cache, a carga de gravação e a ligação direta a SSDs NVMe. Aqui, é importante uma Topologia da plataforma muitas vezes mais decisivo do que um simples valor de débito do servidor web.

Classificar o EPYC 9005 e o Xeon 6 como base de comparação

Este artigo compara deliberadamente o AMD EPYC 9005 e o Intel Xeon 6 como gerações de plataformas claramente diferenciadas. Esta comparação destina-se à aquisição, expansão ou avaliação de sistemas baseados nestas duas famílias de produtos. Não é possível deduzir conclusões sobre outras gerações ou linhas de produtos a partir desta comparação, uma vez que a arquitetura dos núcleos, a plataforma de memória, o equipamento de E/S e as funcionalidades disponíveis podem diferir.

Além disso, uma função do processador documentada difere de uma função que é, de facto, sistema de servidor disponível no mercado distinguir. A placa-mãe, o firmware, a configuração dos módulos DIMM, o sistema de refrigeração, as fontes de alimentação e as certificações OEM determinam quais as configurações que são viáveis na prática. Por isso, verifique, para cada SKU específica, quais os modelos de servidor disponíveis e validados para a configuração planeada. Isto aplica-se especialmente a capacidades elevadas de RAM, a um grande número de unidades NVMe e a funções especiais de virtualização.

As gerações mais antigas da série EPYC 700x e os modelos anteriores da série Xeon Scalable não devem ser confundidos com o EPYC 9005 ou o Xeon 6. Da mesma forma, os dados de outras linhas de produtos não devem ser aplicados a estas famílias. A arquitetura do núcleo, o equipamento de E/S, a plataforma de memória e as funcionalidades disponíveis podem variar entre as gerações. Por isso, uma comparação de aquisição requer sempre a designação completa do modelo, o número de soquetes e a placa-mãe do servidor utilizada.

A série EPYC 9005 inclui, consoante o modelo, processadores com Zen 5– ou núcleos Zen-5c. Estas designações não descrevem uma hierarquia geral para a hospedagem. O que é relevante é, antes, a SKU específica, o número de núcleos, o comportamento de clock, os parâmetros térmicos e o paralelismo previsto. Uma variante com muitos núcleos pode ser adequada para muitos clientes bem delimitados, enquanto um modelo com características diferentes pode ser mais adequado para um número menor de aplicações que exigem um elevado poder de cálculo.

A Intel divide o Xeon 6 em variantes com P-Cores e E-Cores. Os P-Cores estão orientados para um elevado desempenho por núcleo e suportam, entre outros, AVX-512 e AMX. Isto pode revelar-se relevante quando o software utilizado recorre efetivamente a estas funções vetoriais ou matriciais; uma pilha comum de PHP ou de servidor web não obtém automaticamente qualquer vantagem com isso. Os núcleos E, por outro lado, visam uma elevada densidade de núcleos e um rendimento paralelo.

Para cargas de trabalho partilhadas ou na nuvem, densas e bem isoladas, os núcleos Xeon 6-E podem, por isso, ser uma opção a considerar. Os núcleos Xeon 6-P ou os modelos EPYC 9005 devidamente configurados são também candidatos óbvios para cargas de trabalho com maior necessidade de desempenho por núcleo individual. Trata-se de uma orientação sobre a linha de produtos, não de uma garantia de desempenho. A expansão da memória RAM, o firmware e a configuração de software podem influenciar significativamente o resultado e distorcer uma comparação entre os tipos de núcleos sem uma configuração de plataforma idêntica.

As sementes são apenas um dos fatores

Os núcleos da CPU só revelam o seu potencial se a memória e as E/S acompanharem o ritmo. Os canais DDR5, juntamente com a configuração e o tipo de DIMM, determinam a largura de banda de memória disponível; por outro lado, a capacidade da RAM limita o número de máquinas virtuais, buffers de bases de dados ou caches que podem ser operados sem necessidade de paging. As pistas PCIe ligam unidades NVMe, placas de rede e, se for o caso, aceleradores. No âmbito da hospedagem, esta cadeia deve ser planeada como um sistema integrado.

A AMD indica que o EPYC 9005 suporta até doze canais DDR5, bem como, dependendo do número de soquetes e da plataforma, uma ampla conectividade PCIe Gen 5. Para sistemas de soquete único, são referidas até 128 pistas PCIe Gen 5. O Intel Xeon 6 também oferece, dependendo da série, até doze canais DDR5; determinadas configurações de soquete único com núcleos P atingem até 136 pistas PCIe. Estes valores referem-se a dados de modelos e plataformas, não constituindo uma garantia de desempenho de uma aplicação.

Topologia esquemática da plataforma com CPU, memória RAM, unidades NVMe e placas de rede.
Os canais de memória e os caminhos PCIe contribuem para determinar se a capacidade da CPU é aproveitada na hospedagem.

Um nó VPS com vários SSDs NVMe, duas placas de rede rápidas e muitas máquinas virtuais ilustra a diferença na prática. Se as unidades ou as placas de rede estiverem ligadas através de switches PCIe, é possível que partilhem uma ligação de subida. A placa-mãe também determina a divisão de faixas, as ranhuras, a bifurcação, o suporte a CXL e a configuração de firmware efetivamente ativada. Por isso, a capacidade da CPU documentada deve ser comparada com o diagrama de blocos e a validação do servidor específico.

Em sistemas com vários nós NUMA, é também determinante a localização da memória RAM, das CPUs virtuais e dos dispositivos de E/S. Se uma VM ou uma base de dados aceder frequentemente à memória de outro nó, podem ocorrer latências adicionais. Por isso, faz sentido realizar medições em condições de utilização realistas: a utilização da CPU, por si só, não revela nem os estrangulamentos de memória nem as filas de espera no armazenamento ou na rede.

Muitas pistas facilitam a ligação direta de inúmeros dispositivos, mas não garantem nem uma baixa latência da base de dados nem elevadas taxas de transação. O controlador, o firmware do SSD, a configuração RAID ou de replicação, a profundidade da fila e o caminho de rede continuam a ser fatores determinantes. A escolha entre Hospedagem AMD EPYC e, no caso de um servidor Intel Xeon, deve, por isso, ter em conta os requisitos de E/S e de memória de forma tão concreta como o número de núcleos e a frequência.

Sincronizar cargas de trabalho com a plataforma

A escolha não começa pelo fabricante, mas sim pela distribuição da carga de trabalho. O Xeon 6 com núcleos E é, em princípio, adequado para um grande número de tarefas independentes entre si e bem delimitadas; o Xeon 6 com núcleos P é indicado para requisitos que exigem Desempenho por núcleo e determinadas operações vetoriais ou matriciais. O EPYC 9005 também abrange diferentes perfis de núcleos e frequências de clock. Daí não decorre qualquer hierarquia: o que é determinante é o SKU específico, a topologia do servidor e a carga de trabalho da aplicação medida.

Critérios de seleção de acordo com a carga de trabalho de alojamento
Carga de trabalhoCritério mais importante relativo ao CPUCritério mais importante da plataformaGargalos típicosValores de medição necessários
hospedagem compartilhadaElevado nível de paralelismo com limites de conta eficazesRAM por conta, agendador e limites de E/SAlgumas contas consomem CPU, RAM ou E/S de discoTempo de resposta p95, processos ativos, fila de execução, limitação da CPU e tempo de espera de E/S; «Steal-Time» apenas em hosts virtualizados
CMS e lojas onlineDesempenho por worker PHP ativo, além de paralelismo suficienteCache de objetos rápido, RAM da base de dados e latência NVMeFilas do PHP-FPM, consultas lentas, falhas de cachep95/p99 – Tempo de pedido, carga dos workers, tempo de consulta, taxa de acertos na cache
VPS e nuvemDensidade de núcleo ou desempenho garantido por vCPU, de acordo com o plano tarifárioDisposição NUMA, capacidade de RAM, rede e QoS de armazenamentoSobrecarga da CPU, alocação desigual de RAM, concorrência no armazenamentoLatência de convidado, IOPS, débito, latência de rede, bem como, dependendo do hipervisor, tempo de disponibilidade da CPU, fila de execução, tempo de interrupção ou métricas de agendamento semelhantes
Base de dados e RedisDesempenho da cache e da memória, em função do paralelismoExpansão de DDR5, afinidade NUMA e ligação direta ao armazenamentoMemória RAM insuficiente, acessos NUMA remotos, NVMe lento ou sobrecarregadoLatência de consulta ou de comando, acertos no buffer pool, latência de E/S, largura de banda da memória
Serviços relacionados com NVMeCPU com capacidade suficiente para a carga de protocolos e de testesTopologia PCIe, número de ligações diretas a unidades de disco e placas de redeSwitches PCIe, filas, limite de rede ou de replicaçãop99 - Latência de E/S, profundidade da fila, IOPS, débito, utilização da rede

Na hospedagem partilhada, uma elevada densidade de núcleos só é útil se os limites de tempo de CPU, processos, memória e E/S protegerem efetivamente as contas vizinhas. Por isso, os modelos E-Core podem ser adequados para ambientes de clientes altamente paralelizados. Um modelo EPYC 9005 com um perfil de núcleos adequado também pode ser adequado. Por outro lado, para instâncias individuais exigentes de lojas online ou CMS, os tempos de resposta por trabalhador e a base de dados são mais importantes do que o mero número de núcleos disponíveis.

Os nós VPS e os serviços próximos do armazenamento exigem, além disso, uma verificação do Topologia de E/S. O EPYC 9005 apresenta recursos abrangentes de DDR5 e PCIe 5.0, dependendo da plataforma; o Xeon 6 também oferece canais de memória e pistas PCIe que variam consoante a série e o modelo. Estes dados facilitam a pré-seleção, mas não garantem uma determinada latência NVMe nem um determinado débito de base de dados. A placa-mãe, a configuração, o firmware e a pilha de software continuam a fazer parte da decisão.

Planear corretamente os testes de desempenho da CPU para serviços de alojamento

O termo de pesquisa benchmark de CPU em alojamento web leva a uma simplificação indevida: um resultado da CPU não descreve uma oferta de alojamento. A SPEC considera os resultados como reflexos de sistemas completos e exige a divulgação de detalhes essenciais da configuração. Para uma comparação entre plataformas, é, portanto, necessário testar ambos os candidatos com um número comparável de soquetes, capacidade de memória, armazenamento, rede e software.

Protocolo de benchmark reproduzível para plataformas de alojamento
Objetivo do testeGerador de carga ou ferramentaVariável medidaInformações obrigatórias sobre o ambienteCritérios de exclusão
PHP-FPM e servidor webCarga HTTP representativa com percursos anonimizados e tempos de resposta realistasPedidos por segundo, latência p95/p99, taxa de errosModelo da CPU, RAM, NVMe, rede, sistema operativo, kernel, servidor web, versão do PHP e pools do FPMApenas respostas estáticas, caches diferentes ou limites de trabalhadores distintos
Base de dadosConsultas orientadas para a aplicação e volume de dados definidoTempo de consulta, transações, latência p95/p99, tempo de espera de E/SAlém disso, versão da base de dados, parâmetros, buffer pool, índices, tamanho dos registos e modo de replicaçãoCache quente apenas numa plataforma ou conjuntos de dados desiguais
Densidade de VPSHóspedes definidos com carga idêntica e reserva de recursosLatência do sistema convidado, débito, IOPS e, dependendo do hipervisor e do sistema operativo convidado, tempo de disponibilidade da CPU, tempo de roubo, fila de execução ou métricas de agendamento semelhantesAlém disso: hipervisor, sistema operativo convidado, fixação de CPU, mapeamento NUMA, reserva de RAM e QoS de armazenamentoOutra taxa de sobre-reserva, topologia de vCPU, metodologia de medição ou carga de fundo do anfitrião

No caso do PHP-FPM, um elevado débito de pedidos não é suficiente. Uma plataforma pode fornecer muitas respostas com uma carga sintética de curta duração e, ainda assim, gerar valores p99 elevados quando existem tarefas Cron executadas em paralelo ou consultas lentas à base de dados. Por isso, registe as filas de espera, as taxas de erro e os tempos de resposta separadamente para páginas dinâmicas e em cache. As implementações com controlo de versões ajudam a registar de forma inequívoca a aplicação e a configuração testadas. Fluxos de trabalho do Git no alojamento

No caso das bases de dados, o tamanho dos registos e o estado da cache têm de ser documentados, porque um teste realizado inteiramente na RAM apresenta limites diferentes dos de um funcionamento com elevada carga de E/S. No que diz respeito à densidade de VPS, a experiência no sistema convidado é também determinante. A métrica de agendamento mais relevante depende do hipervisor e do sistema operativo convidado; por isso, o tempo de CPU Ready não deve ser tratado como uma métrica universalmente aplicável. Repita os testes de carga e registe abertamente o método de medição, bem como quaisquer desvios.

Verificar a configuração e a topologia

Antes de fazer uma comparação, deve primeiro registar o estado atual. Isto evita que uma suposta diferença na CPU resulte, na realidade, de uma atribuição NUMA diferente, de memória RAM diferente ou de uma configuração alterada do servidor web. Os comandos seguintes leem informações ou verificam configurações; não alteram nem a atribuição de CPUs nem as definições dos serviços. Execute-os com as autorizações necessárias no respetivo sistema e guarde os resultados de forma segura.

Com lscpu registas o modelo da CPU, as CPUs lógicas, o soquete, os núcleos e os nós NUMA detetados. numactl --hardware Desde que a ferramenta esteja instalada, complementa as CPUs e a memória disponíveis por nó NUMA. Ambas as saídas descrevem a topologia de hardware detetada, e não a utilização real sob carga de alojamento.

Terminal
lscpu
numactl --hardware
nginx -T
php-fpm -tt

O apelo nginx -T apresenta a configuração efetiva do NGINX e, por isso, pode conter nomes de anfitriões internos, percursos de ficheiros ou referências a certificados. Verifica e corrige essas informações antes de partilhar o resultado. php-fpm -tt servi como exemplo de uma verificação de configuração; o nome do ficheiro binário e as opções variam consoante a distribuição e a versão do PHP. Verifica primeiro a variante disponível localmente, em vez de alterares uma configuração em produção.

Um caso prático de VPS ilustra o objetivo: se as vCPUs de uma VM estiverem atribuídas a núcleos de um nó NUMA, mas a RAM que lhes está reservada se encontrar predominantemente no outro nó, os acessos à memória podem sofrer latência adicional. Por isso, documenta Fixação da CPU e a alocação de RAM em conjunto. Só depois disso é que se pode avaliar se é necessária outra plataforma de CPU ou, numa primeira fase, uma topologia de máquina virtual mais consistente.

Implementar a virtualização de forma segura e planeada

No caso das ofertas de VPS e na nuvem, o nome do processador, por si só, não determina o desempenho percebido. Fixação da CPU associa vCPUs a núcleos físicos específicos, conforme necessário, podendo assim reduzir as variações nos tempos de execução. Trata-se, no entanto, de uma decisão de capacidade: os núcleos reservados em exclusivo não estão disponíveis para uma distribuição flexível a outros clientes. Para planos com capacidade de computação garantida, esta reserva deve, por isso, ser incluída no planeamento da utilização da capacidade.

Igualmente importante é a Afinidade NUMA em sistemas com vários soquetes ou com um elevado número de núcleos. Uma VM deve, na medida do possível, utilizar núcleos de processamento e memória RAM do mesmo nó NUMA. Se aceder regularmente à memória de outro nó, as vias de acesso adicionais podem aumentar a latência. Por isso, planeie inicialmente as máquinas virtuais de grande dimensão com base na capacidade de RAM local e na atribuição de núcleos, em vez de considerar apenas a soma de todos os núcleos e da memória total.

Exemplo simplificado de vários domínios NUMA com máquinas virtuais, núcleos de CPU e memória alocados localmente.
Os domínios NUMA dependem do processador, da plataforma e do firmware; uma atribuição adequada pode reduzir os acessos remotos desnecessários à memória.

A RAM reservada impede que a capacidade de memória prometida resulte apenas de uma sobre-reserva otimista. Além disso, limita QoS de armazenamento IOPS, débito ou filas por VM, para que uma cópia de segurança, uma importação de base de dados ou um convidado mal configurado não bloqueie o pool NVMe partilhado. Defina limites de sobrealocação separadamente para a CPU, a RAM e o armazenamento: uma quota de CPU viável não torna um nó resistente se o seu armazenamento já estiver a gerar tempos de espera elevados durante picos de carga.

No que diz respeito a máquinas virtuais confidenciais, ambas as plataformas oferecem funcionalidades que vão além da virtualização convencional. A AMD documenta, para o EPYC 9005, as tecnologias SEV, SEV-ES e SEV-SNP; a SEV-SNP complementa mecanismos de proteção contra determinados ataques às tabelas de páginas e à alocação de memória. A Intel descreve o TDX como uma tecnologia que isola o sistema operativo convidado e as aplicações da máquina virtual em relação ao anfitrião da nuvem, ao hipervisor e a outras máquinas virtuais na plataforma.

Essas funcionalidades não tornam automaticamente mais seguro nem um servidor AMD EPYC nem um servidor Intel Xeon. No caso do Intel TDX, é necessário verificar os processadores suportados, a configuração adequada de DIMMs e a plataforma específica do OEM ou ODM; as especificações documentadas para os módulos DIMM podem variar consoante a implementação da plataforma. Além disso, a funcionalidade pressupõe uma interação coordenada entre o firmware, o hipervisor, o kernel, o sistema operativo convidado e os processos operacionais. Verifique também o ciclo de vida da chave, a certificação, a recuperação e a monitorização. Sem estes processos, uma função de hardware ativada não consegue satisfazer totalmente os requisitos de proteção de um cliente.

Fontes de erro na comparação e no funcionamento

Uma comparação válida começa com sistemas de dimensões idênticas. Um servidor com dois soquetes não deve ser comparado com um sistema de um único soquete, quando a questão da aquisição diz respeito a uma classe de plataforma. Registe, por cada teste, o modelo da CPU, o número de soquetes, os núcleos ativos, a quantidade de RAM e a configuração dos módulos DIMM. Só assim será possível determinar se um resultado se deve à arquitetura, a hardware adicional ou a uma configuração diferente.

Além disso, memórias e E/S desiguais também distorcem as conclusões. Diferentes configurações de canais DDR5, gerações NVMe, disposições RAID, placas de rede ou perfis de energia da BIOS alteram significativamente o débito e as latências. A AMD salienta, no que diz respeito ao EPYC 9005, que a configuração concreta de E/S depende da plataforma e da placa-mãe; a capacidade de interface documentada não constitui, portanto, uma garantia para a aplicação.

Embora muitas pistas PCIe facilitem a ligação direta de várias unidades NVMe e placas de rede de alta velocidade, não garantem uma baixa latência da base de dados: as filas no armazenamento, o firmware do controlador, a replicação, os parâmetros da base de dados e o conjunto de trabalho na RAM continuam a ser fatores determinantes. No que diz respeito às arquiteturas próximas do armazenamento, o artigo complementa Alojamento web para plataformas de IoT a perspetiva sobre a latência da rede, a segmentação e os percursos de memória.

Os picos de Boost isolados também não constituem um parâmetro de referência para servidores. A AMD define o Boost máximo como a frequência que um único núcleo pode atingir em condições normais de funcionamento de um servidor; sob carga contínua paralela, aplicam-se outras condições térmicas e energéticas. Por isso, avalie os percentis de tempo de resposta e a taxa de transferência em condições representativas de simultaneidade, em vez de deduzir o desempenho de um nó inteiro a partir de um único valor de frequência.

Afinal, o TDP não é uma medição do consumo real do servidor. Para estimativas de custos, precisas de valores de medição de todo o sistema, com a RAM, o armazenamento, a carga de rede e o perfil energético selecionados. O Comparabilidade A divulgação pública dos resultados exige, além disso, informações completas sobre o sistema; a SPEC trata os resultados expressamente como resultados de sistemas completos, e não de processadores individuais.

Tomar decisões em matéria de aquisições com base em requisitos mensuráveis

Primeiro, documente o perfil de carga: número e dimensão dos clientes, simultaneidade típica e máxima, percentagem de PHP ou da aplicação, consultas à base de dados, taxa de acertos na cache, RAM por instância, bem como picos de E/S e de rede. O resultado não é uma classificação abstrata, mas sim um catálogo de requisitos. Só este catálogo revela se o fator decisivo é uma elevada densidade de núcleos, tempos de resposta curtos de cada worker ou uma ligação de armazenamento particularmente abrangente.

Em seguida, determine se pretende expandir uma plataforma existente, avaliar sistemas usados ou em stock, ou adquirir uma configuração de servidor totalmente nova. No caso do EPYC 9005 e do Xeon 6, é necessário verificar a disponibilidade, as aprovações dos fabricantes de equipamento original (OEM), a manutenção do firmware e o planeamento de peças de substituição para o modelo de servidor específico. A designação da família de CPUs, por si só, não garante nem a disponibilidade nem a validação dos componentes de RAM, armazenamento e rede pretendidos.

Em seguida, compare SKUs concretas, incluindo a topologia do soquete e a plataforma do servidor. No caso do AMD EPYC 9005, devem ser verificadas a variante do núcleo, o modelo, bem como a expansão prevista para DDR5 e PCIe. A família inclui modelos Zen-5 e Zen-5c, cujas características não devem ser consideradas idênticas de forma generalizada. No caso do Intel Xeon 6, é importante distinguir, em particular, entre as variantes P-Core e E-Core, uma vez que estas visam objetivos diferentes em termos de desempenho por núcleo e densidade de núcleos.

Verifica a configuração como uma lista completa de componentes: configuração validada de DIMMs, RAM local por nó NUMA, número e ligação das unidades NVMe, placas de rede, comutadores PCIe, bem como o sistema de refrigeração e as fontes de alimentação. Um Nó de alojamento EPYC-9005 É óbvio quando uma configuração concretamente disponível oferece a combinação exigida de núcleos, canais de memória e E/S. Trata-se de uma avaliação da adequação da SKU e da plataforma de servidor selecionadas, e não de uma vantagem geral em termos de desempenho face ao Intel Xeon.

Um servidor Intel Xeon 6 com núcleos E pode ser uma opção plausível para muitas cargas de trabalho bem delimitadas e independentes. Os modelos com núcleos P são mais indicados quando aplicações específicas necessitam de elevado desempenho por núcleo ou quando são relevantes funções vetoriais e matriciais adequadas. A Intel refere o AVX-512 e o AMX para os núcleos P do Xeon 6; no entanto, a utilidade destas funcionalidades depende do software utilizado e da sua implementação concreta.

Antes de efetuar a encomenda, realize um teste reproduzível com as suas próprias imagens, configurações e volumes de dados realistas. Registe, além do número de pedidos por segundo, também a taxa de erros, os percentis de tempo de resposta, os tempos de espera da base de dados, as latências de armazenamento e o comportamento em caso de cópias de segurança paralelas ou falhas. São necessárias informações completas sobre o hardware e o software, para que as decisões posteriores sejam compreensíveis.

A Operação piloto É aconselhável quando a densidade de clientes prevista, novas funcionalidades do hipervisor, um design NVMe pouco habitual ou os custos energéticos influenciam significativamente o cálculo. Para tal, utilize um grupo limitado e representativo de clientes ou um grupo de teste com limites de recursos bem definidos. Só após a observação dos picos de carga, das reservas de capacidade e dos processos operacionais é que as projeções, as aquisições e a implementação podem ser fundamentadas tecnicamente.

Fontes e estado atual dos conhecimentos

Estado da pesquisa:

Versão técnica: 24 de setembro de 2026. Este artigo compara exclusivamente o AMD EPYC 9005 e o Intel Xeon 6; as informações relativas a outras gerações e linhas de produtos devem ser verificadas separadamente. A apresentação do produto, as SKUs de CPU disponíveis e os sistemas de servidor efetivamente adquiríveis e validados não são equivalentes. As informações relativas a canais, pistas PCIe e funcionalidades de segurança dependem sempre do modelo e da plataforma. Nota sobre a fonte: No PDF do EPYC 9005 da S2, o título dos metadados do PDF incorporado pode aparecer como „AMD EPYC 4004 Series Processors“; a URL inalterada e o conteúdo visível do documento referem-se ao AMD EPYC 9005.

https://www.intel.com/content/www/us/en/products/docs/xeon-6-product-brief.html

https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/datasheets/amd-epyc-9005-series-processor-datasheet.pdf

https://www.spec.org/cpu2026/docs/runrules.html

https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/user-guides/58462_amd-epyc-9005-tg-architecture-overview.pdf

https://docs.amd.com/api/khub/documents/UIqhAbjRhgnzgzzdVU4pUw/content

https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/03/hardware_selection/

Artigos actuais

Plataforma de servidor abstrata com percursos de dados para a RAM, NVMe e rede, destinada a diferentes cargas de alojamento.
Servidores e Máquinas Virtuais

AMD EPYC ou Intel Xeon: escolher a plataforma certa para o alojamento web

Não é possível avaliar de forma generalizada os processadores AMD EPYC 9005 e Intel Xeon 6 para alojamento web. Os fatores decisivos são o modelo de alojamento, o SKU específico, a topologia de RAM e de E/S, a disposição NUMA, bem como medições realizadas com uma carga representativa.

Representação abstrata de um servidor de alojamento com fluxos de dados para memória, CPU, isolamento e manutenção.
Tecnologia

Kernel do Linux 6.x: Novidades relevantes para servidores de alojamento

Quais as funcionalidades do kernel Linux 6.x que podem ser relevantes em situações de pressão na memória, concorrência na CPU, isolamento de processos e manutenção – e como os administradores podem avaliar de forma rigorosa a disponibilidade e os limites.

Distribuição centralizada de patches com grupos escalonados para diferentes servidores de alojamento
Segurança

KernelCare ePortal para infraestruturas de alojamento de maior dimensão

O KernelCare ePortal centraliza a distribuição e a aprovação de patches em tempo real em grandes frotas Linux. O artigo explica em que situações vale a pena utilizar esta plataforma adicional e como gerir de forma controlada os anéis de patches, o espelhamento, a replicação e os controlos de segurança.