Un sistema que estamos desarrollando consta de un frontend de aplicación web y un backend que procesa una gran cantidad de datos utilizando procedimientos almacenados en SQL Server 2008 R2 (por favor, no pregunte por qué...). Estos procedimientos almacenados hacen un uso intensivo de tablas temporales (creación, inserciones, uniones), de modo quetempdbLa tasa de E/S es alta en escrituras y lecturas. Nuestros clientes necesitan velocidad, por eso estamos a punto de recomendar lo siguiente:
- Compre un servidor con una matriz SSD RAID 1 para almacenar la base de datos principal (tal vez RAID10 si tienen el dinero), usando otro disco duro para la instalación del sistema operativo y SQL Server, de modo que los datos vitales se almacenen con replicación en un disco rápido, y 64 GB de RAM.
- Utilice un disco Ram para almacenar eltempdbbase de datos, por lo que las tablas temporales (creemos que el mayor cuello de botella en el rendimiento) se procesan en la RAM.
Algunos datos de contexto:
- Nuestra base de datos no utiliza más de 10 GB, con una tasa de crecimiento esperada muy baja. Tempdb normalmente crece hasta no más de 2-3 GB.
- El servidor se utilizará para la base de datos y el servidor web.
- El software Ramdisk puede montar el disco ram al iniciar Windows.
Hemos probado el enfoque del disco RAM en una computadora portátil con mucha memoria RAM. La aceleración es notable (los tiempos de ejecución de procedimientos almacenados se redujeron a 1/3) al menos.
Necesito ayuda para determinar si esta es una buena solución o no, y para detectar cualquier defecto (obvio o menos obvio) que pueda estar pasando por alto.
EDITAR: ¡Gracias por las respuestas hasta ahora! Olvidé mencionar explícitamente que habrá usuarios simultáneos usando la aplicación, por lo que se ejecutarán múltiples operaciones de tablas temporales. Además, mezclar el servidor web y el servidor de base de datos no es nuestra elección, ya sabemos que no es óptimo;)
Respuesta1
No es sólo el precio, es la espera. Comparar adecuadamente. Verifique las IOPS, más la longitud de la cola del disco. Utilice perfiles Perfmon y SQL. Adelante, esperaré.
Ya sabe que el sistema operativo debe estar en un conjunto de ejes, los MDF en otro, los LDF en otro y los archivos tempdb en otro, si tiene preocupaciones reales sobre el rendimiento. Si no puede comprometerse a hacerlo, compárelo y descubra sus prioridades. Además, los diferentes patrones de lectura y escritura pueden dictar diferentes niveles de RAID para cada uno de ellos.
Es posible que descubra que los discos estándar con las configuraciones RAID correctas pueden llevarlo a donde necesita estar y no limitarse a SSD empresariales. Sin embargo, si tempdb está siendo golpeado lo suficiente, un solo SSD podría ser una buena opción. Probablemente no sea necesario RAID para mejorar el rendimiento, aunque para redundancia podría ser una buena idea. Depende de tu presupuesto y de cuánto tiempo puedas estar inactivo, por supuesto.
También sabes que el servidor SQL debe estar separado del servidor web, ¿verdad? ¿Si el rendimiento es una preocupación? Incluso si no tienes ningún problema ahora, si creces, te resultará difícil determinar cuál está siendo castigado con más fuerza y cuál es la solución adecuada.
Respuesta2
RAID es pararedundancia, el rendimiento se va por la ventana. Por ejemplo, RAID 5 para leer un datotodoSe deben leer los discos componentes y verificar la paridad (es decir,esmás lento que leer desde un solo disco, los movimientos de la cabeza no necesariamente estarán sincronizados, por lo que estará esperando lamás largodel conjunto, no solo el promedio), escribir significa leer todo, calcular la paridad y escribir nuevos datos y la paridad, claramente más lento que simplemente escribir.
Sí, una buena implementación de RAID y un sistema operativo inteligente pueden mitigar esto en gran medida (debe ser así, incluso los discos individuales son terriblemente lentos con respecto a la RAM, por lo que cualquier sistema operativo que se precie realiza un almacenamiento en caché extenso independientemente de los discos).
Sí, un DBMS inteligente también almacenará en caché los datos en la RAM tanto como sea posible (respetando las promesas hechas con respecto a la coherencia de los datos, la resistencia a fallas, etc.; cuando sea necesario, esperará explícitamente a que los datos estén seguros en el disco antes de continuar).
Para cualquier base de datos, un disco RAM es puro veneno ("los datos escritos explícitamente en el disco, por lo tanto seguros", no lo son).
Respuesta3
Gracias por todas las respuestas. Han sido de gran ayuda. Después de algunas investigaciones posteriores, descubrí que la velocidad de E/S no era el principal cuello de botella en este caso particular, aunque es importante en general. Las mejores prácticas en la gestión de tempdb incluyen tener al menos 4 archivos de datos. Microsoft también recomienda 1 archivo de datos para cada núcleo de CPU. Tener más archivos ayuda a reducir algunos tipos de problemas de contención.
Algunos enlaces sobre esto:
Respuesta4
para que la tasa de E/S de tempdb sea alta en escrituras y lecturas
Muy poca RAM. tempdb solo realiza E/S cuando se desborda; de lo contrario, SQL Server no volca las páginas de tempdb al disco.
Por lo tanto, un disco RAM no ayudará; más bien, agregará más memoria.