Compartir vía

Diagnosticar y resolver excepciones de tiempo de espera en solicitudes del SDK de Java v4 para NoSQL de Azure Cosmos DB

  • Se aplica a: ✅ NoSQL

El error HTTP 408 se produce si el kit de desarrollo de software (SDK) no ha podido completar la solicitud antes de que se agotara el tiempo de espera.

Pasos para solucionar problemas

La siguiente lista contiene las causas y soluciones conocidas para las excepciones de tiempo de espera de solicitud.

Política integral de tiempo de espera

Hay escenarios en los que se producen errores de tiempo de espera de red 408 incluso cuando se implementan todas las soluciones preventivas aquí mencionadas. Un procedimiento general recomendado para reducir la latencia de cola y mejorar la disponibilidad en estos escenarios es implementar una política de tiempo de espera de extremo a extremo. La latencia de cola se reduce al acelerar la detección de errores, y las unidades de solicitud y los costos de procesamiento del lado del cliente se reducen al detener los reintentos tras el agotamiento del tiempo de espera. La duración del tiempo de espera se puede establecer en CosmosItemRequestOptions. A continuación, se pueden pasar las opciones a cualquier solicitud enviada a Azure Cosmos DB para NoSQL:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();

CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);

container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Problemas existentes

Si observa que las solicitudes se bloquean por períodos prolongados o se agotan los tiempos de espera de forma más frecuente, actualice el SDK de Java v4 a la versión más reciente. NOTA: Se recomienda encarecidamente usar la versión 4.18.0 y posteriores. Consulte las notas de la versión del SDK de Java v4 para obtener más detalles.

Uso elevado de CPU

El uso elevado de la CPU es el caso más común. Para lograr una latencia óptima, el uso de la CPU debe ser de aproximadamente el 40 por ciento. Use 10 segundos como intervalo para supervisar el uso máximo de la CPU (no el promedio). Los picos de CPU son más habituales con consultas entre particiones en las que se pueden realizar varias conexiones para una sola consulta.

Solución

La aplicación cliente que usa el SDK se debe escalar vertical u horizontalmente.

Regulación de velocidad de conexión

La limitación de conexiones puede producirse debido a un límite de conexión en un equipo host o al agotamiento de puertos de traducción de direcciones de red de origen (SNAT) de Azure.

Límite de conexión en un equipo host

Algunos sistemas Linux, como Red Hat, tienen un límite superior en el número total de archivos abiertos. Los sockets en Linux se implementan como archivos, por lo que este número limita también el número total de conexiones. Ejecute el siguiente comando.

ulimit -a

Solución

El número máximo permitido de archivos abiertos, que se identifican como nofile, debe ser al menos 10 000 o más. Para más información, consulte las sugerencias de rendimiento del SDK de Java v4 de Azure Cosmos DB para NoSQL.

La disponibilidad de puertos o de sockets puede ser reducida

Cuando la solución se ejecuta en Azure, los clientes que usan el SDK de Java pueden alcanzar el agotamiento de puertos SNAT de Azure.

Solución 1

Si utiliza máquinas virtuales de Azure, siga la guía de agotamiento de los puertos SNAT.

Solución 2

Si utiliza Azure App Service, siga la guía de solución de problemas de errores de conexión y use el diagnóstico de App Service.

Solución 3

Si usa Azure Functions, compruebe que está siguiendo la recomendación para Azure Functions del mantenimiento de los clientes Singleton o estáticos para todos los servicios implicados (incluido Azure Cosmos  for NoSQL). Compruebe los límites de servicio según el tipo y el tamaño del hospedaje de la aplicación de funciones.

Solución 4

Si usa un Proxy HTTP, asegúrese de que pueda admitir el número de conexiones configuradas en el SDK de GatewayConnectionConfig. En caso contrario, se encontrará con problemas de conexión.

Creación de varias instancias de cliente

La creación de varias instancias de cliente podría provocar problemas de tiempo de espera y la contención de la conexión.

Solución 1

Siga las sugerencias de rendimiento y use una única instancia de CosmosClient en toda una aplicación.

Solución 2

Si no se puede tener singleton CosmosClient en una aplicación, se recomienda compartir conexiones entre varios clientes de Azure Cosmos DB para NoSQL a través de esta API connectionSharingAcrossClientsEnabled(true) en CosmosClient. Cuando tiene varias instancias del cliente que interactúan con varias cuentas, habilitar esta configuración permite el uso compartido de conexiones en modo directo . Este modo solo está habilitado si el uso compartido de conexiones es posible entre instancias de Azure Cosmos DB para el cliente NoSQL. Tenga en cuenta que, al establecer esta opción de uso compartido, se utiliza la configuración de conexión (por ejemplo, configuración de tiempo de espera del socket, configuración de tiempo de espera de inactividad) del primer cliente para todas las demás instancias de cliente.

Clave de partición activa

Azure Cosmos DB for NoSQL distribuye el rendimiento general aprovisionado de forma uniforme entre las particiones físicas. Cuando hay una partición activa, una o varias claves de partición lógica de una partición física consumen todas las unidades de solicitud por segundo (RU/s) de la partición física. Al mismo tiempo, las RU/s de otras particiones físicas no se usan. Como síntoma, las RU/s totales consumidas son menores que las RU/s aprovisionadas en general en la base de datos o el contenedor, pero sigue viendo restricciones (errores 429) en las solicitudes contra la clave de partición lógica caliente. Utilice la métrica Consumo de RU normalizado para ver si la carga de trabajo está encontrando una partición caliente.

Solución

Elija una buena clave de partición que distribuya uniformemente el volumen y el almacenamiento de solicitudes. Obtenga más información acerca de cómo cambiar la clave de partición.

Alto grado de simultaneidad

La aplicación tiene un alto nivel de simultaneidad, lo que puede provocar contención en el canal.

Solución

La aplicación cliente que usa el SDK se debe escalar vertical u horizontalmente.

Solicitudes o respuestas de gran tamaño

Un gran número de solicitudes o respuestas puede provocar un bloqueo de encabezado de línea en el canal y agravar la contención, incluso con un nivel relativamente bajo de simultaneidad.

Solución

La aplicación cliente que usa el SDK se debe escalar vertical u horizontalmente.

La tasa de errores está dentro del contrato de nivel de servicio (SLA) de Azure Cosmos DB para NoSQL.

La aplicación debe ser capaz de controlar los errores transitorios y volver a intentarlo cuando sea necesario. Las excepciones 408 no se reintentan porque, en las rutas de acceso de creación, no es posible saber si el servicio creó el elemento. Enviar de nuevo el mismo elemento para crear provoca una excepción de conflicto. La lógica de negocios de las aplicaciones de usuario podría personalizarse para administrar los conflictos, lo que produciría errores por la ambigüedad de un elemento existente frente al conflicto de un reintento de creación.

La tasa de errores infringe el Acuerdo de Nivel de Servicio de Azure Cosmos DB for NoSQL SLA

Póngase en contacto con el soporte técnico de Azure.

Contenido relacionado

  • Last updated on