El enfoque principal de este sitio de blog es el rendimiento en un entorno de SQL Server. Se podría argumentar que el rendimiento comienza con el diseño de la base de datos y la aplicación. Pero también puede argumentar que tener los recursos adecuados disponibles es esencial para un buen desempeño. A pesar de toda la discusión sobre los recursos correctos (qué modelo de CPU, cuánta memoria, qué tipo de almacenamiento), a veces descuidamos el acto de planificar la capacidad:usar los datos que tenemos para tomar decisiones informadas sobre lo que necesitamos . La planificación de la capacidad no es solo determinar cuánto espacio en disco necesitamos, sino que también involucra los recursos que una instancia de SQL Server debe tener disponible para manejar la carga de trabajo.
¿Nuevo o existente?
La planificación de capacidad para una nueva solución es realmente complicada. Debe realizar estimaciones sobre la carga de trabajo en función de la información que recopila del negocio. Esto significa que debe hacer preguntas difíciles sobre la cantidad de datos que esperarán en el primer mes, los primeros seis meses y el primer año. Cuando llega una nueva solución, a menudo es lo ÚLTIMO en lo que piensa la empresa, por lo que muy a menudo obtendrá respuestas vagas. En el caso de una nueva solución, realmente debe hacer un mejor esfuerzo de suposición. No se tire de los pelos tratando de obtener números exactos.
Si la solución es de un proveedor, debe pedirle recomendaciones de planificación sobre el espacio necesario y los recursos necesarios. Lo admito, puede que no tengan esos datos, pero no obtienes lo que no pides. Nunca está de más intentarlo.
[Bonificación:si el proveedor no tiene ninguna información que proporcionar, ¿no sería útil si, después de que el sistema esté en funcionamiento durante unos meses, le envíe sus datos... como el hardware que tiene? y cómo es la carga de trabajo? No es necesario que sea un artículo de 20 páginas, pero los comentarios pueden empujarlos en la dirección de ser más proactivos en el futuro.]
En términos de una solución existente, si tiene un problema de rendimiento o está buscando actualizar el hardware, querrá capturar información sobre el entorno actual para planificar uno nuevo.
Almacenamiento
Planificación de la cantidad de almacenamiento necesario es bastante simple, solo requiere un poco de planificación por adelantado. En mis artículos proactivos de verificación de estado de SQL Server, analizo la supervisión del espacio en disco e incluyo una consulta para capturar información de archivos. Esta consulta captura el tamaño de los archivos de la base de datos para la instancia, así como el espacio utilizado. Es imperativo hacer una tendencia de estos datos a lo largo del tiempo, y eso no significa unas pocas semanas. Está buscando ver cómo cambian los archivos a lo largo de los meses, posiblemente durante uno o dos años, porque los patrones de uso de una aplicación pueden cambiar. Esta información es fácil de capturar, requiere poco espacio para almacenar y es invaluable para tenerla como referencia cuando está adquiriendo almacenamiento. Si puede proporcionar datos cuantitativos sobre el crecimiento del sistema, entonces tiene muchas más posibilidades de obtener el espacio que necesita por adelantado en lugar de tener que pedirlo más tarde. Y cuando solicite espacio, asegúrese de incluir tempdb en sus cálculos.
Recursos de hardware
CPU
Optimizar el rendimiento de su CPU no se trata solo de la cantidad de CPU que tiene, también debe considerar el modelo y la carga de trabajo (por ejemplo, almacén de datos con consultas paralelas grandes frente a OLTP con consultas en serie). Con esta información y un poco de ayuda de Glenn, puede determinar el mejor procesador para su servidor. ¡No olvide considerar los costos de licencia y las limitaciones según su edición de SQL Server!
Memoria
La memoria es relativamente económica y es nuestra recomendación comprar siempre la cantidad máxima de memoria que un servidor puede contener. Leer datos de la memoria es significativamente más rápido que leerlos del disco, por lo que cuantos más datos quepan en la memoria, mejor. Tenga en cuenta que toda la base de datos no tiene para caber en la memoria. Solo necesita que el conjunto de datos de trabajo quepa en la memoria. Considere una base de datos de 2 TB. Es poco probable que, en un escenario OLTP, se acceda a todos los 2 TB todos los días. Por lo general, solo se accede a los datos recientes, quizás solo los últimos 30 o 60 días. Esos son los datos que deben caber en la memoria. Pero, por supuesto, rara vez vemos un entorno OLTP puro, a menudo es un entorno mixto porque a los usuarios les gusta ejecutar informes sobre grandes conjuntos de datos y no hay un almacén de datos o una copia de informes de la base de datos, por lo que tienen para ejecutar los informes contra la producción. Esto complica el requisito de memoria. Ahora, a veces necesita esos datos más antiguos en la memoria, pero a veces no. Es importante comprender la carga de trabajo; ¿Qué tipos de consultas se ejecutan en la base de datos?
Si está utilizando la Edición estándar, compruebe que tiene más memoria en el servidor que la memoria máxima admitida. Por ejemplo, con SQL Server 2014 y versiones posteriores, en Standard Edition, la cantidad máxima de memoria que puede asignar al grupo de búfer (a través de la configuración de memoria máxima del servidor) es de 128 GB. Por lo tanto, desea tener más memoria en el servidor (por ejemplo, 160 GB) para que pueda establecer la memoria máxima del servidor en el valor más alto posible de 128 GB y aún tener memoria disponible para el sistema operativo y otros procesos de SQL Server. Además, con SQL Server 2016 SP1 Standard Edition puede usar OLTP en memoria, con un límite de 32 GB por base de datos. Esto está por encima del valor máximo de memoria del servidor, por lo que si planea usar esta función, compre memoria en consecuencia.
Almacenamiento
Cuando hablamos de los requisitos de rendimiento para el almacenamiento, a menudo escucha a la gente hablar de IOPS (operaciones de entrada/salida por segundo). De hecho, este artículo se inspiró en una pregunta de un espectador que vio mi curso de Pluralsight sobre Benchmarking y Baselining. La pregunta era:"¿Cómo se correlacionan los contadores del Monitor de rendimiento para lecturas y escrituras por segundo con las conexiones de usuario para estimar la cantidad de IO por usuario?" Las lecturas y escrituras por segundo son las operaciones de entrada/salida, por lo que tenemos estos datos disponibles a través de PerfMon a nivel de instancia, y esto es lo que usa para definir los requisitos de IOPS para una instancia.
Sin embargo, si sabe leer y escribir y conexiones de usuario, luego puede hacer algunos cálculos y calcular IOPS por usuario. Esto es útil si planea hacer crecer la solución y agregar más usuarios. Quiere asegurarse de que la solución se escalará, y una opción que tiene es tomar sus IOPS calculadas por usuario, en función de una cantidad X de usuarios, y luego estimar las IOPS de instancia para una cantidad Y de usuarios. Ahora, hacemos muchas suposiciones con este cálculo. Asumimos que la forma en que las nuevas conexiones utilizan el sistema es la misma que en la actualidad; al final, ese puede ser el caso o no, no lo sabrá hasta que el sistema esté en su lugar. Cuando comprenda este valor (lecturas + escrituras/conexiones de usuario =IOPS promedio por usuario), entonces sabrá cómo estimar las IOPS para una solución en función de las conexiones de usuario anticipadas.
Luego lleva esta información a su persona de almacenamiento para analizar las posibles configuraciones disponibles. Puede calcular el IOPS máximo para una configuración de disco, siempre que tenga información sobre los discos (por ejemplo, la cantidad de discos, la velocidad, el tamaño y la configuración de RAID). Puede probar el rendimiento de E/S de una unidad con CrystalDiskMark, aunque es posible que esto no sea posible si no se ha decidido el almacenamiento. Sin embargo, una vez que esté en su lugar, debe realizar esta prueba para asegurarse de que el IOPS para una unidad determinada pueda cumplir con la carga de trabajo esperada.
Las IOPS son solo una forma de ver el rendimiento del almacenamiento. Comprenda que estos datos le indican cuánto IO está ocurriendo e, idealmente, si conoce el IOPS y tiene el almacenamiento para cumplir con los requisitos, entonces la latencia debería ser mínima. Pero, la latencia es lo que afecta el rendimiento. Para determinar qué latencia existe, deberá usar una herramienta como DiskSpd para comparar el almacenamiento. Glenn tiene un excelente artículo que explica cómo analizar el rendimiento de IO y luego otro artículo sobre cómo usar DiskSpd para probarlo y comprender la latencia. Recomiendo encarecidamente revisar ambos artículos si no ha analizado el almacenamiento y el rendimiento anteriormente.
Conclusión
La planificación de la capacidad es algo más que saber cuánto espacio necesita para los archivos de la base de datos. Debe comprender la carga de trabajo y lo que requiere en términos de recursos de CPU, memoria y disco. Para hacer esto, necesita datos... lo que significa que necesita capturar líneas de base. Mi primera sesión en la comunidad de SQL Server fue en diciembre de 2010 y trató sobre el tema de las líneas base. Seis años después, sigo hablando de su importancia, y todavía escucho de personas que no tienen estos números. Si desea realizar una planificación de capacidad inteligente y específica, debe recopilar los datos apropiados... de lo contrario, solo está adivinando.
