Los procedimientos recomendados para un rendimiento óptimo
Azure Managed Instance for Apache Cassandra es un servicio totalmente administrado para clústeres de Apache Cassandra de código abierto puros. El servicio también permite invalidar las configuraciones, en función de las necesidades específicas de cada carga de trabajo, lo que permite la máxima flexibilidad y control cuando sea necesario. En este artículo se proporcionan sugerencias sobre cómo optimizar el rendimiento.
Configuración e instalación óptimas
Factor de replicación, número de discos, número de nodos y SKU
Dado que Azure admite tres zonas de disponibilidad en la mayoría de las regiones y Cassandra Managed Instance asigna zonas de disponibilidad a bastidores, se recomienda elegir una clave de partición con alta cardinalidad para evitar particiones activas. Para obtener el mejor nivel de confiabilidad y tolerancia a errores, se recomienda encarecidamente configurar un factor de replicación de 3. También se recomienda especificar un múltiplo del factor de replicación como número de nodos, por ejemplo 3, 6, 9, etc.
Se usa RAID 0 sobre el número de discos que aprovisiona. Por lo tanto, para conseguir las IOPS óptimas, debe comprobar el número máximo de IOPS en la SKU que ha elegido junto con las IOPS de un disco P30. Por ejemplo, la SKU Standard_DS14_v2 admite 51 200 IOPS sin almacenar en caché, mientras que un único disco P30 tiene un rendimiento base de 5000 IOPS. Por lo tanto, cuatro discos conducirían a 20 000 IOPS, que está muy por debajo de los límites de la máquina.
Se recomienda encarecidamente realizar pruebas comparativas exhaustivas de la carga de trabajo con respecto a la SKU y el número de discos. La prueba comparativa es especialmente importante en el caso de SKU con solo ocho núcleos. Nuestra investigación muestra que CPU de ocho núcleos solo funcionan con cargas de trabajo menos exigentes, y la mayoría de las cargas de trabajo necesitan un mínimo de 16 núcleos para tener un buen rendimiento.
Cargas de trabajo analíticas frente a transaccionales
Las cargas de trabajo transaccionales suelen necesitar un centro de datos optimizado para baja latencia, mientras que las cargas de trabajo analíticas suelen usar consultas más complejas, que tardan más tiempo en ejecutarse. En la mayoría de los casos, es preferible separar los centros de datos:
- Uno optimizado para baja latencia.
- Uno optimizado para cargas de trabajo analíticas.
Optimización para cargas de trabajo analíticas
Se recomienda que los clientes apliquen la siguiente configuración de cassandra.yaml para cargas de trabajo analíticas (consulte aquí cómo hacerlo).
Tiempos de espera
| Value | Valor predeterminado de Cassandra MI | Recomendación para cargas de trabajo analíticas |
|---|---|---|
| read_request_timeout_in_ms | 5.000 | 10 000 |
| range_request_timeout_in_ms | 10 000 | 20.000 |
| counter_write_request_timeout_in_ms | 5.000 | 10,000 |
| cas_contention_timeout_in_ms | 1,000 | 2 000 |
| truncate_request_timeout_in_ms | 60 000 | 120 000 |
| slow_query_log_timeout_in_ms | 500 | 1,000 |
| roles_validity_in_ms | 2.000 | 120 000 |
| permissions_validity_in_ms | 2.000 | 120 000 |
Cachés
| Value | Valor predeterminado de Cassandra MI | Recomendación para cargas de trabajo analíticas |
|---|---|---|
| file_cache_size_in_mb | 2 048 | 6144 |
Más recomendaciones
| Value | Valor predeterminado de Cassandra MI | Recomendación para cargas de trabajo analíticas |
|---|---|---|
| commitlog_total_space_in_mb | 8192 | 16 384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Configuración de cliente
Se recomienda aumentar los tiempos de espera del controlador cliente de Cassandra de acuerdo con los tiempos de espera aplicados en el servidor.
Optimización para una latencia baja
Nuestra configuración predeterminada ya es adecuada para cargas de trabajo de baja latencia. Para garantizar el mejor rendimiento de las latencias de cola, se recomienda encarecidamente usar un controlador de cliente que admita la ejecución especulativa y configurar el cliente en consecuencia. Aquí puede encontrar una demostración donde se ilustra cómo funciona esto y cómo habilitar la directiva para el controlador Java V4.
Supervisión de cuellos de botella de rendimiento
Rendimiento de CPU
Al igual que cada sistema de base de datos, Cassandra funciona mejor si el uso de la CPU es alrededor del 50 % y nunca supera el 80 %. Puede ver las métricas de CPU en la pestaña Métricas, dentro de Supervisión, desde el portal:
Si la CPU está permanentemente por encima del 80 % para la mayoría de los nodos, la base de datos se sobrecarga al manifiesto en varios tiempos de espera de cliente. En este escenario, se recomienda realizar las siguientes acciones:
- escalar verticalmente a una SKU con más núcleos de CPU (especialmente si los núcleos son solo 8 o menos).
- escalar horizontalmente agregando más nodos (como se mencionó anteriormente, el número de nodos debe ser múltiplo del factor de replicación).
Si la CPU solo es alta en unos pocos nodos, pero baja para los demás, indica una partición activa y necesita una investigación más detallada.
Nota:
El cambio de SKU se admite a través de Azure Portal, la CLI de Azure y la implementación de plantillas de ARM. Puede implementar o editar la plantilla de ARM y reemplazar la SKU por una de las siguientes:
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Tenga en cuenta que actualmente no se admite la transición entre familias de SKU. Por ejemplo, si actualmente posee una Standard_DS13_v2 y está interesado en actualizar a una SKU mayor, como Standard_DS14_v2, esta opción no está disponible. Sin embargo, puede abrir una incidencia de soporte técnico para solicitar una actualización a la SKU superior.
Rendimiento de disco.
El servicio se ejecuta en discos administrados de Azure P30, lo que permite "IOPS de ráfaga". Se requiere una supervisión cuidadosa cuando se trate de cuellos de botella relacionados con el rendimiento del disco. En este caso, es importante revisar las métricas de IOPS:
Si las métricas muestran una o todas las características siguientes, puede indicar que necesita escalar verticalmente.
- Sistemáticamente mayor o igual que la IOPS base (recuerde multiplicar 5000 IOPS por el número de discos por nodo para obtener el número).
- Sistemáticamente mayor o igual que el número máximo de IOPS permitido para la SKU para las escrituras.
- La SKU admite el almacenamiento en caché (escritura a través de caché) y este número es menor que las IOPS de los discos administrados (este será el límite superior para las IOPS de lectura).
Si solo ve las IOPS elevadas en algunos nodos, es posible que tenga una partición activa y deba revisar los datos por un posible sesgo.
Si las IOPS son inferiores a las admitidas por la SKU elegida, pero superiores o iguales a las IOPS de disco, puede realizar las siguientes acciones:
- Agregar más discos para aumentar el rendimiento. Para aumentar los discos es necesario generar un caso de soporte técnico.
- Escalar verticalmente los centros de datos agregando más nodos.
Si el número de IOPS es superior a lo que admite la SKU, puede hacer lo siguiente:
- escalar verticalmente a otra SKU que admita más IOPS.
- Escalar verticalmente los centros de datos agregando más nodos.
Para más información, consulte Rendimiento de la máquina virtual y del disco.
Rendimiento de la red
En la mayoría de los casos, el rendimiento de red es suficiente. Sin embargo, si suele transmitir datos (por ejemplo, escalar o reducir verticalmente con frecuencia) o hay grandes movimientos de datos de entrada y salida, esto puede convertirse en un problema. Es posible que tenga que evaluar el rendimiento de red de la SKU. Por ejemplo, la SKU Standard_DS14_v2 admite 12 000 Mb/s; compárelo con la entrada o salida de bytes en las métricas:
Si solo ve la red con privilegios elevados para algunos nodos, es posible que tenga una partición activa y necesite revisar los patrones de distribución de datos o acceso para un potencial sesgo.
- Escalar verticalmente hasta otra SKU que admita un número mayor de E/S de red.
- Escalar verticalmente en horizontal el clúster agregando más nodos.
Demasiados clientes conectados
Las implementaciones deben planearse y aprovisionarse para admitir el número máximo de solicitudes paralelas necesarias para la latencia deseada de una aplicación. En una implementación determinada, al introducir más carga en el sistema por encima de un umbral mínimo, aumenta la latencia general. Supervise el número de clientes conectados para asegurarse de que no supera los límites tolerables.
Espacio en disco
En la mayoría de los casos, hay suficiente espacio en disco, ya que las implementaciones predeterminadas están optimizadas para IOPS, lo que conduce a un uso bajo del disco. Sin embargo, se recomienda revisar ocasionalmente las métricas de espacio en disco. Cassandra acumula una gran cantidad de discos y, a continuación, lo reduce cuando se desencadena la compactación. Por lo tanto, es importante revisar el uso del disco durante períodos más largos para establecer tendencias, como la incapacidad de compactación para recuperar espacio.
Nota:
Para garantizar espacio disponible para la compactación, el uso del disco debe mantenerse en torno al 50 %.
Si solo observa este comportamiento en algunos nodos, es posible que tenga una partición activa y deba revisar los patrones de distribución de datos o acceso por un posible sesgo.
- Agregue más discos, pero tenga en cuenta los límites de IOPS impuestos por la SKU.
- Escale verticalmente el clúster en horizontal.
Memoria de JVM
Nuestra fórmula predeterminada asigna la mitad de la memoria de la máquina virtual a la JVM con un límite superior de 31 GB, que, en la mayoría de los casos, es un buen equilibrio entre rendimiento y memoria. Algunas cargas de trabajo, especialmente las que tienen frecuentes lecturas entre particiones o exámenes de intervalos, pueden ser desafíos para la memoria.
En la mayoría de los casos el recolector de elementos no utilizados de Java recupera la memoria de manera eficaz, pero especialmente si la CPU está a menudo por encima del 80 % no quedan suficientes ciclos de CPU para dicho recolector. Por lo tanto, los problemas de rendimiento de la CPU deben solucionarse antes que los problemas de memoria.
Si la CPU se mantiene por debajo del 70 %, y la recolección de elementos no utilizados no puede reclamar memoria, es posible que necesite más memoria de JVM. Este es especialmente el caso si está en una SKU con memoria limitada. En la mayoría de los casos, debe revisar las consultas y la configuración del cliente y reducir fetch_size junto con lo que se elige en limit dentro de la consulta CQL.
Si realmente necesita más memoria, puede hacer lo siguiente:
- Presentarnos una incidencia para aumentar la configuración de memoria de JVM automáticamente.
- Escalar verticalmente a una SKU que tenga más memoria disponible.
Marcadores de exclusión
Ejecutamos reparaciones cada siete días con Reaper, que elimina las filas cuyo TTL ha expirado (denominado "marcador de exclusión"). Algunas cargas de trabajo tienen eliminaciones más frecuentes y aparecen advertencias como Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) en los registros de Cassandra, o incluso errores que indican que no se pudo completar una consulta debido a marcadores de exclusión excesivos.
Una mitigación a corto plazo si las consultas no se completan es aumentar tombstone_failure_threshold en la configuración de Cassandra del valor predeterminado de 100 000 a un valor superior.
Además de esto, se recomienda revisar el TTL en el espacio de claves y ejecutar posiblemente reparaciones a diario para borrar más marcadores de exclusión. Si los TTL son cortos, por ejemplo, menos de dos días, y los flujos de datos entran y se eliminan rápidamente, se recomienda revisar la estrategia de compactación y favorecer Leveled Compaction Strategy. En algunos casos, estas acciones pueden ser un indicio de que se requiere una revisión del modelo de datos.
Advertencias por lotes
Es posible que encuentre esta advertencia en CassandraLogs y posibles errores relacionados:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
En este caso, debe revisar las consultas para mantenerse por debajo del tamaño de lote recomendado. En raras ocasiones y como mitigación a corto plazo, puede aumentar batch_size_fail_threshold_in_kb en la configuración de Cassandra del valor predeterminado de 50 a un valor superior.
Advertencia de partición grande
Es posible que encuentre esta advertencia en CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Esto indica un problema en el modelo de datos. En este artículo de stack overflow se explica con más detalle. Esto puede provocar problemas graves de rendimiento y debe solucionarse.
Optimizaciones especializadas
Compresión
Cassandra permite seleccionar un algoritmo de compresión adecuado cuando se crea una tabla (consulte Compresión). El valor predeterminado es LZ4, que es excelente para el rendimiento y la CPU, pero consume más espacio en el disco. El uso de Zstd (Cassandra 4.0 y versiones posteriores) ahorra aproximadamente un 12 % de espacio con una sobrecarga mínima de CPU.
Optimización del espacio del montón memtable
Nuestro valor predeterminado es usar 1/4 del montón de JVM para memtable_heap_space en cassandra.yaml. En el caso de las SKU orientadas a escritura o en SKU con memoria pequeña, esto puede provocar vaciados frecuentes y sstables fragmentadas, lo que requiere más compactación. En tales casos, podría ser beneficioso aumentarlo a al menos 4048, pero haría falta pruebas comparativas cuidadosas para asegurarse de que otras operaciones (por ejemplo, lecturas) no se vean afectadas.
Pasos siguientes
En este artículo, hemos presentado algunos procedimientos recomendados para un rendimiento óptimo. Ahora puede empezar a trabajar con el clúster: