Comparteix a través de

Diagnóstico y solución de problemas de tiempo de espera de la solicitud del SDK de Azure Cosmos DB para Java v4

  • Article

SE APLICA A: NoSQL

El error HTTP 408 se produce si el SDK no puede completar la solicitud antes de que se agote el límite de tiempo de espera.

Pasos para solucionar problemas

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

Directiva de tiempo de espera de un extremo a otro

Hay escenarios en los que se producirán errores de tiempo de espera de red 408 incluso cuando se hayan implementado todas las soluciones preventivas mencionadas a continuación. Un procedimiento recomendado general para reducir la latencia del final, así como mejorar la disponibilidad en estos escenarios, es implementar una directiva de tiempo de espera de un extremo a otro. La latencia de cola se reduce mediante fracasar rápido y unidades de solicitud y los costos de proceso del lado cliente se reducen al detener los reintentos después 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:

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 ve que las solicitudes se bloquean durante más tiempo o el tiempo de espera se agota con más frecuencia, actualice el SDK de Java v4 a la versión más reciente. NOTA: Se recomienda usar la versión 4.18.0 y versiones posteriores. Para más detalles, consulte las notas de la versión del SDK de Java v4.

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.

Limitación de la conexión

La limitación de la conexión puede deberse a un Límite de conexiones en una máquina host o al agotamiento de puertos SNAT (PAT) de Azure.

Límite de conexiones en una máquina host

Algunos sistemas Linux, como Red Hat, tienen un límite máximo para el número total de archivos abiertos. En Linux, los sockets se implementan como archivos, por lo que este número también limita 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 de 10 000. Para más información, consulte Sugerencias de rendimiento del SDK de Azure Cosmos DB para Java v4.

La disponibilidad de puertos o de sockets puede ser reducida

Cuando se ejecutan en Azure, los clientes que usan el SDK para Java pueden alcanzar el agotamiento de puertos SNAT (PAT) 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 DB). 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 los consejos de rendimiento y use una sola instancia de CosmosClient en toda una aplicación.

Solución 2:

Si no es posible tener una sola instancia de singleton CosmosClient en una aplicación, se recomienda usar las conexiones compartidas entre varios clientes de Azure Cosmos DB a través de la API connectionSharingAcrossClientsEnabled(true) en CosmosClient. Cuando hay varias instancias del cliente de Azure Cosmos DB en la misma máquina virtual Java que interactúan con varias cuentas de Azure Cosmos DB, esta solución permite compartir las conexiones en modo directo, si es posible entre instancias del cliente de Azure Cosmos DB. Tenga en cuenta que, al establecer esta opción, se usará la configuración de conexión (por ejemplo, configuración de tiempo de espera de socket, configuración de tiempo de espera de inactividad) de la primera instancia del cliente en todas las demás instancias.

Clave de partición activa

Azure Cosmos DB 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 en una partición física están consumiendo todas las unidades de solicitud de la partición física por segundo (RU/s). Al mismo tiempo, las RU/s de otras particiones físicas no se usan. Como síntoma, el total de RU/s consumido será inferior al total de RU/s aprovisionadas en la base de datos o el contenedor, pero seguirá viendo la limitación (429s) en las solicitudes de la clave de la partición lógica activa. Use la métrica de consumo normalizado de RU para ver si la carga de trabajo está detectando una partición activa.

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 Acuerdo de Nivel de Servicio de Azure Cosmos DB

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. Si se vuelve a enviar el mismo elemento para crearlo, se producirá 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

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

Pasos siguientes