Peggior prestazioni su un nuovo server


11

Siamo stati su un server dedicato (single quad-core, 6 GB RAM) e ci stiamo spostando su un nuovo server dedicato (2x hex-core, 32 GB RAM). Entrambi sono Windows Server 2008, SQL Server 2008. Le prestazioni sul nuovo server sono leggermente peggiori rispetto al vecchio server più lento.

Durante i test, la nostra applicazione ASP.NET è più lenta del 10-20%. L'esecuzione di singole query costose con STATISTICS IO e STATISTICS TIME mostra un tempo trascorso del 10-20% maggiore sul nuovo server. Il profilo di query SQL mostra un maggiore utilizzo della CPU su query costose.

Task Manager sul nuovo server mostra sqlserver.exe che consuma 22 GB di RAM, ma i valori della CPU rimangono sempre molto bassi.

Ho aggiornato tutte le statistiche, gli indici ricostruiti o riorganizzati, ecc. I piani di esecuzione dovrebbero essere archiviati sul nuovo server a questo punto, data la quantità di test che ho fatto. Se ci sono indici mancanti (non credo ci siano) influenzano allo stesso modo il vecchio e il nuovo server. Nuovo ha un backup ripristinato degli stessi dati sul vecchio.

Mi aspettavo che le prestazioni sul nuovo server sarebbero state migliori, ma di maggiore preoccupazione è il carico. Se il vecchio server funziona meglio anche sotto carico, cosa succederà quando questo nuovo server leggermente peggiore dovrà sopportare quel carico?

Cos'altro potrei perdere qui?

EDIT: MAXDOP impostato su 6.

Il vecchio server ha SO, database e tempdb sulle stesse unità fisiche (RAID 10). In totale 4 SAS da 15k 3 Gb / s da 3,5 pollici. Il nuovo server ha tre set di unità: sistema operativo su RAID 1, database su RAID 10, tempdb su RAID 5. Totale di SAS 15 15K 6 Gb / s da 2,5 pollici.

Il vecchio server ha 1 x thread Intel Xeon E5620 da 2,40 GHz Quad-Core 8 (con H / T). Il nuovo server ha 2 thread Intel Xeon E5-2640 2,5 GHz Six-Core 12 (con H / T).

EDIT 2: Ecco l'analisi finale:

Il piano di alimentazione era equilibrato, non ad alte prestazioni. Sostituito.

Tempdb era su un RAID 5, non su RAID 10. Aggiunto un altro HD per creare due configurazioni RAID 10 fisicamente distinte, una per tempdb e una per tutto il resto.

File esclusi SQL correlati (mdf, ldf, ndf, bak) dalla scansione antivirus.

Ricostruito tutti gli indici dopo il passaggio al nuovo server. Erano molto frammentati - probabilmente a causa di backup, copia, ripristino?

E mi sono reso conto che il salto del processore non era così grande. Le query non verranno eseguite molto più velocemente, ma con più processori, più core, più RAM, saremo più scalabili.


Oltre O / S il risparmio di energia non ci può essere anche impostazioni del BIOS correlati: stackoverflow.com/a/27807572/538763
crokusek

Risposte:


11

Il raid 5 è più lento del raid 10, specialmente per carichi di lavoro pesanti. Come tale, non è generalmente raccomandato per il server SQL e certamente non per tempdb. Questo da solo potrebbe facilmente spiegare la differenza di prestazioni.

La mia raccomandazione sarebbe di spostare tempdb al raid 10.


4

Questo è un problema molto generale, quindi è difficile dare un consiglio specifico. Ma, se mi trovassi in questa situazione, inizierei dalle basi, controllando le query più costose. Quale funzionalità richiede più tempo? Che cosa sta consumando più tempo a eseguire query con tempo statistico? Una volta limitato il focus, puoi confrontare le cose con il vecchio server. Inoltre, qualcosa da verificare è assicurarsi che entrambi i server siano sullo stesso livello di patch (SQL e Windows).


3

Bene, non dici nulla sui tuoi dischi rigidi e sul numero di file tempdb che hai. C'è una raccomandazione generale che nr di tempdbs = numero di core fino a 32, c'è anche un interruttore da lanciare per garantire che i db di temperatura siano usati allo stesso modo.

Tuttavia indepth: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data- file-per-processor-core.aspx hai anche modificato il pacchetto per tabelle e indici durante la migrazione? Il backup e il ripristino potrebbero finire con il default su una diversa spaziatura degli indici (inclusi quelli raggruppati)

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.