Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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. Esta característica 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 niveles de producto
Azure admite tres zonas de disponibilidad en la mayoría de las regiones. Azure Managed Instance para Apache Cassandra 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 el número de nodos. Por ejemplo, use 3, 6, 9, etc.
Azure usa un RAID 0 sobre el número de discos que aprovisiona. Para obtener las operaciones de entrada y salida óptimas por segundo (IOPS), compruebe el número máximo de IOPS en el nivel de producto que eligió junto con las IOPS de un disco P30. Por ejemplo, el Standard_DS14_v2 nivel de producto admite 51 200 IOPS sin almacenar en caché. Un único disco P30 tiene un rendimiento base de 5000 IOPS. Cuatro discos conducen 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 en el nivel de producto y el número de discos. La prueba comparativa es especialmente importante para los niveles de producto con solo ocho núcleos. Nuestra investigación muestra que las CPU de ocho núcleos funcionan solo para las cargas de trabajo menos exigentes. La mayoría de las cargas de trabajo necesitan un mínimo de 16 núcleos para realizar correctamente.
Cargas de trabajo analíticas frente a transaccionales
Las cargas de trabajo transaccionales suelen necesitar un centro de datos optimizado para una latencia baja. 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, ustedes quieren centros de datos separados con:
- Una optimizada para baja latencia.
- Una optimizada para cargas de trabajo analíticas.
Optimización para cargas de trabajo analíticas
Se recomienda aplicar la siguiente cassandra.yaml configuración para cargas de trabajo analíticas. Para obtener más información sobre cómo aplicar estas opciones de configuración, consulte Actualización de la configuración de Cassandra.
Tiempos de expiración
| Importancia | 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 |
Memorias caché
| Importancia | Valor predeterminado de Cassandra MI | Recomendación para cargas de trabajo analíticas |
|---|---|---|
file_cache_size_in_mb |
2 048 | 6144 |
Más recomendaciones
| Importancia | Valor predeterminado de Cassandra MI | Recomendación para cargas de trabajo analíticas |
|---|---|---|
commitlog_total_space_in_mb |
8,192 | 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 para las latencias de cola, se recomienda encarecidamente usar un controlador de cliente que admita la ejecución especulativa y que configure el cliente en consecuencia. En el caso de un controlador de Java V4, una demostración muestra cómo funciona este proceso y cómo habilitar la directiva en este ejemplo.
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 %. Para ver las métricas de CPU, en Azure Portal, en la sección Supervisión , abra la pestaña Métricas .
Para obtener una vista de CPU realista, agregue un filtro y use Usage kind=usage_idle para dividir la propiedad. Si este valor es inferior al 20 %, aplique la división para obtener el uso de todos los tipos de uso.
Si la CPU está permanentemente por encima del 80 % para la mayoría de los nodos, la base de datos se sobrecarga, que se manifiesta en varios tiempos de espera de cliente. En este escenario, se recomienda realizar las siguientes acciones:
- Escale verticalmente a un nivel de producto con más núcleos de CPU, especialmente si los núcleos son solo 8 o menos.
- Escale horizontalmente agregando más nodos. Como se mencionó anteriormente, el número de nodos debe ser un múltiplo del factor de replicación.
Si la CPU es alta solo para unos pocos nodos, pero baja para las demás, indica una partición activa. Este escenario necesita una investigación más detallada.
El cambio del nivel de producto se admite mediante Azure Portal, la CLI de Azure y la implementación de la plantilla de Azure Resource Manager (plantilla de ARM). Puede implementar o editar una plantilla de ARM y reemplazar el nivel de producto por uno de los siguientes valores:
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
Actualmente, no se admite la transición entre familias de productos. Por ejemplo, si actualmente posee un Standard_DS13_v2 y desea actualizar a un producto más grande, como Standard_DS14_v2, esta opción no está disponible. Abra un ticket de soporte para solicitar una actualización a un producto de nivel 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, es posible que tenga que escalar verticalmente:
- Las métricas son constantemente mayores o iguales que las IOPS base. Recuerde multiplicar 5000 IOPS por el número de discos por nodo para obtener el número.
- Las métricas son constantemente mayores o iguales que las IOPS máximas permitidas para el nivel de producto para las escrituras.
- Su nivel de producto admite almacenamiento en caché (caché de escritura directa), y este número es menor que las IOPS de los discos administrados. Este valor es el límite superior para las IOPS de lectura.
Si ve las IOPS elevadas solo para unos pocos nodos, es posible que tenga una partición caliente y necesite revisar los datos para identificar un posible sesgo.
Si los IOPS son inferiores a lo que admite el nivel de producto, pero mayor o igual que el IOPS de disco, realice las siguientes acciones:
- Agregue más nodos para escalar verticalmente los centros de datos.
Si su IOPS alcanza el límite superior que admite el nivel de producto, puede hacer lo siguiente:
- Escale verticalmente a otro nivel de producto que admita más IOPS.
- Agregue más nodos para escalar verticalmente los centros de datos.
Para más información, consulte Rendimiento de disco y máquina virtual.
Rendimiento de la red
Normalmente, el rendimiento de la red es suficiente. Si transmite datos con frecuencia, como el escalado horizontal hacia arriba/hacia abajo frecuente, o hay grandes movimientos de datos de ingreso y egreso, este rendimiento puede convertirse en un problema. Es posible que tenga que evaluar el rendimiento de la red de su categoría de producto. Por ejemplo, el Standard_DS14_v2 nivel de producto admite 12 000 Mb/s. Compara este valor con el byte entrante/saliente de las métricas.
Si ve la red con privilegios elevados solo para unos pocos nodos, es posible que tenga una partición activa. Revise sus patrones de distribución y acceso de datos para identificar un posible sesgo.
- Escalar verticalmente a un nivel diferente de producto aumentando el soporte para más E/S de red.
- Escalar verticalmente en horizontal el clúster agregando más nodos.
Demasiados clientes conectados
Planee y aprovisione implementaciones para admitir el número máximo de solicitudes paralelas necesarias para la latencia deseada de una aplicación. Para una implementación específica, 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 esta situación no supera los límites tolerables.
Espacio en disco
En la mayoría de los casos, hay suficiente espacio en disco. Las implementaciones predeterminadas están optimizadas para IOPS, lo que da lugar a un uso bajo del disco. Sin embargo, se recomienda revisar ocasionalmente las métricas de espacio en disco. Cassandra acumula numerosos discos y, a continuación, los reduce cuando se desencadena la compactación. Es importante revisar el uso del disco durante períodos más largos para establecer tendencias, como cuando la compactación no puede recuperar el espacio.
Nota:
Para garantizar el espacio disponible para la compactación, mantenga el uso del disco en alrededor del 50 %.
Si observa este comportamiento solo en algunos nodos, es posible que tenga una partición caliente. Revise sus patrones de distribución y acceso de datos para identificar un posible sesgo.
- Agregue más discos, pero tenga en cuenta los límites de IOPS impuestos por el nivel de producto.
- Escala horizontalmente el clúster.
Memoria de JVM
Nuestra fórmula predeterminada asigna la mitad de la memoria de la máquina virtual a la máquina virtual Java (JVM) con un límite superior de 31 GB. En la mayoría de los casos, este enfoque es un buen equilibrio entre el rendimiento y la memoria. Algunas cargas de trabajo, especialmente las que tienen lecturas frecuentes entre particiones o exploraciones de rango, podrían presentar desafíos de memoria.
En la mayoría de los casos, el recolector de elementos no utilizados de Java recupera la memoria de forma eficaz. Si la CPU suele estar por encima del 80 %, no hay suficientes ciclos de CPU para el recolector de elementos no utilizados. Solucione los problemas de rendimiento de la CPU antes de comprobar los problemas de memoria.
Si la CPU mantiene el puntero por debajo del 70 % y la recolección de elementos no utilizados no puede reclamar memoria, es posible que necesite más memoria JVM. Es posible que sea necesario más memoria JVM si se encuentra en un nivel de producto 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 en la consulta del lenguaje de consulta de Cassandra (CQL).
Si necesita más memoria, puede hacer lo siguiente:
- Escale verticalmente a un nivel de producto que tenga más memoria disponible.
Marcadores de exclusión
Ejecutamos reparaciones cada siete días con Reaper, que elimina las filas cuyo tiempo de vida (TTL) ha expirado. Estas filas se denominan lápidas. Algunas cargas de trabajo eliminan con más frecuencia y muestran advertencias como Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) en los registros de Cassandra. Algunos errores indican que no se pudo cumplir una consulta debido a un exceso de lápidas.
Una mitigación a corto plazo si las consultas no se cumplen es aumentar el valor tombstone_failure_threshold de la configuración de Cassandra de 100 000 a un valor superior.
También se recomienda revisar el TTL en el espacio de claves y ejecutar reparaciones diariamente para borrar más lápidas. Si los TTL son cortos (por ejemplo, menos de dos días) y los datos fluyen y se eliminan rápidamente, le recomendamos que revise la estrategia de compactación y favorezca Leveled Compaction Strategy. En algunos casos, estas acciones pueden indicar que se requiere una revisión del modelo de datos.
Advertencias por lotes
Es posible que encuentre la siguiente advertencia en CassandraLogs y posibles errores relacionados:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Revise las consultas para que permanezcan por debajo del tamaño de lote recomendado. En raras ocasiones y como mitigación a corto plazo, aumente batch_size_fail_threshold_in_kb la configuración de Cassandra del valor predeterminado de 50 a un valor superior.
Advertencia de partición grande
Es posible que encuentre la siguiente advertencia en CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Este mensaje indica un problema en el modelo de datos. Para más información, consulte este artículo de Stack Overflow. Este problema puede causar 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. 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 Zstandard (Cassandra 4.0 y versiones posteriores) ahorra aproximadamente 12% espacio con una sobrecarga mínima de CPU.
Optimizar el espacio del montón de memoria
El valor predeterminado es usar un cuarto del montón de JVM para memtable_heap_space en el archivo cassandra.yaml. En el caso de las aplicaciones orientadas a escritura o en los niveles de producto con pequeñas cantidades de memoria, este problema puede dar lugar a un vaciado frecuente y un sstables fragmentado, lo que requiere más compactación. Aumentar a al menos 4.048 podría ser bueno. Este enfoque requiere una prueba comparativa cuidadosa para asegurarse de que otras operaciones (por ejemplo, lecturas) no se vean afectadas.