Considerazioni sulla scelta dei processori AMD su Intel


13

Lavoro per un'azienda con molte applicazioni web LAMP legacy, dove stiamo cercando di aggiornare il nostro hardware da ~ 250 server fisici a ~ 40 nuovi server con virtualizzazione. Abbiamo ricevuto due preventivi dai fornitori: uno suggerisce i processori Intel, l'altro AMD.

Una cosa che mi piace dell'elevato numero di core con AMD è che saremo in grado di dedicare core alle VM, il che significa che abbiamo meno possibilità che le applicazioni interferiscano tra loro a causa di picchi, che in una certa misura è maggiore importante per me delle massime prestazioni.

Le altre considerazioni che ho in mente sono:

  • Il consumo di energia potrebbe essere diverso (non è un problema nel nostro caso).
  • Le istruzioni della CPU come CRC32 (SSE 4.2) non saranno supportate (Modifica: MySQL 5.6 sembra supportare SSE4.2. Non sono sicuro di Apache)
  • MySQL non si adatta perfettamente dopo ~ 16 / ~ 32 core (sono disposto ad accettare questo trade off).

Quali altre considerazioni mi mancano?

(Nota per i moderatori: sono a conoscenza di questo thread - considero la domanda leggermente diversa.)


Modifica: supponiamo che le attività siano eccezionalmente parallele (server Web) e che non mi interessi che i server di database non siano così paralleli.



Se l'applicazione è in grado di suddividere le letture / query di query in pool di server diversi, è possibile aggirare alcuni dei problemi di prestazioni di MySQL eseguendo una seconda istanza per cui le letture slave vengono disattivate. Non so abbastanza della tua architettura o del tuo carico di lavoro per sapere se questa è un'idea realizzabile o se ciò aggiungerà solo un sacco di spese generali e complessità inutili, ma è un'opzione da considerare.
jgoldschrafe,

Conosco bene come funziona la divisione lettura / scrittura. In questo caso non è adatto per un miglioramento delle prestazioni.
Morgan Tocker,

Risposte:


10

C'è stata una buona quantità di stampa riguardo all'ultima offerta di processori AMD, chiamata Bulldozer. La versione "Server" di questa parte non è ancora disponibile, ma l'offerta desktop offre un'ottima vista su alcuni dei potenziali problemi delle novità.

Per quanto riguarda l'attuale generazione della parte Server, nel complesso la raccomandazione è abbastanza buona a livello generico. Il lavoro sul Web e (la maggior parte) del database è in gran parte basato su Integer e le CPU AMD funzionano bene con il calcolo di Integer. Inoltre, il servizio web è (genericamente) un problema che può essere fortemente parallelizzato. AMD si sta concentrando piuttosto specificamente su "molti core rendono il lavoro più veloce", e LAMP (di nuovo, genericamente) tende a rispondere bene a questo.

Un'area a cui devi davvero prestare attenzione sono le dipendenze a thread singolo nelle tue applicazioni. Le parti AMD non si ridimensionano in senso orario quanto le parti Intel, quindi i processi che sono fondamentalmente a thread singolo possono strozzare il sistema in generale molto più rapidamente di quanto non farebbe con parti della CPU più veloci. Solo tu sai se questo si applica a te o no. Alcune operazioni di database potrebbero essere gestite meglio da processori Intel più veloci con un numero inferiore di core, in modo che quei pochi thread fatali possano davvero urlare.

Anche qui il codice dell'applicazione conta. Alcuni processi di server Web di lunga durata potrebbero richiedere molto tempo a thread singolo e vorrebbero anche un clock più veloce. Ciò può essere risolto riscrivendo la necessità di quel lungo processo, ma fino ad allora un orologio più veloce sarebbe bello.

Ma in generale, per i carichi di lavoro in stile lotti-o-server-web-VM, quelle parti a 12 core possono scalare piuttosto male. Se si verificano problemi con un singolo thread, andare con le parti a 8 core con clock superiore sarebbe un compromesso accettabile.


Grazie, sfortunatamente il sistema AMD non sarà un bulldozer. È un AMD Opteron 6140 (o simile).
Morgan Tocker,

@MorganTocker A quanto pare, ho familiarità con quella classe di CPU, ed è per questo che ho scritto il mio post. Il bulldozer ha alcuni problemi specifici in cui non sono entrato.
sysadmin1138

4

Per la maggior parte, entrambi i processori sono molto simili. I processori AMD hanno un leggero vantaggio nelle velocità della RAM (di solito) a causa del 4 ° canale. I processori Intel hanno generalmente un CPI inferiore (forse di più con HT , anche se dipende molto dal carico di lavoro). AMD sono generalmente più economici.

La maggior parte di questi fattori darà un vantaggio all'uno o all'altro, a seconda del carico di lavoro. Nessuno dei due sarà significativamente peggiore dell'altro (presupponendo configurazioni sane e CapEx approssimativamente uguale).


2

È necessario considerare le differenze di prestazioni che può comportare la diversa architettura RAM e se questo è o meno un fattore decisivo per la propria organizzazione.

Inoltre, come nota a margine, mentre potresti non preoccuparti delle massime prestazioni, se le VM non avranno più core ciascuna e / o attività specifiche all'interno sono a thread singolo, c'è un notevole vantaggio in termini di prestazioni negli core di AMD, anche se il conteggio totale dei core è inferiore.


Supponiamo che le nostre applicazioni siano opportunamente multi-thread (i server web sono; disposti ad accettare che MySQL non sia del tutto).
Morgan Tocker,

2

La differenza principale è nell'approccio; nella fascia media, AMD ha una leggera enfasi sui core in una parte che costa circa quanto una parte Intel simile. La parte Intel avrà meno core con un clock più alto.

Quindi, per i carichi di lavoro di app Web virtualizzati, probabilmente vorrai favorire i sistemi AMD.

A meno che non ci sia una grande differenza di prezzo, non mi preoccuperei dei dollari. Guarderei di più al sottosistema IO. E, il TCO su 40 server sarà principalmente supporto, licenze software, se presenti, e personale, probabilmente non i server stessi.

Come minimo, devi fare un favore a te stesso, attirare entrambi i fornitori ed eseguire i tuoi sistemi sul loro hardware prima di eseguire il commit su 40 server da uno di essi. Solo tu puoi rispondere correttamente alla domanda per il tuo carico di lavoro specifico.


La ringrazio per la risposta! Non abbiamo un carico di lavoro, ne abbiamo diversi. Quindi, per attirare il fornitore, dovremmo migrare completamente e quindi migrare nuovamente per provare entrambi. Mi rendo conto che è l'ottimale, nel nostro caso non è pratico. Possiamo scegliere un numero inferiore di ruoli da spostare e proiettare, ma per farlo dobbiamo sapere cosa dovremmo misurare / cercare; da qui la mia domanda;)
Morgan Tocker,

Per carico di lavoro, intendo dire che hai un carico di lavoro COMPLETO costituito da (presumibilmente) molti server diversi che fanno cose diverse. Dovresti essere in grado di convertire un sottoinsieme di server chiave in immagini virtuali al giorno d'oggi abbastanza facilmente (con software che può aiutare questo) che può essere caricato sui server che stai per acquistare. Non un compito trascurabile, ma l'unico modo per essere sicuri che non solo la CPU, ma il sottosistema IO e tutto il resto funzionino a tuo favore. Altrimenti, tutti rinunciano e indovinano a mano. :)
alphadogg,

1

Un'altra cosa da lanciare lì, attenzione se si utilizza la virtualizzazione di qualsiasi tipo che la migrazione degli ospiti da Intel a AMD può essere un vero problema e il clustering tra i marchi non è affatto nelle carte. Attenersi a una piattaforma per ciascun cluster e accettare che è difficile saltare da uno all'altro.


La migrazione in tempo reale
Ophidian,

L'utente ha detto "LAMPADA legacy"; che puzza di essere ospiti a 32 bit per me. Tuttavia, è bello sapere che KVM sta affrontando il problema! Grazie per la nota.
Segna il

Sì, alcuni ospiti sono a 32 bit, ma prevediamo di spostarci e di essere tutti a 64 bit.
Morgan Tocker,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.