¿Cómo se realizan pruebas de carga y planificación de capacidad para bases de datos?

34

Esta es una pregunta canónica sobre la planificación de capacidad para bases de datos.

Relacionado:

Estoy buscando crear una pregunta canónica de herramientas y métodos de planificación de capacidad para bases de datos. Esta pretende ser una pregunta canónica.

Obviamente, el flujo de trabajo general es:

  • Pon tu escenario en su lugar
  • Agregar monitoreo
  • Agregar tráfico
  • Evaluar resultados
  • Remediación basada en resultados
  • Enjuague, repita hasta que esté razonablemente feliz

Siéntase libre de describir diferentes herramientas y técnicas para diferentes servidores web, marcos, etc., así como las mejores prácticas.

gWaldo
fuente
Una base de datos casi nunca es un sistema independiente. Se debe ver en el contexto principal de los servidores de aplicaciones, a menudo grandes, frente a ellos. Los DB son los dispositivos de datos de fondo. Entonces, al probar la carga, debe considerar eso.
Nils

Respuestas:

24

Planificación de capacidad de disco y RAM

La planificación de la capacidad de disco y memoria para un servidor de base de datos es un arte negro. Más es mejor. Más rápido es mejor.

Como pautas generales ofrezco lo siguiente:

  • Desea más espacio en disco del que NUNCA necesitará.
    Tome su mejor cálculo de cuánto espacio en disco necesitará para los próximos 3-5 años, luego duplíquelo.
  • Necesitará suficiente RAM para mantener los índices de su base de datos en la memoria, manejar su consulta más grande al menos dos veces y aún tendrá suficiente espacio para un caché de disco del sistema operativo saludable.
    El tamaño del índice dependerá de su base de datos, y todo lo demás depende en gran medida de su conjunto de datos y estructura de consulta / base de datos. Ofreceré "Al menos el doble del tamaño de su tabla más grande" como sugerencia, pero tenga en cuenta que esta sugerencia se desglosa en operaciones de almacenamiento de datos realmente grandes donde la tabla más grande puede ser decenas o cientos de gigabytes.

Todos los proveedores de bases de datos tienen algunas instrucciones sobre cómo ajustar el rendimiento de su disco / memoria / núcleo del sistema operativo: dedique algún tiempo a esta documentación antes de la implementación. Ayudará.


Benchmarking de carga de trabajo y planificación de capacidad

Suponiendo que aún no se haya desplegado ...

Muchos sistemas de bases de datos se envían con herramientas de evaluación comparativa: por ejemplo, PostgreSQL se envía con pgBench .
Estas herramientas deberían ser su primera parada en la evaluación comparativa del rendimiento de la base de datos. Si es posible, debe ejecutarlos en todos los nuevos servidores de bases de datos para tener una idea de "cuánto trabajo" puede hacer el servidor de bases de datos.

Armado ahora con un punto de referencia sin procesar ABSOLUTELY MEANINGLESS, consideremos un enfoque más realista para la evaluación comparativa: cargue el esquema de su base de datos y escriba un programa que lo complete con datos ficticios, luego ejecute las consultas de su aplicación contra esos datos.
Esto compara tres cosas importantes: 1. El servidor de la base de datos (hardware) 2. El servidor de la base de datos (software) 3. El diseño de su base de datos y cómo interactúa con (1) y (2) anteriores.

Tenga en cuenta que esto requiere mucho más esfuerzo que simples puntos de referencia preconstruidos como pgBench: necesita escribir algún código para completar la información, y puede que necesite escribir algo de código para hacer las consultas e informar el tiempo de ejecución.
Este tipo de prueba también es sustancialmente más precisa: dado que está trabajando con su esquema y consultas, puede ver cómo funcionarán y le ofrece la oportunidad de perfilar y mejorar su base de datos / consultas.

Los resultados de estos puntos de referencia son una vista idealizada de su base de datos. Para estar seguro, suponga que solo alcanzará el 50-70% de este rendimiento en su entorno de producción (el resto es un colchón que le permitirá manejar un crecimiento inesperado, fallas de hardware, cambios en la carga de trabajo, etc.).


¡Es demasiado tarde! ¡Está en producción!

Una vez que sus sistemas están en producción, es realmente demasiado tarde para "comparar": puede activar brevemente el registro / sincronización de consultas y ver cuánto tiempo demoran las cosas en ejecutarse, y puede ejecutar algunas consultas de "prueba de esfuerzo" en grandes conjuntos de datos durante el apagado horas También puede ver la utilización de la CPU, RAM y E / S (ancho de banda del disco) del sistema para tener una idea de qué tan cargada está.
Desafortunadamente, todas estas cosas harán una idea de lo que está haciendo el sistema y un concepto vago de cuán cerca está de la saturación.
Eso nos lleva a ...


Monitoreo continuo

Todos los puntos de referencia en el mundo no lo ayudarán si su sistema de repente ve patrones de uso nuevos / diferentes.
Para mejores o peores, las implementaciones de bases de datos no son estáticas: sus desarrolladores cambiarán las cosas, su conjunto de datos crecerá (parece que nunca se reducen) y sus usuarios crearán de alguna manera combinaciones locas de eventos que nunca predijo en las pruebas.

Para planificar adecuadamente la capacidad de su base de datos, necesitará implementar algún tipo de monitoreo de rendimiento para alertarlo cuando el rendimiento de la base de datos ya no cumpla con sus expectativas. En ese momento, puede considerar acciones correctivas (nuevo hardware, esquema de base de datos o cambios de consulta para optimizar el uso de recursos, etc.).


Nota: Esta es una guía genérica y de muy alto nivel para dimensionar el hardware de su base de datos y descubrir cuánto abuso puede soportar. Si aún no está seguro de cómo determinar si un sistema específico satisface sus necesidades, debe hablar con un experto en bases de datos.
También hay un sitio de Stack Exchange dedicado específicamente a la gestión de bases de datos: dba.stackexchange.com . Busque en su archivo de preguntas o explore las etiquetas específicas de su motor de base de datos para obtener más consejos sobre el ajuste del rendimiento.

voretaq7
fuente
1
Además de eso, hoy en día, puede usar SSD para operaciones de intercambio / en disco. Eso acelerará las consultas que usan tablas temporales grandes en los discos. Por lo tanto, agregar más SSD es generalmente una muy buena idea.
Peter
2
@ Peter No recomendaría SSD para el espacio de intercambio (si está intercambiando activamente hay una tasa de rotación muy alta), aunque con un SSD lo suficientemente grande y un buen desgaste, el disco puede nivelar la vida útil de la máquina. He visto SSD utilizados para el espacio de tabla temporal con buenos resultados.
voretaq7
1
Tenga en cuenta que este consejo en los comentarios sobre SSD tiene ahora 7 años. Cada almacenamiento que contenga una base de datos en su servidor de base de datos debe ser un SSD en 2019 o posterior.
Mark Henderson
1

Generalmente necesita casos de uso realistas para probar el rendimiento. Una práctica recomendada es involucrar a los desarrolladores de aplicaciones y usuarios finales.

Registre lo que suelen hacer, parametrícelo (contenido, número de acciones concurrentes) para cada caso de uso.

Luego construya el lado del cliente. Una sola máquina física a menudo no es suficiente para aumentar la carga de producción.

Luego enciéndalo, calcule, mejore y pruebe nuevamente.

Te sorprenderá dónde surgen los cuellos de botella.

Nils
fuente