Hemos estado en un servidor dedicado (quad-core único, 6 GB de RAM) y nos estamos mudando a un nuevo servidor dedicado (2x hex-core, 32 GB de RAM). Ambos son Windows Server 2008, SQL Server 2008. El rendimiento en el nuevo servidor es ligeramente peor que el antiguo y más lento.
En las pruebas, nuestra aplicación ASP.NET se ejecuta entre un 10 y un 20% más lento. La ejecución de consultas costosas individuales con STATISTICS IO y STATISTICS TIME muestra un tiempo transcurrido del 10 al 20% mayor en el nuevo servidor. El perfil de consulta SQL muestra un mayor uso de CPU en consultas costosas.
El Administrador de tareas en el nuevo servidor muestra que sqlserver.exe consume 22 GB de RAM, pero los valores de la CPU siempre permanecen muy bajos.
He actualizado todas las estadísticas, los índices reconstruidos o reorganizados, etc. Los planes de ejecución deben almacenarse en el nuevo servidor en este momento, dada la cantidad de pruebas que he realizado. Si faltan índices (no creo que los haya), afectan a los servidores antiguos y nuevos por igual. Nuevo tiene una copia de seguridad restaurada de los mismos datos en el antiguo.
Esperaba que el rendimiento en el nuevo servidor fuera mejor, pero la mayor preocupación es la carga. Si el servidor anterior funciona mejor incluso bajo carga, ¿qué sucederá cuando este nuevo servidor, un poco peor, tenga que soportar esa carga?
¿Qué más podría faltar aquí?
EDITAR: MAXDOP establecido en 6.
El servidor anterior tiene SO, bases de datos y tempdb en las mismas unidades físicas (RAID 10). Total de 4 15k 3 Gb / s SAS de 3,5 pulgadas. El nuevo servidor tiene tres conjuntos de unidades: SO en RAID 1, base de datos en RAID 10, tempdb en RAID 5. Total de 9 15K 6 Gb / s 2.5 pulgadas SAS.
El servidor anterior tiene 1 x Intel Xeon E5620 2.40 GHz Quad-Core 8 subprocesos (w H / T). El nuevo servidor tiene 2 x Intel Xeon E5-2640 2.5 GHz Six -Core 12 Threads (w H / T).
EDITAR 2: Aquí está el análisis final:
El plan de energía era equilibrado, no de alto rendimiento. Cambié eso.
Tempdb estaba en un RAID 5, no RAID 10. Se agregó otro HD para crear dos configuraciones RAID 10 físicamente distintas, una para tempdb y otra para todo lo demás.
Se excluyeron los archivos relacionados con SQL (mdf, ldf, ndf, bak) del análisis de virus.
Reconstruyó todos los índices después del traslado al nuevo servidor. Estaban muy fragmentados, ¿posiblemente como resultado de una copia de seguridad, copia, restauración?
Y me di cuenta de que el salto del procesador no era tan grande. Las consultas no se ejecutarán mucho más rápido, pero con más procesadores, más núcleos, más RAM, seremos más escalables.
fuente
Respuestas:
La incursión 5 es más lenta que la incursión 10, especialmente para cargas de trabajo de escritura pesada. Como tal, generalmente no se recomienda para el servidor SQL y ciertamente no para tempdb. Esto solo podría explicar fácilmente la diferencia de rendimiento.
Mi recomendación sería mover tempdb a la incursión 10.
fuente
Este es un problema muy general, por lo que es difícil dar un consejo específico. Pero, si estuviera en esta situación, comenzaría desde lo básico, verificaría las consultas más caras. ¿Qué funcionalidad lleva más tiempo? ¿Qué es lo que consume más tiempo que ejecutar consultas con tiempo de estadísticas? Una vez que reduce un poco su enfoque, puede comparar cosas con el servidor anterior. Además, algo que debe verificar es asegurarse de que ambos servidores estén en el mismo nivel de parche (SQL y Windows).
fuente
Bueno, no dices nada sobre tus discos duros y la cantidad de archivos tempdb que tienes. Hay una recomendación general de que nr de tempdbs = número de núcleos hasta 32, también hay un interruptor para lanzar para garantizar que los dbs temp se usen por igual.
Sin embargo en profundidad: 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 ¿ también ha cambiado el empaque de tablas e índices durante la migración? La copia de seguridad y la restauración pueden terminar en un relleno diferente en los índices (incluidos los agrupados)
fuente