...

AMD EPYC o Intel Xeon: scegliere la piattaforma giusta per il web hosting

Per quanto riguarda il web hosting, non esiste un vincitore assoluto tra AMD EPYC e Intel Xeon. La piattaforma adeguata si adatta al profilo di carico: Nel shared hosting contano la densità dei core e i limiti, mentre nelle applicazioni dinamiche è importante la prestazione per worker attivo; i nodi VPS e di database, invece, richiedono soprattutto RAM, layout NUMA e topologia I/O. Confronta quindi modelli specifici di EPYC 9005 e Xeon 6, insieme alla piattaforma server, sulla base di misurazioni riproducibili anziché in base al numero di core, alla frequenza di clock o a singoli benchmark.

Profili di hosting prima del confronto delle prestazioni della CPU

Il web hosting non rappresenta un carico di lavoro uniforme per la CPU. Una piattaforma che ospita migliaia di piccoli account segue regole diverse rispetto a un nodo per macchine virtuali o a un server di database. Prima di confrontare AMD EPYC e Intel Xeon, è quindi necessario definire il profilo delle richieste, il numero di client attivi contemporaneamente, il fabbisogno di RAM, l’I/O di storage e i tempi di risposta accettabili. Solo questa combinazione rende significativi i dati tecnici di una CPU ai fini dell’acquisto.

hosting condiviso elabora numerose attività PHP, CMS e di posta elettronica indipendenti l'una dall'altra, spesso caratterizzate da brevi picchi di carico. Un'elevata densità di core può essere d'aiuto, ma è altrettanto importante stabilire limiti efficaci per il tempo di CPU, i processi, la memoria e l'I/O. Senza tali limiti, un singolo account può occupare risorse limitate e peggiorare i tempi di risposta degli altri clienti. In questo caso, una separazione pianificabile dei clienti conta spesso più di un valore di picco in un test multicore sintetico.

Nel caso dei CMS e degli shop gestiti, i requisiti sono più eterogenei. Richieste PHP dinamiche, cache degli oggetti, interrogazioni del database, cron job e accessi amministrativi si verificano talvolta contemporaneamente. Per alcune applicazioni particolarmente esigenti è possibile Prestazioni per core può essere più importante del numero massimo di core; quando si hanno molti worker PHP-FPM indipendenti in modo permanente, invece, la parallelizzazione assume maggiore importanza. Ciò che rimane determinante è che il server web, i processi PHP e il database siano dimensionati in modo adeguato.

Un negozio WooCommerce illustra chiaramente questa distinzione: un server web dotato di cache è in grado di fornire in modo molto efficiente le immagini statiche dei prodotti. Il carrello, il checkout e le disponibilità di magazzino, invece, generano esecuzioni PHP personalizzate e accessi al database. Un numero maggiore di core della CPU non elimina i tempi di attesa se le query non trovano gli indici, il buffer pool è troppo piccolo o la latenza NVMe aumenta sotto carico. Pertanto, la latenza delle richieste, i tempi di risposta del database e i tempi di attesa I/O dovrebbero essere misurati separatamente.

I nodi VPS e cloud, oltre alla potenza di calcolo, necessitano soprattutto di RAM sufficiente, larghezza di banda di memoria, rete e una distribuzione delle risorse trasparente. Il CPU-pinning, la memoria riservata, l’assegnazione NUMA e lo Storage-QoS influenzano l’esperienza degli utenti in misura maggiore rispetto al logo del produttore. I sistemi legati a database, Redis e storage valutano inoltre il working set, la dimensione della cache, il carico di scrittura e il collegamento diretto agli SSD NVMe. In questo caso è importante un equilibrio Topologia della piattaforma spesso più determinante rispetto al semplice valore di throughput di un server web.

Inserire EPYC 9005 e Xeon 6 come termine di paragone

Questo articolo mette a confronto, in modo mirato, AMD EPYC 9005 e Intel Xeon 6 come generazioni di piattaforme chiaramente distinte. Il confronto è finalizzato all’acquisto, all’espansione o alla valutazione di sistemi basati su queste due famiglie di prodotti. Da esso non è possibile trarre conclusioni relative ad altre generazioni o linee di prodotti, poiché la struttura dei core, la piattaforma di memoria, le dotazioni I/O e le funzioni disponibili possono variare.

Una funzione del processore documentata deve inoltre corrispondere effettivamente a una sistema server disponibile da distinguere. Scheda madre, firmware, configurazione DIMM, raffreddamento, alimentatori e approvazioni OEM determinano quali configurazioni sono effettivamente utilizzabili. Verifica quindi, per ogni SKU specifica, quali modelli di server sono disponibili e convalidati per la configurazione prevista. Ciò vale in particolare per elevate capacità di RAM, numerose unità NVMe e funzioni di virtualizzazione speciali.

Le generazioni precedenti di EPYC 700x e i modelli precedenti di Xeon Scalable non devono essere confusi con EPYC 9005 o Xeon 6. Allo stesso modo, non si dovrebbero applicare a queste famiglie i dati relativi ad altre linee di prodotti. La struttura dei core, le dotazioni I/O, la piattaforma di memoria e le funzionalità disponibili possono variare da una generazione all’altra. Per un confronto tra le opzioni di acquisto è quindi sempre necessario disporre della denominazione completa del modello, del numero di socket e della scheda madre del server utilizzata.

La serie EPYC 9005 comprende, a seconda del modello, processori con Zen 5– o core Zen-5c. Queste denominazioni non indicano una classifica generale per l’hosting. Sono invece rilevanti lo SKU specifico, il numero di core, la frequenza di clock, i requisiti termici e il livello di parallelismo previsto. Una variante con molti core può essere adatta a numerosi tenant ben delimitati, mentre un modello con caratteristiche diverse può risultare più indicato per un numero minore di applicazioni ad alta intensità di calcolo.

Intel suddivide la linea Xeon 6 in varianti con P-Core ed E-Core. I P-Core sono progettati per garantire elevate prestazioni per singolo core e supportano, tra l’altro, AVX-512 e AMX. Ciò può risultare rilevante qualora il software utilizzato sfrutti effettivamente queste funzioni vettoriali o matriciali; un normale stack PHP o di server web non ne trae automaticamente vantaggio. Gli E-Core, invece, puntano a un’elevata densità di core e a un throughput parallelo.

Per i carichi di lavoro condivisi o cloud molto intensi e ben isolati, i core Xeon 6-E possono quindi essere presi in considerazione. Anche i core Xeon 6-P o i modelli EPYC 9005 opportunamente configurati sono candidati ideali per carichi di lavoro che richiedono una maggiore potenza per singolo core. Si tratta di una classificazione dell’orientamento del prodotto, non di una garanzia di prestazioni. L’espansione della RAM, il firmware e la configurazione software possono influenzare in modo significativo il risultato e falsare un confronto tra i tipi di core senza una configurazione identica della piattaforma.

I semi sono solo uno dei fattori

I core della CPU esprimono appieno il loro potenziale solo se la memoria e l’I/O sono all’altezza. I canali DDR5, insieme al numero di moduli e al tipo di DIMM, determinano la larghezza di banda di memoria disponibile; la capacità della RAM, invece, limita il numero di macchine virtuali, buffer di database o cache che possono essere gestiti senza ricorrere allo swap. Le linee PCIe collegano unità NVMe, schede di rete ed eventuali acceleratori. Per l’hosting, questa catena deve essere progettata come un sistema integrato.

AMD dichiara per l’EPYC 9005 fino a dodici canali DDR5 e, a seconda del numero di socket e della piattaforma, un’ampia connettività PCIe Gen 5. Per i sistemi a socket singolo sono indicati fino a 128 lane PCIe Gen 5. Anche Intel Xeon 6 offre, a seconda della serie, fino a dodici canali DDR5; alcune configurazioni P-Core a socket singolo raggiungono fino a 136 linee PCIe. Questi valori si riferiscono ai dati relativi ai modelli e alle piattaforme e non costituiscono una garanzia delle prestazioni di un’applicazione.

Topologia schematica della piattaforma con CPU, memoria di lavoro, unità NVMe e schede di rete.
I canali di memoria e i percorsi PCIe contribuiscono a determinare se la capacità della CPU possa essere sfruttata nell’hosting.

Un nodo VPS dotato di più SSD NVMe, due schede di rete veloci e numerose macchine virtuali mette in evidenza la differenza concreta. Se le unità o le schede di rete sono collegate tramite switch PCIe, potrebbero condividere un unico uplink. Anche la ripartizione delle lane, gli slot, la biforcazione, il supporto CXL e la configurazione del firmware effettivamente abilitata sono determinati dalla scheda madre. La capacità della CPU documentata deve quindi essere confrontata con lo schema a blocchi e la convalida del server specifico.

Nei sistemi con più nodi NUMA, è inoltre fondamentale considerare dove sono assegnati la RAM, le CPU virtuali e i dispositivi I/O. Se una macchina virtuale o un database accede frequentemente alla memoria di un altro nodo, possono verificarsi latenze aggiuntive. È quindi opportuno effettuare misurazioni in condizioni di carico realistiche: il solo carico della CPU non evidenzia né colli di bottiglia nella memoria né code sullo storage o sulla rete.

Molte lane facilitano il collegamento diretto di numerosi dispositivi, ma non garantiscono né una bassa latenza del database né elevate velocità di transazione. Il controller, il firmware degli SSD, la configurazione RAID o di replica, la profondità della coda e il percorso di rete rimangono fattori determinanti. La scelta tra Hosting AMD EPYC e, nel caso di un server Intel Xeon, dovrebbe quindi tenere conto in modo altrettanto preciso dei requisiti di I/O e di memoria, oltre che del numero di core e della frequenza di clock.

Sincronizzare i carichi di lavoro con la piattaforma

La scelta non parte dal produttore, ma dalla distribuzione del carico di lavoro. Lo Xeon 6 con E-Core è in linea di massima indicato per un gran numero di attività indipendenti tra loro e ben delimitate; lo Xeon 6 con P-Core per esigenze relative a Prestazioni per core e determinate operazioni vettoriali o matriciali. L’EPYC 9005 copre inoltre diversi profili di core e di clock. Da ciò non deriva alcuna gerarchia: sono determinanti lo SKU specifico, la topologia del server e il carico applicativo misurato.

Criteri di selezione in base al carico di lavoro di hosting
Carico di lavoroCriterio principale relativo alla CPUCriterio fondamentale della piattaformaPunti di strozzatura tipiciValori di misura richiesti
hosting condivisoElevato grado di parallelismo con limiti di conto efficaciRAM per account, scheduler e limiti di I/OSingoli account consumano risorse della CPU, della RAM o dell'I/O del discoTempo di risposta p95, processi attivi, coda di esecuzione, limitazione della CPU e tempo di attesa I/O; Steal-Time solo su host virtualizzato
CMS e negozi onlinePrestazioni per ogni worker PHP attivo, oltre a un livello adeguato di parallelismoCache degli oggetti veloce, RAM del database e latenza NVMeCode PHP-FPM, query lente, errori di cachep95/p99 - Tempo di richiesta, carico dei worker, tempo di interrogazione, percentuale di hit della cache
VPS e cloudDensità di core o prestazioni garantite per ogni vCPU in base al piano tariffarioLayout NUMA, capacità della RAM, rete e QoS dello storageOverbooking della CPU, allocazione non uniforme della RAM, competizione per lo spazio di archiviazioneLatenza guest, IOPS, throughput, latenza di rete, nonché – a seconda dell’hypervisor – tempo di disponibilità della CPU, Run-Queue, Steal-Time o metriche di scheduling analoghe
Database e RedisPrestazioni della cache e della memoria, in funzione del parallelismoEspansione DDR5, affinità NUMA e connessione diretta allo storageRAM insufficiente, accessi NUMA remoti, NVMe lento o sovraccaricoLatenza delle query o dei comandi, hit del buffer pool, latenza I/O, larghezza di banda della memoria
Servizi correlati a NVMeCPU adeguata per il carico di protocollo e di testTopologia PCIe, numero di collegamenti diretti alle unità e alle schede di reteSwitch PCIe, code, limiti di rete o di replicap99 - Latenza I/O, profondità della coda, IOPS, throughput, carico di rete

Nell’hosting condiviso, un’elevata densità di core è utile solo se i limiti relativi al tempo di CPU, ai processi, alla memoria RAM e alle operazioni I/O proteggono effettivamente gli account vicini. I modelli E-Core possono quindi essere adatti ad ambienti multi-tenant fortemente parallelizzati. Anche un modello EPYC 9005 con un profilo di core adeguato può risultare idoneo. Per singole istanze di e-shop o CMS particolarmente esigenti, invece, i tempi di risposta per singolo worker e il database sono più importanti del semplice numero di core disponibili.

I nodi VPS e i servizi correlati allo storage richiedono inoltre una verifica dei Topologia I/O. L’EPYC 9005 offre, a seconda della piattaforma, ampie risorse DDR5 e PCIe 5.0; anche lo Xeon 6 offre canali di memoria e lane PCIe che variano in base alla serie e al modello. Questi dati facilitano la preselezione, ma non garantiscono né una determinata latenza NVMe né una specifica velocità di trasmissione dei dati del database. La scheda madre, la configurazione, il firmware e il percorso software rimangono fattori determinanti nella decisione.

Pianificare correttamente i benchmark della CPU per l'hosting

Il termine di ricerca benchmark della CPU per hosting porta a una semplificazione inammissibile: un risultato relativo alla CPU non descrive un’offerta di hosting. SPEC considera i risultati come quelli di sistemi completi e richiede la divulgazione dei dettagli configurativi essenziali. Per un confronto tra piattaforme, è quindi necessario testare entrambi i candidati con un numero di socket, una dotazione di memoria, uno spazio di archiviazione, una rete e un software comparabili.

Protocollo di benchmark riproducibile per piattaforme di hosting
Obiettivo del testGeneratore di carico o utensileVariabile misurataInformazioni obbligatorie sull'ambiente circostanteCriteri di esclusione
PHP-FPM e il server webCarico HTTP rappresentativo con percorsi anonimizzati e tempi di risposta realisticiRichieste al secondo, latenza p95/p99, tasso di erroreModello della CPU, RAM, NVMe, rete, sistema operativo, kernel, server web, versione PHP e pool FPMSolo risposte statiche, cache diverse o limiti diversi per i worker
Banca datiRichieste orientate all’applicazione e volume di dati definitoTempo di interrogazione, transazioni, latenza p95/p99, tempo di attesa I/OInoltre: versione del database, parametri, buffer pool, indici, dimensione dei record e modalità di replicaCache a caldo su una sola piattaforma o set di dati disomogenei
Densità dei VPSOspiti definiti con carico identico e prenotazione delle risorseLatenza guest, throughput, IOPS e, a seconda dell’hypervisor e del sistema operativo guest, tempo di disponibilità della CPU, steal time, run queue o metriche di scheduling analogheInoltre: hypervisor, sistema operativo ospite, pinning della CPU, mappatura NUMA, prenotazione della RAM e QoS dello storageDiverso tasso di overbooking, diversa topologia delle vCPU, diversa metodologia di misurazione o diverso carico di fondo dell'host

Per PHP-FPM, un elevato throughput delle richieste non è sufficiente. Una piattaforma può fornire molte risposte con un carico sintetico di breve durata e tuttavia generare valori p99 elevati in presenza di cronjob eseguiti in parallelo o di query al database lente. È quindi necessario monitorare separatamente le code di attesa, i tassi di errore e i tempi di risposta per le pagine dinamiche e quelle memorizzate nella cache. Le distribuzioni con controllo di versione aiutano a documentare in modo univoco l’applicazione e la configurazione testate. Flussi di lavoro Git nell'hosting

Nel caso dei database, è necessario documentare la dimensione dei record e lo stato della cache, poiché un test eseguito interamente in RAM mostra limiti diversi rispetto a un funzionamento con un carico elevato di operazioni di I/O. Per quanto riguarda la densità dei VPS, è determinante anche l’esperienza nel sistema ospite. Quale metrica di scheduling sia significativa dipende dall’hypervisor e dal sistema operativo ospite; il tempo di CPU Ready non deve quindi essere considerato un parametro universalmente valido. Ripeti i test di carico e registra in modo trasparente il metodo di misurazione e le eventuali discrepanze.

Verifica della configurazione e della topologia

Prima di effettuare un confronto, è necessario valutare lo stato attuale. Ciò evita che una presunta differenza a livello di CPU sia in realtà dovuta a una diversa assegnazione NUMA, a una memoria diversa o a una configurazione modificata del server web. I comandi seguenti leggono informazioni o verificano le configurazioni; non modificano né l’assegnazione delle CPU né le impostazioni dei servizi. Eseguili con le autorizzazioni richieste dal rispettivo sistema e archivia i risultati in modo protetto.

Con lscpu Si documentano il modello della CPU, le CPU logiche, il socket, i core e i nodi NUMA rilevati. numactl --hardware se lo strumento è installato, integra le CPU disponibili e la memoria per ciascun nodo NUMA. Entrambe le uscite descrivono la topologia hardware rilevata, non l’effettivo carico di lavoro in condizioni di carico di hosting.

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

L'appello nginx -T visualizza la configurazione NGINX attualmente in uso e può quindi contenere nomi host interni, percorsi di file o riferimenti a certificati. Controlla e correggi tali informazioni prima di diffondere l'output. php-fpm -tt è un esempio di verifica della configurazione; il nome del file binario e le opzioni variano a seconda della distribuzione e della versione di PHP. Verifica prima la versione disponibile localmente, invece di modificare una configurazione di produzione.

Un caso pratico relativo ai VPS ne illustra lo scopo: se le vCPU di una VM sono assegnate ai core di un nodo NUMA, ma la RAM loro riservata si trova prevalentemente sull’altro nodo, gli accessi alla memoria potrebbero subire una latenza aggiuntiva. Documentare quindi Pinning della CPU e l’allocazione della RAM. Solo in seguito sarà possibile valutare se sia necessaria un’altra piattaforma CPU o, in un primo momento, una topologia guest più coerente.

Gestire la virtualizzazione in modo sicuro e pianificabile

Nel caso delle offerte VPS e cloud, non è solo il nome del processore a determinare le prestazioni percepite. Pinning della CPU Assegna le vCPU a core fisici specifici in base alle esigenze, riducendo così le fluttuazioni nei tempi di esecuzione. Si tratta tuttavia di una scelta in termini di capacità: i core riservati in modo esclusivo non sono disponibili per una distribuzione flessibile ad altri clienti. Per i piani tariffari con potenza di calcolo garantita, tale riserva dovrebbe quindi essere inclusa nella pianificazione del carico di lavoro.

Altrettanto importante è la Affinità NUMA su sistemi multi-socket o con un numero elevato di core. Una VM dovrebbe, per quanto possibile, utilizzare core e memoria RAM provenienti dallo stesso nodo NUMA. Se accede regolarmente alla memoria di un altro nodo, i percorsi di accesso aggiuntivi possono aumentare la latenza. Pertanto, è consigliabile progettare le VM di grandi dimensioni tenendo conto innanzitutto della capacità della RAM locale e dell’allocazione dei core, anziché considerare solo la somma di tutti i core e della memoria totale.

Esempio semplificato di più domini NUMA con macchine virtuali, core CPU e memoria assegnati localmente.
I domini NUMA dipendono dal processore, dalla piattaforma e dal firmware; un’assegnazione adeguata può ridurre gli accessi remoti non necessari alla memoria.

La RAM riservata impedisce che la capacità di memoria garantita derivi esclusivamente da un sovraprenotazione ottimistica. Inoltre, limita QoS dello storage IOPS, throughput o code per ogni VM, in modo che un backup, un’importazione di database o un guest configurato in modo errato non blocchino il pool NVMe condiviso. Imposta limiti di sovraallocazione separati per CPU, RAM e storage: una quota CPU sostenibile non rende un nodo resiliente se il suo storage genera già tempi di attesa elevati durante i picchi di carico.

Per le macchine virtuali riservate, entrambe le piattaforme offrono funzionalità che vanno oltre la virtualizzazione tradizionale. AMD documenta per EPYC 9005 le tecnologie SEV, SEV-ES e SEV-SNP; SEV-SNP integra meccanismi di protezione contro specifici attacchi alle tabelle di pagina e all’allocazione della memoria. Intel descrive TDX come una tecnologia che isola il sistema operativo ospite e le applicazioni della macchina virtuale dall’host cloud, dall’hypervisor e dalle altre macchine virtuali presenti sulla piattaforma.

Tali funzionalità non rendono automaticamente più sicuri né i server AMD EPYC né quelli Intel Xeon. Per Intel TDX, è necessario verificare i processori supportati, la configurazione DIMM adeguata e la piattaforma OEM o ODM specifica; i requisiti documentati relativi alle DIMM possono variare a seconda dell’implementazione della piattaforma. Inoltre, l’utilizzabilità presuppone un’interazione coordinata tra firmware, hypervisor, kernel, sistema operativo guest e processi operativi. Verifica inoltre il ciclo di vita delle chiavi, la certificazione, il ripristino e il monitoraggio. Senza queste procedure, una funzione hardware attivata non può soddisfare pienamente i requisiti di protezione di un cliente.

Fonti di errore durante il confronto e il funzionamento

Un confronto attendibile parte da sistemi di dimensioni equivalenti. Un server a due socket non deve essere messo a confronto con un sistema a un solo socket quando la scelta di acquisto riguarda una classe di piattaforme. Per ogni test, registra il modello della CPU, il numero di socket, i core attivi, la quantità di RAM e la configurazione delle DIMM. Solo così sarà possibile stabilire se un risultato è dovuto all’architettura, a componenti hardware aggiuntivi o a una configurazione diversa.

Anche memorie e I/O non uniformi possono falsare le conclusioni. Differenze nell’assegnazione dei canali DDR5, nelle generazioni NVMe, nella configurazione RAID, nelle schede di rete o nei profili energetici del BIOS modificano in modo significativo la velocità di trasferimento e le latenze. AMD sottolinea che, per l’EPYC 9005, la configurazione I/O specifica dipende dalla piattaforma e dalla scheda madre; la capacità dell’interfaccia documentata non costituisce quindi una garanzia per l’applicazione.

Sebbene un numero elevato di linee PCIe faciliti il collegamento diretto di più unità NVMe e schede di rete veloci, non garantisce una bassa latenza del database: le code nello storage, il firmware del controller, la replica, i parametri del database e il set di lavoro nella RAM rimangono fattori determinanti. Per le architetture vicine allo storage, l’articolo integra Web hosting per piattaforme IoT la prospettiva relativa alla latenza di rete, alla segmentazione e ai percorsi di memoria.

Anche i clock boost isolati non costituiscono un benchmark per l’hosting. AMD definisce il boost massimo come la frequenza che un singolo core può raggiungere in condizioni normali di funzionamento del server; in caso di carico parallelo continuo si applicano condizioni termiche ed energetiche diverse. Pertanto, è opportuno valutare i percentili dei tempi di risposta e la velocità effettiva in condizioni di concorrenza rappresentative, anziché dedurre le prestazioni di un intero nodo da un singolo valore di frequenza.

Il TDP, infatti, non è una misura del consumo effettivo del server. Per le stime dei costi, ti servono i valori di misura dell'intero sistema con la RAM, lo spazio di archiviazione, il carico di rete e il profilo energetico selezionati. Il Comparabilità I risultati resi pubblici richiedono inoltre informazioni complete sul sistema; SPEC considera espressamente i risultati come relativi a sistemi completi, non a singoli processori.

Decidere gli acquisti in base a requisiti misurabili

Documenta innanzitutto il profilo di carico: numero e dimensioni dei clienti, concorrenza tipica e massima, percentuale di PHP o dell’applicazione, query al database, percentuale di hit della cache, RAM per istanza, nonché picchi di I/O e di rete. Da ciò non deriva una classifica astratta, bensì un catalogo dei requisiti. Solo questo potrà indicare se siano determinanti un’elevata densità di core, tempi di risposta brevi dei singoli worker o una connessione di storage particolarmente capiente.

Stabilisci quindi se intendi ampliare una piattaforma esistente, valutare sistemi usati o in magazzino oppure procurarti una configurazione server completamente nuova. Per EPYC 9005 e Xeon 6 è necessario verificare la disponibilità, le approvazioni OEM, la manutenzione del firmware e la pianificazione dei ricambi per il modello di server specifico. La denominazione della famiglia di CPU da sola non garantisce né la disponibilità né la convalida delle dotazioni desiderate in termini di RAM, storage e rete.

Confronta quindi gli SKU specifici, compresa la topologia del socket e la piattaforma server. Per l’AMD EPYC 9005 occorre verificare la variante di core, il modello e l’espansione prevista per DDR5 e PCIe. La famiglia comprende modelli Zen-5 e Zen-5c, le cui caratteristiche non possono essere equiparate in modo generalizzato. Per quanto riguarda Intel Xeon 6, occorre distinguere in particolare tra le varianti P-Core ed E-Core, poiché perseguono obiettivi diversi in termini di prestazioni per core e densità dei core.

Verifica la configurazione come elenco completo dei componenti: configurazione DIMM convalidata, RAM locale per nodo NUMA, numero e collegamento delle unità NVMe, schede di rete, switch PCIe, nonché sistema di raffreddamento e alimentatori. Un Nodo di hosting EPYC-9005 È ovvio che una configurazione concretamente disponibile offra la combinazione richiesta di core, canali di memoria e I/O. Si tratta di una verifica dell’idoneità della SKU e della piattaforma server selezionate, non di un vantaggio prestazionale generale rispetto a Intel Xeon.

Un server Intel Xeon 6 con E-Core può rappresentare un’opzione plausibile per molti carichi di lavoro ben definiti e indipendenti. I modelli con P-Core sono invece da prendere in considerazione quando singole applicazioni richiedono elevate prestazioni per core o quando sono rilevanti funzioni vettoriali e matriciali adeguate. Intel cita AVX-512 e AMX per i P-Core Xeon 6; tuttavia, l’utilità di queste funzioni dipende dal software utilizzato e dalla sua implementazione concreta.

Prima di effettuare l'ordine, esegui un test riproducibile utilizzando le tue immagini, le tue configurazioni e volumi di dati realistici. Oltre alle richieste al secondo, registra anche il tasso di errore, i percentili dei tempi di risposta, i tempi di attesa del database, le latenze di archiviazione e il comportamento in caso di backup paralleli o guasti. Sono necessarie informazioni complete su hardware e software affinché le decisioni successive rimangano comprensibili.

A Fase pilota È opportuno farlo quando la densità prevista dei mandanti, le nuove funzionalità dell’hypervisor, un design NVMe insolito o i costi energetici influenzano in modo significativo il calcolo. A tal fine, gestisci un gruppo limitato e rappresentativo di clienti o un gruppo di test con chiari limiti di risorse. Solo dopo aver osservato i picchi di carico, le riserve di capacità e i processi operativi è possibile giustificare tecnicamente le proiezioni, gli acquisti e l’implementazione.

Fonti e stato dell'arte

Stato della ricerca:

Aggiornamento tecnico: 24/09/2026. L'articolo mette a confronto esclusivamente AMD EPYC 9005 e Intel Xeon 6; i dati relativi ad altre generazioni e linee di prodotti devono essere verificati separatamente. La presentazione del prodotto, gli SKU delle CPU disponibili e i sistemi server effettivamente reperibili e convalidati non sono da considerarsi equivalenti. Le informazioni relative a canali, linee PCIe e funzioni di sicurezza dipendono sempre dal modello e dalla piattaforma. Nota sulle fonti: nel PDF relativo all’EPYC 9005 della serie S2, il titolo dei metadati del PDF incorporato potrebbe apparire come „AMD EPYC 4004 Series Processors“; l’URL invariato e il contenuto visibile del documento si riferiscono tuttavia all’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/

Articoli attuali

Piattaforma server astratta con percorsi dati verso RAM, NVMe e rete per diversi carichi di hosting.
Server e macchine virtuali

AMD EPYC o Intel Xeon: scegliere la piattaforma giusta per il web hosting

Non è possibile valutare in modo generalizzato le prestazioni di AMD EPYC 9005 e Intel Xeon 6 per l'hosting web. Sono determinanti il modello di hosting, lo SKU specifico, la topologia della RAM e dell'I/O, il layout NUMA e le misurazioni effettuate con un carico rappresentativo.

Rappresentazione astratta di un server di hosting con flussi di dati relativi a memoria, CPU, isolamento e manutenzione.
Tecnologia

Kernel Linux 6.x: novità rilevanti per i server di hosting

Quali funzioni del kernel Linux 6.x possono essere rilevanti in caso di pressione sulla memoria, competizione per la CPU, isolamento dei processi e manutenzione – e come gli amministratori possono verificare con precisione la disponibilità e i limiti.

Distribuzione centralizzata delle patch con gruppi scaglionati per diversi server di hosting
Sicurezza

KernelCare ePortal per infrastrutture di hosting di grandi dimensioni

KernelCare ePortal centralizza la distribuzione e l'approvazione delle patch live in grandi parchi di sistemi Linux. L'articolo illustra quando vale la pena utilizzare questa piattaforma aggiuntiva e come gestire in modo controllato i cicli di patch, lo mirroring, la replica e i controlli di sicurezza.