L'upgrade CPU su socket esistente è uno degli interventi più sottovalutati: in molte famiglie (Xeon Scalable Gen1→Gen2, EPYC Rome→Milan) è possibile passare a SKU di generazione successiva senza cambiare motherboard, guadagnando 20-50% di performance per processo. Ma serve verifica precisa: microcode BIOS, headroom termico, alimentazione PSU, compatibilità RAM channel.
Monitoring mostra CPU costantemente 80-100% in run queue, latenza applicativa correlata al carico, throughput plafonato. La motherboard ha headroom socket per SKU più alta della stessa famiglia. ROI tipico: 6-12 mesi rispetto a un cluster scale-out.
Generazione successiva sullo stesso socket introduce feature mancanti: AVX-512 su Skylake→Cascade Lake, AVX2/SSE4 sui sistemi più vecchi, virtualization extension SR-IOV, AMD SEV. Se l'applicazione ne beneficia, vale la spesa.
Su cluster vSphere/Hyper-V con vincoli di rack space, l'upgrade core/SKU fa salire la densità VM per host. Costa frazione di un nodo nuovo se la motherboard regge, e mantiene la topologia di cluster esistente.
L'upgrade CPU non è "metto la nuova e via". Servono verifiche tecniche puntuali. Se manca anche solo una di queste, il sistema può fare POST fail, funzionare in modalità degraded, o danneggiare la nuova CPU.
La motherboard riconosce la CPU dal microcode incluso nel firmware BIOS. Ogni CPU ha un CPUID univoco; il BIOS sa come comunicare con i CPUID che conosce. Aggiornamento BIOS sempre alla versione più recente prima dello swap. Su sistemi EOL questo è il primo blocco: vendor che non rilascia più BIOS può rendere impossibile upgrade su CPU recenti.
Stesso socket meccanico ed elettrico. LGA 3647 (Xeon Scalable Gen1/Gen2), LGA 4189 (Gen3/Gen4 Ice Lake), LGA 4677 (Sapphire Rapids). Per AMD: SP3 (EPYC Rome/Milan), SP5 (Genoa/Bergamo). Anche se il socket fisico è uguale, varianti elettriche (es. socket "P" vs socket "P+") possono creare incompatibilità — verifichiamo sempre l'HCL del vendor.
Passare da CPU 105W a 165W o 205W richiede dissipatore performance (non standard) e budget termico del case rivisto. Sui PowerEdge esistono dissipatori "standard" e "performance/heatpipe"; HPE ProLiant idem; Lenovo ThinkSystem standard e high-performance. Senza dissipatore corretto la CPU va in thermal throttling continuo, vanificando l'upgrade.
2× CPU 205W + RAM 16 DIMM + 4× NVMe + 2× GPU può andare oltre il budget di PSU 1100W. Calcoliamo il power draw atteso e verifichiamo che le PSU installate (e la combinazione attiva, considerando ridondanza) reggano. Su sistemi che vanno verso il limite serve passare a PSU di taglio superiore (es. 1600W).
Salti di generazione possono cambiare il numero di canali di memoria supportati o aggiungere supporto a frequenze RAM più alte. Esempio: Xeon Scalable Gen3 supporta DDR4-3200 contro 2933 di Gen2. La RAM esistente potrebbe non beneficiare del salto, e in alcuni casi va aggiornata in parallelo.
Su sistemi 2-socket le due CPU devono essere stepping identico per garantire stabilità e prestazioni nominali. Mescolare stepping diversi della stessa SKU spesso funziona ma fa rifiutare il sistema a certi BIOS o crea micro-instabilità sotto stress. Su contratti acquistiamo coppie matched.
Rileviamo modello server esatto, motherboard part-number, BIOS attuale, CPU correnti, dissipatori installati, PSU. Confrontiamo con la HCL (Hardware Compatibility List) ufficiale del vendor per identificare la CPU candidata sostenibile.
Aggiornamento BIOS all'ultima versione che supporta la CPU target. Su Dell via Lifecycle Controller, su HPE via Service Pack for ProLiant (SPP), su Lenovo via XClarity. Verifichiamo che il microcode CPU corretto sia presente.
Server spento, capacitor discharge, rimozione dissipatore esistente, pulizia con isopropanolo, posa nuova CPU rispettando orientamento, applicazione pasta termica di qualità (Arctic MX-6, Noctua NT-H2), riposizionamento dissipatore (performance se TDP superiore), serraggio torque-controlled.
Primo boot per memory training prolungato (può durare 5-10 min su sistemi multi-socket grandi). Verifica POST clean, controllo CPU rilevata correttamente, frequenze nominali, ECC enabled, NUMA topology corretta. SEL azzerato.
Stress test sotto carico (stress-ng, Linpack, mprime) per 1-2 ore. Monitoriamo temperature CPU, package power, frequenze sostenute, eventuali correctable error. Riconsegna con report scritto e baseline pulita per il monitoring continuativo.
Cliente studio professionale area Milano, cluster Proxmox VE a 5 nodi PowerEdge R740. Configurazione iniziale: 2× Xeon Silver 4114 (10c/20t, 2.2 GHz base, 85W TDP) per nodo. Workload: virtualizzazione mista (terminal server, file server, gestionale, mail). Bottleneck CPU evidente: utilizzo medio 75-85% durante orario lavorativo, picchi 95% costanti su 2-3 nodi specifici.
Decisione: stessa famiglia LGA 3647 ammette il salto a Gen2 (Cascade Lake). Identificata SKU sostitutiva: 2× Xeon Gold 6240R (24c/48t, 2.4 GHz base, 165W TDP) per nodo. Vincoli da verificare: TDP più alto richiede dissipatore performance (presente già su PowerEdge R740 standard), PSU 1100W standard reggono con margine. BIOS aggiornato a 2.x recente. RAM esistente DDR4-2666 mantenuta (Gold 6240R supporta 2933 ma DDR4-2666 lavora senza problemi).
Esecuzione: 5 finestre serali (una per nodo), HA Proxmox sposta automaticamente le VM sul nodo da spegnere agli altri 4. BIOS aggiornato → spegnimento → swap CPU + ri-pasta termica → boot → stress test 1h → reintegrazione cluster. Zero downtime applicativo.
Risultato: utilizzo CPU medio sceso al 35-45%, headroom per 50-70% di VM aggiuntive nel medio termine.
Sì, se la nuova CPU è dello stesso socket fisico e supportata dal microcode BIOS. Esempi tipici: passare da Xeon Scalable Gen1 (Skylake) a Gen2 (Cascade Lake) sui sistemi che supportano LGA 3647 con BIOS aggiornato; EPYC Rome a Milan sullo stesso SP3. Su Xeon E5-2600 v4 si può salire a SKU più alti della stessa generazione. La motherboard deve avere il BIOS recente abbastanza.
Dipende dal salto SKU. Tipicamente 20-40% in più di throughput per workload multi-thread se si sale da una SKU media a una high-end. Su single-thread il guadagno è più modesto perché la frequenza turbo cambia poco. Su workload database SQL/PostgreSQL il salto può essere consistente per via dell'aumento di cache L3. Su workload virtualizzazione il guadagno è proporzionale al numero di core.
Sì, sempre. Il BIOS contiene il microcode che dice alla motherboard come parlare con la CPU. Mettere una CPU di generazione nuova su un BIOS che non la conosce dà POST fail o boot con feature ridotte. L'ordine è: aggiornare BIOS all'ultima versione che supporta la nuova CPU → spegnere → swappare CPU → boot. Su HPE ProLiant l'aggiornamento iLO+BIOS è separato; su Dell il Lifecycle Controller fa tutto.
Sì se il sistema termico esistente non lo regge. Passare da una CPU 105W a una 165W richiede tipicamente: dissipatore performance (non standard), curve fan rivisitate, verifica del budget elettrico PSU. Su PowerEdge R740 con dissipatore standard la massima TDP supportata è limitata. Su HPE DL380 idem. Verifichiamo sempre prima di proporre l'upgrade.
Su sistemi enterprise multi-socket le due CPU devono essere identiche per stepping, frequenza, cache. Mescolare non è supportato; in alcuni BIOS rifiutato del tutto, in altri funziona ma con performance asimmetriche e NUMA squilibrato. Su contratto preferiamo sempre upgrade in coppia o nessun upgrade. Se il budget è limitato meglio una sola CPU più potente che mezza coppia upgradata.
Molte licenze enterprise sono per-core o per-socket (Windows Server, SQL Server Enterprise, alcune licenze Oracle). Aumentare i core può aumentare i costi di licensing in modo significativo. È un calcolo che facciamo insieme prima dell'upgrade: a volte la SKU intermedia è economicamente migliore della top-of-line per via del licensing.
Inviami brand, modello (Service Tag / Serial / part number motherboard), workload obiettivo. Entro un giorno lavorativo ti rispondo con la fattibilità tecnica, i vincoli che ho visto e una stima onesta.