Più core della CPU vs dischi più veloci

Faccio parte di una piccola azienda, quindi come al solito ricopro una serie di ruoli diversi. L'ultima delle quali sta procurando un box SQL Server dedicato per la nostra app Web .NET. Siamo stati citati su una doppia CPU Xeon E5-2620 (sei core) da 2,00 GHz (12 core in totale), con 32 GB di RAM. Questo ci ha lasciato con un budget limitato per l'array di dischi, che consisterebbe essenzialmente in due unità SAS da 300 GB da 2,5 "(15k RPM) in una configurazione RAID 1.

So che l'installazione del disco non è ottimale per SQL Server e mi piacerebbe davvero spingere per RAID 10 in modo da poter mettere il database, i file di registro e il tempdb sulle proprie unità. Per renderlo compatibile con il nostro budget, dovrei considerare di ridurre il numero di core della CPU? o potrei ottenere una banca migliore per mantenere i core e utilizzare meno unità, forse 4 in una configurazione RAID 1 doppia?

Ecco alcune statistiche aggiuntive

• Il database di SQL Server è inclinato verso un numero elevato di letture in scrittura, probabilmente rispettivamente 80% vs 20%. L'attuale dimensione del DB è attualmente di circa 10 GB 26 GB, con una crescita di 250 MB al mese.

• Attualmente in esecuzione su SQL Server 2008 R2 Standard su una singola scatola Xeon quad core condivisa con il web server (12 GB di RAM, 2 unità SAS da 10 k 300 GB in RAID 1), cercando di passare a SQL Server 2012 Standard.

• Il database serve circa 100-150 utenti simultanei con alcune attività di pianificazione in background inserite. Leggendo questo, sto pensando che 12 core sono davvero eccessivi!

Ho distribuito l'intera applicazione in un servizio cloud di Azure (2 piccole istanze) collegato a un database SQL Azure. Sebbene le prestazioni fossero ragionevoli durante i test (carico quasi zero), ho perso il coraggio di usarlo in produzione a causa dell'imprevedibilità di cui avevo letto così tanto. Potrebbe funzionare meglio con un approccio scalabile, ma con solo un database da 10 GB posso probabilmente cavarmela con il ridimensionamento in questo momento e risparmiare un po 'di denaro.

Inizialmente ho trascurato i costi delle licenze e non mi rendevo conto che le licenze di SQL Server 2012 si basano sul numero di core. Ho un abbonamento BizSpark MSDN con una licenza SQL Server 2012 Standard, quindi dovrei leggere su quanti core questo userebbe immediatamente.

Parlando per esperienza che è modesta ma penso che valga la pena condividerla, il principale collo di bottiglia con i database SQL (Sybase e SQL server qui) è lo storage.

Ma penso sia giusto che qualcuno prima faccia un benchmark della propria configurazione prima di fare ipotesi sbagliate. Nel mio caso, l'utilizzo della CPU non è mai aumentato abbastanza da giustificare l'aggiornamento della CPU in qualunque momento presto. Invece, ho aggiornato da un singolo disco a RAID 1 e poi a RAID 10 + un bump da 8 GB a 16 GB di RAM.

Tutti questi aggiornamenti RAID hanno contribuito a ridurre i tempi di attesa precedenti di un fattore da 2 a 6. Sospetto che l'aggiornamento a SSD sarebbe ancora migliore. Se ci pensate, può essere tutto ridotto alla larghezza di banda (teorica). La tua combinazione [(Velocità RAM + Dimensione RAM + Controller memoria) alla CPU] ha un limite di larghezza di banda che sarebbe il fattore più importante nelle operazioni di lettura quando i tuoi dati dovrebbero essere sempre memorizzati nella cache, il tuo particolare spazio di archiviazione (RAID) ha un limite di larghezza di banda ( influisce sulle letture in caso di perdita della cache e sulle scritture durante lo svuotamento o quando molti client scrivono molti dati combinati).

Normalizza tutti i limiti il ​​più possibile (avvicinali in modo da non avere risorse sprecate) e aumentali il più possibile (aggiorna dove necessario e solo se necessario, non lasciare che le risorse vengano sprecate se il sistema ha vinto ' essere in grado di usarli perché sono presenti altri colli di bottiglia). Alla fine, il tuo peggior collo di bottiglia sarà il sottosistema server meno performante (con meno larghezza di banda) nella tua particolare configurazione.

Potrei anche aggiungere che, durante il processo di aggiornamento, ho creato configurazioni RAID separate per i file di database e i file di registro del database. Il motivo era che i file di registro del database tendono ad essere ad alta intensità di scrittura. Un file di registro viene utilizzato per ripristinare un database da un arresto anomalo ed è sempre scritto immediatamente quando viene eseguita una transazione prima che qualsiasi dato venga scritto nel file di database.

Un file di registro viene utilizzato anche da alcuni server di replica del database, ma la maggior parte della replica non viene eseguita immediatamente ma frequentemente, quindi l'impatto sulle prestazioni di lettura è minimo qui. Almeno credo. Ho eseguito un benchmark minimo durante l'aggiornamento, quindi consiglio a chiunque di confrontare prima le loro diverse configurazioni e prima di tutto l'archiviazione, quindi la RAM e il collegamento di rete, prima di pensare di aggiornare le loro CPU.

Dopo aggiornamenti più estesi su più di 5 server, sono tornato per condividere la mia esperienza. Sicuramente sostengo ancora prima di aggiornare l'archiviazione, quindi la RAM e poi la CPU. Il motivo è la disparità delle larghezze di banda nel sistema tra memoria, RAM e CPU, in ordine dal più basso al più alto. Quindi ho aggiornato un sacco di server da RAID10 e doppi RAID1 a SSD.

Il modo in cui l'ho fatto per motivi di costi (ho 20 server in più da aggiornare) è spostare i dati del database e i file degli oggetti su un SSD (sì, solo un SSD in RAID0) e spostare il registro delle transazioni più tempdb su un RAID10 4xHDD configurazione. Ho provato anche con tempdb su SSD con grandi risultati (in effetti risultati molto belli con query più di 15 volte più veloci a volte, producendo alcuni report che richiedevano secondi invece di minuti in passato) ma in seguito ho spostato tempdb sul disco RAID10 perché di gravi problemi di usura da scrittura per l'SSD.

Quindi ora sostanzialmente ho osservato tempi di risposta 10-15 volte più veloci per alcune delle query più lunghe. L'SSD è ottimo per leggere rapidamente i dati nella RAM perché SQL Server non porta i dati nella RAM fino a quando non viene richiesto e, naturalmente, i dati devono prima essere caricati nella RAM per essere elaborati dalla CPU (in seguito, nella cache L1, L2, L3) , quindi gli SSD aiutano a ridurre di molto il tempo di attesa iniziale. E gli SSD aiutano anche a ridurre i tempi di scambio ... svuotando la RAM e caricando nuovi dati, specialmente se il tuo database è più grande di quanto possa adattarsi alla RAM.

Tutto sommato, siamo molto soddisfatti e abbiamo funzionato così per diversi mesi in una sorta di lento processo di migrazione per consentire ai server di funzionare in modo che io possa raccogliere informazioni sul livello di usura prima di passare tutti i miei server a questa configurazione. E questo è solo SQL Server Express! : D - Assicurati solo che i tuoi SSD possano fornire IOPS costanti perché è un'altra cosa che fa una grande differenza (basta cercarlo su Google). Ecco perché ho scelto SSD serie Intel DC (DataCenter).

In qualche modo non è la risposta che probabilmente stai cercando nella prima parte, ma: hai mai pensato di trasferirla nel cloud? AWS potrebbe consentirti di soddisfare la maggior parte delle esigenze di cui sopra ed estendere il tuo potere d'acquisto senza dover gestire anche l'hardware.

Seconda parte: l'hardware dipende davvero dalle attività. Tendo a inclinarmi verso più CPU quando sono in grado di eseguire l'integrazione CLR personalizzata, perché in questo modo posso ottimizzare soluzioni veramente parallele ai problemi. Il più delle volte, però, se è meglio avere soluzioni basate su set, trovo che la RAM e la velocità del disco rigido siano il maggiore collo di bottiglia, e il secondo sembra essere il tuo caso. (Dove l'idea SSD sopra sarebbe utile)

Senza statistiche reali dal tuo server, ti suggerirei di esaminare alcune soluzioni di memorizzazione nella cache per ridurre le scritture, (a meno che tu non stia facendo una sorta di registrazione con le scritture o cose che richiedono una cronologia) e mettendo molti più soldi nei tuoi hard disk rispetto alla CPU. Il server SQL è abbastanza bravo ad andare in parallelo sulle query (se sono scritte per questo) ma se sei pesante nelle scritture, il tuo disco rigido è il vero collo di bottiglia.