Servidor de almacén de datos. ¿Cómo se calculan las especificaciones de RAM / CPU?

Estoy tratando de escribir una especificación para un servidor de depósito de datos para nuestra actualización planificada del depósito de datos.

A medida que ejecutamos servidores virtuales en hosts VMWare, tenemos la capacidad de agregar o eliminar recursos según sea necesario. En el pasado, hemos agregado RAM y CPU de forma incremental según sea necesario. A medida que aumentaron nuestras demandas, presionamos para obtener más recursos. (principalmente disco y RAM).

Pedimos más Nos dan lo menos posible.

Sin embargo, recientemente, cada vez que hablamos de recursos, ahora somos criticados por no especificar la máquina en primer lugar, y ahora me dicen que los hosts de desarrollo están al máximo, no hay más RAM disponible.

Somos una pequeña organización del gobierno local con ~ 50 usuarios habituales del DW. En el uso diario normal funciona bien. Obtenemos un buen rendimiento de consultas mdx, y nuestros informes y paneles son rápidos. Los usuarios están contentos.

Sin embargo, nuestros procesos ETL se ejecutan durante toda la noche, y estamos comenzando a ver evidencia de presión en la memoria cuando procesamos datamarts simultáneamente. Anoche, SSIS falló con advertencias sobre un "error de falta de memoria".

Nuestro servidor DW existente es Win 2008 R2 con 4 CPU y 16 Gb de RAM con SQL 2012 Std. Tengo la memoria máxima del servidor establecida en 12 GB, dejando 4 GB para el sistema operativo y los servicios, etc. Nuestro DW existente tiene 3 cubos de datamarts / OLAP, y estamos desarrollando 2 más.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Se planea que nuestro nuevo servidor sea Win 2012 con SQL 2016 Enterprise. Ejecutará SQL, SSIS, SSRS y SSAS. El almacenamiento no es un problema, pero no estoy seguro acerca de la RAM y la CPU.

De acuerdo con la Guía de referencia de Fast Track Data Warehouse para SQL Server 2012 , el mínimo que debería tener es 128 Gb para una máquina de 2 sockets ... lo que parece un poco excesivo. Los requisitos de hardware y software para instalar SQL Server 2016 recomiendan un mínimo de 4 Gb de RAM para SQL 2016. ¡Esa es una gran diferencia!

Entonces ... ¿Cuál es un buen punto de partida? 32Gb? 64Gb? ¿Cómo justifico mi posición inicial (especificación) a TI?

¿Hay alguna buena guía sobre cómo calcular los recursos del servidor?

¿Hay alguna buena regla general?

¿Cuáles son las métricas / ingredientes clave para el dimensionamiento de RAM en un contexto DW?

• El volumen de datos?
• ¿El número de cubos?
• ¿El tiempo que lleva hacer ETL o procesar un cubo?
• ¿Carga de procesamiento máxima durante la noche o rendimiento según lo visto por los usuarios finales durante el día?

Gran pregunta, e hice una sesión sobre esto en TechEd hace unos años llamada Construyendo los servidores SQL más rápidos:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

En él, explico que para los almacenes de datos, necesita almacenamiento que pueda proporcionar datos lo suficientemente rápido como para que SQL Server los consuma. Microsoft creó una gran serie de documentos técnicos llamada Arquitectura de referencia de Fast Track Data Warehouse que incluye los detalles del hardware, pero la idea básica es que su almacenamiento debe ser capaz de proporcionar un rendimiento de lectura secuencial de 200-300 MB / s, por núcleo de CPU, en para mantener ocupadas las CPU.

Cuantos más datos pueda almacenar en caché en la memoria, más lento será el almacenamiento. Pero tiene menos memoria de la necesaria para almacenar en caché las tablas de hechos con las que está tratando, por lo que la velocidad de almacenamiento se vuelve muy importante.

Aquí están tus próximos pasos:

• Mira ese video
• Pruebe su almacenamiento con CrystalDiskMark (así es como )
• Con 4 núcleos, querrás al menos 800 MB / s de rendimiento de lectura secuencial
• Si no tiene eso, considere agregar memoria hasta que el dolor desaparezca (y el almacenamiento en caché de toda la base de datos en RAM no es impensable)

Supongamos que tiene una base de datos de 200GB con la que está lidiando, y no puede obtener suficiente capacidad de almacenamiento para mantener ocupados sus núcleos. No es impensable necesitar no solo 200 GB de RAM, sino incluso más, porque después de todo, SSIS y SSAS realmente quieren hacer su trabajo en la memoria, por lo que debe tener los datos del motor disponibles, además de espacio de trabajo para SSIS y SSAS.

Esta es también la razón por la cual las personas intentan separar SSIS y SSAS en diferentes máquinas virtuales: todos necesitan memoria simultáneamente.

La Guía de referencia de Fast Track Data Warehouse para SQL Server 2012 está realmente un poco desactualizada, especialmente si se está mudando a SQL Server 2016 (¿en serio? Llámeme), no solo en términos de tiempo, sino también de características.

En SQL Server 2012, la versión en la que se basa la vía rápida, solo podría tener índices de almacén de columnas no agrupados. Estas son estructuras separadas de la tabla principal, por lo que incurren en gastos adicionales de almacenamiento y procesamiento debido a las copias comprimidas de los datos.

Desde SQL Server 2014 en adelante, puede tener índices de almacén de columnas agrupados. Estos ofrecen una compresión masiva y un potencial aumento del rendimiento para consultas agregadas / resumen. Son absolutamente apropiados para las tablas de hechos, por lo que su tabla de hechos de 32 GB podría parecerse más a ~ 8-12 GB. YMMV. Eso cambia un poco el paisaje, ¿no? Mirando su mesa (y el pulgar en el aire) tal vez podría salirse con la suya con 32GB, pero yo dispararía por 64GB (no es como si estuviera pidiendo 1TB) y dejaría espacio para otros servicios y crecimiento, la justificación es que esto permite que mantenga su mesa más grande en la memoria, dejar espacio para el crecimiento y el espacio para otros servicios. No tiene que contarles sobre la compresión. Una cosa que debe tener en cuenta con el tamaño es que no solo está dimensionando sus datos ahora, sino cómo será, digamos dentro de un año. Sin embargo, tenga en cuenta también que el rendimiento de las búsquedas de puntos puede ser horrendo, pero a medida que se mude a SQL Server 2016, puede agregar índices adicionales o siempre podría considerar los índices de almacén de columnas para el análisis operativo en tiempo real, aunque necesitará más memoria para eso. :)

Por cierto, ¿cómo te está yendo con los CTP? Actualmente, en CTP3.3 tiene la mayoría de las características que querrás usar disponibles, por lo que dices que no tienes recursos para las pruebas, pero podrías obtener una prueba de Windows Azure , active una máquina virtual, cree algunos datos de muestra, pruebe la compresión, el rendimiento de las funciones y consultas clave, etc. de forma gratuita. O si tiene una licencia de MSDN, esta está incorporada.

En resumen, dimensione para permitir que su tabla más grande esté en la memoria (más otras cosas) o configure una prueba simple (gratis en la nube) para obtener la evidencia sólida que busca. Recuerde desasignar su VM cuando haya terminado :)

Presumiblemente, mientras desarrolla y mantiene los paquetes ETL en máquinas de desarrollo local, a veces usa datos de prueba de escala similar o mayor a la que espera en la producción, y si no, tal vez consideraría hacerlo (datos reales anónimos o datos de prueba generados algorítmicamente, si sus datos reales son confidenciales)

Si este es el caso, puede ejecutar el proceso en varias condiciones de memoria y perfilarlo, para ver el punto donde más RAM deja de hacer una gran diferencia, tan útil como las reglas generales y las conjeturas educadas, nada de evaluación comparativa y perfil puede proporcionar respuestas mucho más concretas y como un bono puede resaltar cuellos de botella obvios que podrían ser fáciles de optimizar. Por supuesto, sus entornos de desarrollo / prueba pueden no coincidir exactamente con la producción, por lo que es posible que necesite usar la experiencia para interpretar cómo pueden cambiar los resultados.

Si está ejecutando SSIS en la misma máquina que las bases de datos, entonces definitivamente debe asegurarse de que las instancias del motor de SQL Server estén configuradas para nunca reclamar toda la memoria. El hambre de memoria no solo puede causar errores de OOM en SSIS, mucho antes de ese punto, puede causar problemas de rendimiento importantes, ya que pone en cola las memorias intermedias en el disco cuando de otro modo podría mantenerlos en la RAM. La cantidad que necesita reservar para SSIS y otras tareas variará en gran medida según su proceso, por lo que nuevamente la creación de perfiles es una buena manera de evaluar esto. A menudo se recomienda que ejecute SSIS en una máquina separada para que sea más fácil de administrar, aunque puede tener problemas de rendimiento de red y licencias para considerar allí.

Actualizar

Si, según su comentario, no hay recursos disponibles para realizar puntos de referencia realistas para medir dónde cae el rendimiento (y / o los errores OOM y los problemas relacionados comienzan a suceder) si se asigna muy poca RAM, las cosas se vuelven considerablemente más difíciles sin un conocimiento íntimo del almacén y los procesos ETL. Una regla general para la base de datos del almacén en sí: desea suficiente RAM para poder contener la totalidad de los índices más utilizados, y luego algunos para permitir datos menos utilizados y más para permitir el crecimiento esperado en el futuro cercano. / futuro medio.

Calcular esto puede ser faf: sp_spaceUsed no desglosará las cosas por índice, por lo que tendrá que consultar sys.allocation_units y amigos directamente usted mismo. Sin embargo, hay algunos ejemplos para comenzar, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 / parece el mejor de los primeros que surgió de una búsqueda rápida.

Además de las necesidades para ejecutar la base de datos del almacén, recuerde agregar los requisitos de RAM para SSIS si se va a ejecutar en la misma máquina y asegúrese de que SQL Server tenga límites de RAM para garantizar que esta memoria esté realmente disponible para SSIS

De los tamaños de datos generales que enumera, mi instinto sugiere que 32 Gb sería el mínimo absoluto que recomendaría solo para el motor de base de datos y SSIS, configurando las instancias de SQL para usar como máximo 26, y como también está ejecutando SSRS y otros servicios en la misma máquina, un mínimo razonable con algunas pruebas futuras sería de 64 Gb (dos tercios de sus datos actuales deberían caber después de que otros servicios y reservas tengan su corte). Obviamente, citar mi instinto no te llevará muy lejos en las discusiones con tu personal de infraestructura ...