¿Cuál es la naturaleza de Cassandra "write timeout"?

Question

Estoy ejecutando un programa de escritura pesada (picos de 10 hilos a 25K / seg) en un clúster Cassandra 3.5 de 24 nodos en AWS EC2 (cada host es del tipo c4.2xlarge: 8 vcore y 15G ram)

De vez en cuando mi cliente Java, usando el controlador DataStax 3.0.2, obtenía el problema de tiempo de espera de escritura:

com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency TWO (2 replica were required but only 1 acknowledged the write)
at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:73)
at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:26)
at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:64)

El error ocurre con poca frecuencia y de una manera muy impredecible. Hasta ahora, no puedo vincular los fallos a nada específico (por ejemplo, tiempo de ejecución del programa, tamaño de datos en el disco, hora del día, indicadores de carga del sistema como CPU, memoria, métricas de red). Sin embargo, realmente está perturbando nuestra operaciones.

Estoy tratando de encontrar la causa raíz del problema. Buscando opciones en línea, estoy un poco abrumado por todos los clientes potenciales, como

• Cambiando "write_request_timeout_in_ms" en "cassandra.yaml" (ya cambiado a 5 segundos)
• Usar "RetryPolicy" adecuada para mantener la sesión en funcionamiento (ya que usa DowngradingConsistencyRetryPolicy en un nivel de consistencia de nivel de sesión ONE)
• Cambiar el tamaño de la memoria caché, el tamaño del almacenamiento dinámico, etc., nunca probé esos b / c, hay buenas razones para descartarlos como causa principal.

Una cosa es realmente confusa durante mi investigación es que estoy obteniendo este error de un clúster completamente replicado con muy pocos eventos ClientRequest.timeout.write:

• Tengo un cluster de 24 nodos totalmente replicado que abarca 5 regiones de aws. Cada región tiene al menos 2 copias de los datos
• Mi programa ejecuta el nivel de coherencia UNO en el nivel de la sesión (Creador de clúster con QueryOption)
• Cuando ocurrió el error, nuestro gráfico de Grafito registró no más de tres (3) contratiempos del host, es decir, tener los valores de Cassandra.ClientRequest.Write.Timeouts.Count
• Ya configuré write_timeout en 5 segundos. La red es bastante rápida (usando iperf3 para verificar) y estable

En papel, la situación debería estar dentro del rango de seguridad de Cassandra. ¿Pero por qué mi programa aún falló? ¿Los números no son lo que parecen ser?