Compartir a través de

Diagnóstico y solución de problemas de excepciones de "tasa de solicitud demasiado grande" (429)

  • Se aplica a: ✅ NoSQL

Una excepción de "tasa de solicitudes demasiado grande", también conocida como código de error 429, indica que se limita la tasa de las solicitudes en Azure Cosmos DB.

Este artículo contiene las causas conocidas y las soluciones de varios errores de código de estado 429 para la API para NoSQL. Si usa la API para MongoDB, consulte Solución de problemas comunes en API para MongoDB.

Cuando se usa el rendimiento aprovisionado, se establece el rendimiento medido en unidades de solicitud por segundo (RU/s) necesario para la carga de trabajo. Las operaciones de base de datos en el servicio, como lecturas, escrituras y consultas, consumen cierto número de unidades de solicitud (RU). Más información sobre las unidades de solicitud.

En un segundo determinado, si las operaciones consumen más de las unidades de solicitud aprovisionadas, Azure Cosmos DB devuelve una excepción 429. Cada segundo, se restablece el número de unidades de solicitud disponibles para su uso.

Antes de realizar una acción para cambiar las RU/s, es importante comprender la causa principal de la limitación de velocidad y solucionar el problema subyacente.

Sugerencia

Las instrucciones de este artículo se aplican a las bases de datos y los contenedores que usan el rendimiento aprovisionado: escalado automático y rendimiento manual.

Hay diferentes mensajes de error que corresponden a diferentes tipos de excepciones 429:

La tasa de solicitudes es grande

Se trata del escenario más habitual. Ocurre cuando las UR consumidas por las operaciones en los datos superan la cantidad aprovisionada de UR/s. Si utiliza el rendimiento manual, esto ocurre cuando consume más RU/s que el rendimiento manual aprovisionado. Si está utilizando el escalado automático, esto ocurre cuando consume más que el máximo de RU/s aprovisionadas. Por ejemplo, si tiene un recurso aprovisionado con un rendimiento manual de 400 RU/s, verá un 429 cuando consuma más de 400 unidades de solicitud en un solo segundo. Si tiene un recurso aprovisionado con un RU/s máximo de autoescalado de 4000 RU/s (escala entre 400 RU/s y 4000 RU/s), verá respuestas 429 cuando consuma más de 4000 unidades de solicitud en un solo segundo.

Sugerencia

Todas las operaciones se cobran en función del número de recursos que consumen. Estos cargos se miden en unidades de solicitud. Estos cargos incluyen solicitudes que no se completan correctamente debido a errores de aplicación como 400, 412 y 449. Al analizar la limitación o el uso, es recomendable investigar si ha cambiado algún patrón de uso que pueda provocar un aumento de estas operaciones. En concreto, compruebe si hay etiquetas 412 o 449 (conflicto real).

Para más información sobre el rendimiento aprovisionado, consulte Introducción al rendimiento aprovisionado en Azure Cosmos DB.

Paso 1: Comprobación de las métricas para determinar el porcentaje de solicitudes con el error 429

Ver un mensaje de error 429 no significa necesariamente que haya un problema con la base de datos o el contenedor. Un pequeño porcentaje de respuestas 429 es normal, tanto si utiliza el rendimiento manual como el escalado automático, y es una señal de que está maximizando las RU/s que ha aprovisionado.

Investigación

Determine qué porcentaje de las solicitudes para la base de datos o el contenedor ha resultado en respuestas 429, en comparación con el recuento total de solicitudes correctas. Desde su cuenta de Azure Cosmos DB, vaya a Insights>Solicitudes>Total de solicitudes por código de estado. Filtre por una base de datos y un contenedor específicos.

De manera predeterminada, los SDK de cliente de Azure Cosmos DB y las herramientas de importación de datos, como Azure Data Factory y la biblioteca de Bulk Executor, reintentan automáticamente las solicitudes con errores 429. Normalmente, las reintentan hasta nueve veces. Como resultado, aunque podría ver 429 respuestas en las métricas, es posible que estos errores no se hayan devuelto a la aplicación.

Captura de pantalla del gráfico Total de solicitudes por código de estado que muestra el número de solicitudes 429 y 2xx.

En general, para una carga de trabajo de producción, si ve entre el 1 y el 5 % de las solicitudes con respuestas 429 y la latencia de extremo a extremo es aceptable, es una señal positiva de que las RU/s se están utilizando plenamente. No se requiere ninguna acción. De lo contrario, vaya a los siguientes pasos de solución de problemas.

Importante

Este intervalo de 1 a 5% supone que las particiones de la cuenta se distribuyen uniformemente. Si las particiones no se distribuyen uniformemente, la partición problemática podría devolver un gran número de errores 429, mientras que la tasa de errores general podría ser baja.

Si usa el escalado automático, es posible ver respuestas 429 en la base de datos o el contenedor, incluso si las RU/s no se escalaron al máximo de RU/s. Para obtener una explicación, consulte la sección La tasa de solicitudes es elevada con el autoescalado.

Una pregunta común que surge es "¿Por qué veo respuestas 429 en las métricas de Azure Monitor, pero ninguno en mi propia supervisión de aplicaciones?". Si las métricas de Azure Monitor muestran que tiene errores 429, pero no ha visto ninguna en su propia aplicación, esto se debe a que, de manera predeterminada, los SDK de cliente de Azure Cosmos DB automatically retried internally on the 429 responses y la solicitud se ha hecho correctamente en reintentos posteriores. Como resultado, el código de estado 429 no se devuelve a la aplicación. En estos casos, la tasa general de respuestas 429 suele ser mínima y se puede omitir de forma segura, suponiendo que la tasa global esté entre el 429 y entre el 1 % i el 5 % y que la latencia de un extremo a otro sea aceptable para la aplicación.

Paso 2: Determinación de si hay una partición de nivel de acceso frecuente

Una partición de nivel de acceso frecuente surge cuando una o varias claves de partición lógica consumen una cantidad desproporcionada del total de RU/s debido a un mayor volumen de solicitudes. Esto puede deberse a un diseño de clave de partición que no distribuye uniformemente las solicitudes. Da como resultado que muchas solicitudes se dirijan a un pequeño subconjunto de particiones lógicas (que implican particiones físicas) que se vuelven sobrecargadas. Dado que todos los datos de una partición lógica residen en una partición física y las RU/s totales se distribuyen uniformemente entre las particiones físicas, una partición activa puede provocar 429 respuestas y un uso ineficaz del rendimiento.

Estos son algunos ejemplos de estrategias de creación de particiones que conducen a particiones de nivel de acceso frecuente:

  • Tiene un contenedor que almacena datos de dispositivos IoT para una carga de trabajo con gran volumen de escritura que está particionado por date. Todos los datos de una sola fecha residen en la misma partición lógica y física. Dado que todos los datos escritos cada día tienen la misma fecha, esto da lugar a una partición activa todos los días.

    • En su lugar, en este escenario, una clave de partición como id (un GUID o un identificador de dispositivo) o una clave de partición sintética que combina id y date, produce una cardinalidad más alta de los valores y una mejor distribución del volumen de solicitudes.

  • Tiene un escenario multitenant con un contenedor particionado por tenantId. Si un inquilino está mucho más activo que los demás, se produce una partición de nivel de acceso frecuente. Por ejemplo, si el inquilino más grande tiene 100 000 usuarios, pero la mayoría de los inquilinos tienen menos de 10 usuarios, tendrá una partición de nivel de acceso frecuente cuando se particione por tenantID.

    • En el escenario anterior, considere la posibilidad de tener un contenedor dedicado para el inquilino más grande, particionado por una propiedad más granular, como UserId.

Identificación de la partición de nivel de acceso frecuente

Para comprobar si hay una partición activa, vaya a Insights>Rendimiento>Consumo normalizado de RU (%) por PartitionKeyRangeID. Filtre por una base de datos y un contenedor específicos.

Cada objeto PartitionKeyRangeId se asigna a una partición física. Si hay un partitionKeyRangeId que tiene un consumo de RU normalizado mucho mayor que otros (por ejemplo, uno está constantemente en 100%, pero otros están en 30% o menos), puede ser un signo de una partición activa. Para obtener más información sobre la métrica de consumo de RU normalizado, consulte cómo supervisar RU/s normalizadas para un contenedor de Azure Cosmos DB o una cuenta.

Captura de pantalla que muestra el gráfico Consumo normalizado de RU por PartitionKeyRangeId con una partición activa.

Para ver qué claves de particiones lógicas consumen la mayor cantidad de RU/s, use Los registros de diagnóstico de Azure. Esta consulta de ejemplo suma el total de unidades de solicitud consumidas por segundo en cada clave de partición lógica.

Importante

La habilitación de los registros de diagnóstico conlleva un cargo independiente para el servicio Log Analytics, que se factura en función del volumen de datos ingeridos. Se recomienda activar los registros de diagnóstico durante un período limitado de tiempo para la depuración y desactivarlos cuando ya no sean necesarios. Para más información, consultePrecios de Azure Monitor.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Esta salida de ejemplo muestra que, en un minuto determinado, la clave de partición lógica con el valor Contoso consumió alrededor de 12 000 RU/s, mientras que la clave de partición lógica con el valor Fabrikam consumió menos de 600 RU/s. Si este patrón es continuo durante el período de tiempo en el que se produjo la limitación de tasa, indica una partición de nivel de acceso frecuente.

Captura de pantalla de los resultados que muestran las claves de partición lógicas que consumen la mayoría de las unidades de solicitud por segundo.

Sugerencia

En cualquier carga de trabajo, hay una variación natural en el volumen de solicitudes entre particiones lógicas. Debe determinar si la partición de nivel de acceso frecuente se debe a un sesgo fundamental debido a la elección de la clave de partición (que puede requerir cambiar la clave) o a un pico temporal debido a una variación natural en los patrones de carga de trabajo.

Revise las instrucciones sobre cómo elegir una buena clave de partición.

Si hay un alto porcentaje de solicitudes con limitación de tasa y no hay ninguna partición de nivel de acceso frecuente:

Si hay un alto porcentaje de solicitudes con limitación de tasa y hay una partición de nivel de acceso frecuente subyacente:

  • A largo plazo, para obtener el mejor costo y rendimiento, considere la posibilidad de cambiar la clave de partición. La clave de partición no se puede actualizar localmente, por lo que es necesario migrar los datos a un nuevo contenedor con una clave de partición diferente. Azure Cosmos DB admite una herramienta de migración de datos en directo para este propósito.
  • A corto plazo, puedes aumentar temporalmente las RU/s generales del recurso para permitir un mayor rendimiento en la partición caliente. No se recomienda como una estrategia a largo plazo, ya que conduce a un aprovisionamiento excesivo de RU/s y un costo mayor.
  • A corto plazo, puede redistribuir el rendimiento entre las particiones (vista previa) para asignar más RU/s a la partición física que está activa. Esto solo se recomienda cuando la partición física activa sea predecible y consistente.

Sugerencia

Al aumentar el rendimiento, la operación de escalado vertical se completa de forma instantánea o requiere hasta 5-6 horas para completarse, en función del número de RU/s a las que quiera escalar verticalmente. Si desea saber el mayor número de RU/s que puede configurar sin desencadenar la operación de escalado vertical asincrónico (lo que requiere que Azure Cosmos DB aprovisione más particiones físicas), multiplique el número de identificadores de rango de clave de partición distintos (PartitionKeyRangeIds) por 100,000 RU/s. Por ejemplo, si tiene aprovisionadas 30 000 RU/s y cinco particiones físicas (6000 RU/s asignadas por partición física), puede aumentar a 50 000 RU/s (10 000 RU/s por partición física) en una operación de escalado vertical instantánea. Aumentar a >50 000 RU/s requerirá una operación asincrónica de escalado vertical. Para más información, consulte Procedimientos recomendados para escalar el rendimiento aprovisionado (RU/s).

Paso 3: Determinación de qué solicitudes devuelven respuestas 429

Investigación de solicitudes con respuestas 429

Use Registros de diagnóstico de Azure para identificar qué solicitudes devuelven respuestas 429 y cuántas RU consumieron. Esta consulta de ejemplo se agrega en el nivel de minuto.

Importante

La habilitación de los registros de diagnóstico conlleva un cargo independiente para el servicio Log Analytics, que se factura en función del volumen de datos ingeridos. Se recomienda activar los registros de diagnóstico durante un período limitado de tiempo para la depuración y desactivarlos cuando ya no sean necesarios. Para más información, consultePrecios de Azure Monitor.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Por ejemplo, esta salida de ejemplo muestra que, cada minuto, el 30 % de las solicitudes de creación de documentos tenían una limitación de velocidad, y cada solicitud consumía una media de 17 RU.

Captura de pantalla que muestra solicitudes con el código 429 en los registros de diagnóstico.

Uso de Azure Cosmos DB Capacity Planner

Puede usar la herramienta de planeamiento de capacidad de Azure Cosmos DB para comprender cuál es el mejor rendimiento aprovisionado en función de la carga de trabajo (volumen y tipo de operaciones y tamaño de los documentos). Puede personalizar aún más los cálculos proporcionando datos de ejemplo para obtener una estimación más precisa.

Respuestas 429 en las solicitudes de creación, reemplazo o upsert de documento

De manera predeterminada, en la API para NoSQL, todas las propiedades se indexan de forma predeterminada. Ajuste la directiva de indexación para indexar solo las propiedades necesarias. Esto reduce las RU necesarias por cada operación de creación de documentos, lo que reduce la probabilidad de ver 429 respuestas o permite lograr operaciones más altas por segundo para la misma cantidad de RU/s aprovisionadas.

Respuestas 429 en solicitudes de consulta de documento

Siga las instrucciones para solucionar problemas de consultas con un alto coste de RU.

Respuestas 429 en la ejecución de procedimientos almacenados

Los procedimientos almacenados están previstos para las operaciones que requieren transacciones de escritura en un valor de clave de partición. No se recomienda usar procedimientos almacenados para un gran número de operaciones de lectura o consulta. Para obtener el mejor rendimiento, estas operaciones de lectura o consulta deben realizarse en el lado cliente, mediante los SDK de Azure Cosmos DB.

La tasa de solicitudes es grande con el escalado automático

Todas las instrucciones de este artículo se aplican tanto al rendimiento manual como al de escalado automático.

Al usar el escalado automático, una pregunta común que surge es "¿Todavía es posible ver 429 respuestas con escalabilidad automática?"

La respuesta es sí. Hay dos escenarios principales en los que esto puede ocurrir:

Escenario 1: cuando las RU/s consumidas generales superan las RU/s máximas de la base de datos o contenedor, el servicio limita las solicitudes en consecuencia. Esto es análogo a superar el rendimiento general aprovisionado manual de una base de datos o contenedor.

Escenario 2: Si hay una partición activa, es decir, un valor de clave de partición lógica que tiene una cantidad desproporcionadamente mayor de solicitudes en comparación con otros valores de clave de partición, es posible que la partición física subyacente supere su presupuesto de RU/s. Como procedimiento recomendado, para evitar las particiones frecuentes, elija una buena clave de partición que dé lugar a una distribución uniforme tanto del almacenamiento como del rendimiento. Esto es similar a cuando hay una partición frecuente cuando se usa el rendimiento manual.

Por ejemplo, si selecciona la opción de rendimiento de 20 000 RU por segundo máximas y tiene 200 GB de almacenamiento, con cuatro particiones físicas, cada partición física se puede escalar automáticamente hasta 5000 RU por segundo. Si había una partición frecuente en una clave de partición lógica determinada, verá varios códigos de estado de respuestas 429 cuando la partición física subyacente en la que reside supera las 5000 RU por segundo, es decir, supera el 100 % de la utilización normalizada.

Siga las instrucciones del Paso 1, Paso 2 y Paso 3 para depurar estos escenarios.

Otra pregunta común que surge es: ¿Por qué se normaliza el consumo de RU al 100 %, pero el escalado automático no se escaló al máximo de RU/s?

Esto suele ocurrir para cargas de trabajo que tienen picos de uso temporales o intermitentes. Cuando se usa el escalado automático, Azure Cosmos DB solo escala las RU/s al rendimiento máximo cuando el consumo de RU normalizado es del 100 % durante un período de tiempo continuo y sostenido en un intervalo de 5 segundos. Esto se hace para garantizar que la lógica de escalado sea rentable para el usuario, ya que garantiza que los picos únicos e momentáneos no conducen a un escalado innecesario y un costo mayor. Cuando hay picos momentáneos, el sistema normalmente se escala verticalmente hasta un valor mayor que el escalado anterior a RU/s, pero menor que el número máximo de RU/s. Para más información, consulte Consumo de RU normalizado y escalabilidad automática.

Limitación de tasa en las solicitudes de metadatos

La limitación de la tasa de metadatos puede producirse cuando se realizan un gran volumen de operaciones de metadatos en bases de datos o contenedores. Las operaciones de metadatos incluyen:

  • Crear, leer, actualizar o eliminar un contenedor o una base de datos
  • Enumeración de bases de datos o contenedores en una cuenta de Azure Cosmos DB
  • Consultar las ofertas para ver el rendimiento aprovisionado actual

Hay un límite de RU reservado por el sistema para estas operaciones, por lo que aumentar las RU/s aprovisionadas de la base de datos o el contenedor no tiene ningún efecto y no se recomienda. Consulte Límites del servicio del plano de control.

Investigación

Vaya a Insights>Sistema>Solicitudes de metadatos por código de estado. Filtre por una base de datos y un contenedor específicos, si lo desea.

Captura de pantalla de las solicitudes de metadatos por gráfico de código de estado en Insights.

  • Si la aplicación necesita realizar operaciones de metadatos, considere la posibilidad de implementar una directiva de retroceso para enviar estas solicitudes con una tasa menor.

  • Utilice instancias de cliente estáticas de Azure Cosmos DB. Cuando se inicializa DocumentClient o CosmosClient, el SDK de Azure Cosmos DB captura los metadatos sobre la cuenta, incluida la información sobre el nivel de coherencia, las bases de datos, los contenedores, las particiones y las ofertas. Esta inicialización puede consumir un gran número de RU y debe realizarse con poca frecuencia. Use una única instancia de DocumentClient y úsela durante toda la vigencia de la aplicación.

  • Almacene en caché los nombres de las bases de datos y los contenedores. Durante el inicio, recupere los nombres de las bases de datos y los contenedores de la configuración o almacénelos en memoria caché. Las llamadas como ReadDatabaseAsync/ReadDocumentCollectionAsync o CreateDatabaseQuery/CreateDocumentCollectionQuery generan llamadas de metadatos al servicio, que consumen desde el límite de RU reservado por el sistema. Estas operaciones deben realizarse raramente.

Limitación de tasa debido a un error transitorio del servicio

Este error 429 se devuelve cuando la solicitud encuentra un error de servicio transitorio. Aumentar las RU/s en la base de datos o en el contenedor no tiene ningún efecto y no es recomendado.

Intente de nuevo la solicitud. Si el error persiste durante varios minutos, abra una incidencia de soporte técnico desde Azure Portal.

Pasos siguientes

  • Last updated on