Más núcleos de CPU frente a discos más rápidos

Soy parte de una pequeña empresa, así que, como de costumbre, cubro varios roles diferentes. La última de ellas es la adquisición de un cuadro de SQL Server dedicado para nuestra aplicación web .NET. Hemos sido citados en una configuración de CPU dual Xeon E5-2620 (seis núcleos) de 2.00 GHz (12 núcleos en total), con 32 GB de RAM. Esto nos ha dejado con un presupuesto limitado para la matriz de discos, que consistiría esencialmente en dos unidades SAS 300 GB de 2.5 "(15k RPM) en una configuración RAID 1.

Sé que la configuración del disco es subóptima para SQL Server y realmente me gustaría impulsar RAID 10 para que podamos poner la base de datos, los archivos de registro y tempdb en sus propias unidades. Para que esto sea compatible con nuestro presupuesto, ¿debería considerar reducir la cantidad de núcleos de CPU? ¿o obtendría un mejor banco por dinero manteniendo los núcleos y usando menos unidades, quizás 4 en una configuración RAID 1 dual?

Aquí hay algunas estadísticas adicionales

• La base de datos de SQL Server está inclinada hacia un gran número de lecturas a escrituras, probablemente del 80% frente al 20%, respectivamente. El tamaño actual de la base de datos es de alrededor de 10 GB 26 GB en la actualidad, creciendo a un ritmo de 250 MB por mes.

• Actualmente se ejecuta en SQL Server 2008 R2 Standard en una única caja Xeon de cuatro núcleos compartida con el servidor web (12 GB de RAM, 2 unidades de disco de 10k 300GB SAS en RAID 1), buscando pasar a SQL Server 2012 Standard.

• La base de datos sirve a aproximadamente 100-150 usuarios concurrentes con algunas tareas de programación en segundo plano. Leyendo esto, creo que 12 núcleos es una exageración grave.

Implementé toda la aplicación en un servicio en la nube de Azure (2 instancias pequeñas) vinculada a una base de datos SQL Azure. Aunque el rendimiento fue razonable durante las pruebas (casi carga cero) perdí el coraje de usar en la producción debido a la imprevisibilidad de la que había leído tanto. Puede funcionar mejor con un enfoque de escalamiento horizontal, pero con solo una base de datos de 10 GB, probablemente pueda escalar en este momento y ahorrar algo de dinero.

Inicialmente pasé por alto los costos de licencia y no me di cuenta de que las licencias de SQL Server 2012 se basan en la cantidad de núcleos. Tengo una suscripción a BizSpark MSDN con una licencia estándar de SQL Server 2012, por lo que necesitaría leer cuántos núcleos utilizaría de inmediato.

Hablando de una experiencia que es humilde pero que creo que vale la pena compartir, el principal cuello de botella con las bases de datos SQL (Sybase y el servidor SQL aquí) es el almacenamiento.

Pero creo que es justo que alguien primero compare su configuración antes de hacer suposiciones incorrectas. En mi caso, el uso de la CPU nunca ha aumentado lo suficiente como para justificar la actualización de la CPU en el corto plazo. En cambio, he actualizado de una sola unidad a RAID 1 y luego a RAID 10 + un aumento de 8GB a 16GB de RAM.

Todas estas actualizaciones RAID ayudaron a reducir los tiempos de espera anteriores en un factor de 2 a 6. Sospecho que la actualización a SSD sería aún mejor. Si lo piensa, todo se puede reducir al ancho de banda (teórico). Su combo [(Velocidad RAM + Tamaño RAM + Controlador de memoria) a la CPU] tiene un límite de ancho de banda que sería el factor más importante en las operaciones de lectura cuando sus datos siempre deben almacenarse en caché, su almacenamiento particular (RAID) tiene un límite de ancho de banda ( afecta las lecturas cuando se pierde la memoria caché y las escrituras al vaciar o con muchos clientes que escriben muchos datos combinados).

Normalice todos esos límites tanto como sea posible (acérquelos de modo que no tenga desperdicio de recursos) y créelos tanto como sea posible (actualice donde sea necesario y solo si es necesario, no permita que los recursos se desperdicien si el sistema gana ' No poder usarlos porque hay algún otro cuello de botella en el camino). Al final, su peor cuello de botella será el subsistema de servidor de menor rendimiento (con el menor ancho de banda) en su configuración particular.

También podría agregar que, en el proceso de actualización, he creado configuraciones RAID separadas para los archivos de la base de datos y los archivos de registro de la base de datos. La razón fue que los archivos de registro de la base de datos tienden a ser intensivos en escritura. Se utiliza un archivo de registro para recuperar una base de datos de un bloqueo y siempre se escribe de inmediato ya que se confirma una transacción antes de que se escriban datos en el archivo de base de datos.

Algunos servidores de replicación de bases de datos también usan un archivo de registro, pero la mayoría de las réplicas no se realizan de forma instantánea sino frecuente, por lo que el impacto en el rendimiento de lectura es mínimo aquí. Al menos eso pienso. Hice una evaluación comparativa mínima al realizar esta actualización, así que nuevamente, recomiendo a cualquiera que primero evalúe sus diferentes configuraciones y primero actualice su almacenamiento, luego RAM y enlace de red, antes de pensar en actualizar sus CPU.

Después de actualizaciones más extensas en más de 5 servidores, regresé para compartir mi experiencia. Definitivamente sigo abogando por la primera actualización del almacenamiento, luego la RAM y luego la CPU. La razón es la disparidad de anchos de banda en el sistema entre almacenamiento, RAM y CPU, en orden de menor a mayor. Así que actualicé un montón de servidores de RAID10 y RAID1 duales a SSD.

La forma en que lo hice debido a problemas de costos (tengo 20 servidores más para actualizar) es mover los datos de la base de datos y los archivos de objetos a un SSD (sí, solo un SSD en RAID0) y mover el registro de transacciones más tempdb a un 4xHDD RAID10 configuración. También probé con el tempdb en la SSD con excelentes resultados (de hecho, resultados muy buenos con consultas más de 15 veces más rápidas a veces, produciendo algunos informes que tomaron segundos en lugar de minutos en el pasado) pero luego moví el tempdb al disco RAID10 porque de preocupaciones intensivas de desgaste de escritura para el SSD

Entonces, básicamente, he observado tiempos de respuesta 10-15 veces más rápidos por algunas de las consultas más largas. El SSD es ideal para leer datos en RAM rápidamente porque SQL Server no trae datos a RAM hasta que se solicite y, por supuesto, los datos primero deben cargarse en RAM para que la CPU los procese (más tarde, en caché L1, L2, L3) , por lo que los SSD ayudan a reducir ese tiempo de espera inicial en un factor enorme. Y los SSD también ayudan a reducir los tiempos de intercambio ... limpiando la RAM y cargando nuevos datos, especialmente si su base de datos es más grande de lo que puede caber en la RAM.

Con todo, estamos muy contentos y hemos estado funcionando así durante varios meses en una especie de proceso de migración lenta para permitir que los servidores se ejecuten para que pueda recopilar información sobre el nivel de desgaste antes de cambiar todos mis servidores a esta configuración. ¡Y esto es solo SQL Server Express! : D - Solo asegúrate de que tus SSD puedan proporcionar IOPS constantes porque eso es otra cosa que hace una gran diferencia (solo googlealo). Es por eso que elegí los SSD de la serie Intel DC (DataCenter).

Algo no es la respuesta que probablemente esté buscando en la primera parte, pero: ¿ha considerado llevarlo a la nube? AWS podría permitirle satisfacer la mayoría de las necesidades anteriores y ampliar su poder de compra sin tener que lidiar también con el hardware.

Segunda parte: el hardware realmente depende de las tareas. Tiendo a inclinarme hacia más CPU cuando puedo hacer una integración CLR personalizada, porque entonces puedo optimizar soluciones verdaderamente paralelas a los problemas. Sin embargo, la mayoría de las veces, si es mejor tener soluciones basadas en sistemas, encuentro que la RAM y la velocidad del disco duro es el mayor cuello de botella, y el segundo parece ser su caso. (Donde la idea SSD anterior sería útil)

Sin estadísticas reales de su servidor, le sugiero que busque algunas soluciones de almacenamiento en caché para reducir las escrituras (a menos que esté haciendo algún tipo de registro con las escrituras o cosas que necesitan un historial) y que ponga mucho más dinero en sus discos duros. que la CPU El servidor SQL es bastante bueno para ir en paralelo en las consultas (si están escritas para ello), pero si tiene muchas escrituras, entonces su disco duro es el verdadero cuello de botella.