Compartir a través de

Cómo solucionar problemas de latencia y tiempos de espera en Azure Cache para Redis

  • Se aplica a: ✅ Azure Cache for Redis

Una operación de cliente de Azure Cache for Redis que no recibe una respuesta oportuna puede provocar una latencia alta o una excepción de tiempo de espera. En este artículo se explica cómo solucionar problemas comunes que pueden dar lugar a tiempos de espera y latencia elevados.

Una operación podría experimentar problemas o agotar el tiempo de espera en varias fases. El origen del problema ayuda a determinar la causa y la mitigación. Este artículo se divide en problemas del lado cliente y del lado servidor.

Problemas del lado cliente

Problemas del lado servidor

Solución de problemas de lado cliente

Los siguientes problemas del lado cliente pueden afectar a la latencia y al rendimiento y a los tiempos de espera.

Número elevado de conexiones de cliente

Se pueden producir errores en las solicitudes de cliente para las conexiones de cliente más allá del máximo de la memoria caché. Las conexiones de cliente elevadas también pueden provocar una carga elevada del servidor al procesar intentos repetidos de reconexión.

Un número elevado de conexiones de cliente puede indicar una pérdida de conexión en el código de cliente. Es posible que las conexiones no se estén reutilizando o cerrando correctamente. Revise el uso de conexiones en el código de cliente.

Si las conexiones altas son todas las conexiones cliente legítimas y necesarias, es posible que tenga que actualizar la memoria caché a un tamaño con un límite de conexión superior. Compruebe si la métrica Max aggregate for Connected Clients (Agregado máximo para clientes conectados ) está cerca o superior al número máximo de conexiones permitidas para el tamaño de la memoria caché. Para más información sobre el dimensionamiento por conexión de cliente, vea Rendimiento de Azure Cache para Redis.

Uso elevado de CPU en hosts de cliente

El uso elevado de la CPU del cliente indica que el sistema no puede seguir el ritmo del trabajo asignado. Incluso si la memoria caché envía la respuesta rápidamente, es posible que el cliente no pueda procesar la respuesta lo suficientemente rápido. Es mejor mantener la CPU del cliente en menos de 80%.

Para mitigar la utilización de la CPU elevada de un cliente:

  • Investigue la causa de los picos de CPU.
  • Actualice el cliente a un tamaño mayor de máquina virtual (VM) con más capacidad de CPU.

Supervise el uso de cpu en todo el sistema del cliente mediante métricas disponibles en Azure Portal o a través de contadores de rendimiento en la máquina virtual. Compruebe la métrica Errores (Tipo: ClientesNoResponsivos) para determinar si los hosts cliente pueden procesar las respuestas del servidor de Redis a tiempo.

Tenga cuidado de no supervisar la CPU del proceso, ya que un único proceso puede tener un uso bajo de CPU, pero la CPU de todo el sistema puede ser alta. Busque picos de uso de CPU que correspondan a tiempos de espera. La CPU alta también puede provocar valores altos in: XXX en los mensajes de error de timeoutException. Consulte la sección Configuración del grupo de subprocesos y ráfagas de tráfico para obtener un ejemplo.

StackExchange.Redis 1.1.603 y versiones posteriores incluyen la métrica local-cpu en mensajes de error de timeoutException. Asegúrese de usar la versión más reciente del paquete NuGet StackExchange.Redis, ya que los errores se corrigen periódicamente para que el código sea más resistente a los tiempos de espera. Para obtener más información, consulte Investigación de timeout excepciones en StackExchange.Redis.

Valores de clave grandes

Puede usar el comando redis-cli --bigkeys para buscar claves grandes en la memoria caché. Para obtener más información sobre redis-cli, la interfaz de la línea de comandos de Redis, consulte CLI de Redis.

Para mitigar el problema:

  • Aumente el tamaño de la máquina virtual para obtener mayores funcionalidades de ancho de banda. Más ancho de banda en la máquina virtual cliente o servidor podría reducir los tiempos de transferencia de datos para respuestas más grandes. Compare el uso de red actual en ambas máquinas virtuales con los límites de los tamaños de máquina virtual actuales. Más ancho de banda solo en el servidor o en el cliente puede no ser suficiente.

  • Aumente el número de objetos de conexión que usa la aplicación. Use un enfoque round robin para realizar solicitudes a través de objetos de conexión distintos. Para obtener información sobre el uso de varias claves y valores más pequeños, vea Consideración de más claves y valores más pequeños.

Presión de memoria en el cliente de Redis

La presión de memoria en el cliente puede provocar problemas de rendimiento que retrasan el procesamiento de respuestas de caché. Cuando se produce presión de memoria, el sistema podría paginar los datos en el disco. Estos errores de página hacen que el sistema se ralentice considerablemente.

Para detectar presión de memoria en el cliente:

  • Supervise el uso de memoria en la máquina virtual para asegurarse de que no supera la memoria disponible.
  • Supervise el contador de rendimiento Page Faults/Sec del cliente. Durante el funcionamiento normal, la mayoría de los sistemas tienen algunos errores de página. Los picos de errores de página que corresponden con los tiempos de expiración de solicitudes pueden indicar la presión de memoria.

Para mitigar la presión de memoria alta en el cliente:

  • Investigue los patrones de uso de memoria para reducir el consumo de memoria en el cliente.
  • Actualice la máquina virtual del cliente a un tamaño mayor con más memoria.

Limitación del ancho de banda de red en los hosts de cliente

En función de su arquitectura, las máquinas cliente pueden tener limitaciones en la disponibilidad del ancho de banda de red. Si el cliente supera el ancho de banda disponible sobrecargando la capacidad de red, los datos no se procesan en el lado cliente tan rápido como el servidor lo envía. Esta situación puede provocar tiempos de espera.

Para mitigarlo, reduzca el consumo de ancho de banda de red o aumente el tamaño de la máquina virtual del cliente a una con más capacidad de red. Para obtener más información, consulte Tamaño de solicitud o respuesta grande.

RedisSessionStateProvider retryTimeout

Si usa RedisSessionStateProvider, asegúrese de establecer correctamente retryTimeout . El valor retryTimeoutInMilliseconds debe ser mayor que el valor operationTimeoutInMilliseconds. De lo contrario, no se produce ningún reintento.

En el siguiente ejemplo, retryTimeoutInMilliseconds se establece en 3000.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Para obtener más información, consulte:

Configuración de TCP para aplicaciones cliente hospedadas en Linux

Las aplicaciones cliente hospedadas en Linux podrían experimentar problemas de conectividad debido a la configuración optimista de TCP en Linux. Para obtener más información, consulte Configuración de TCP para aplicaciones cliente hospedadas en Linux.

Configuración del grupo de subprocesos y ráfagas de tráfico

Las ráfagas de tráfico se combinan con una mala configuración de ThreadPool pueden provocar retrasos en el procesamiento de datos ya enviados por el servidor Redis, pero que aún no se han consumido en el lado cliente. Compruebe la métrica Errores (Tipo: UnresponsiveClients) para validar si los hosts de cliente pueden mantenerse al día con picos repentinos en el tráfico. Puede configurar las opciones de ThreadPool para asegurarse de que su grupo de subprocesos se escale verticalmente a gran velocidad en escenarios de ráfaga.

Puede usar timeoutException mensajes de StackExchange.Redis para investigar más a fondo.

    System.timeoutException: timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

La excepción anterior muestra varios problemas.

  • En la sección IOCP y la sección WORKER, el valor de Busy es mayor que el de Min, lo que significa que los ThreadPool requerimientos necesitan ajuste.
  • El valor in: 64221 indica que se recibieron 64 221 bytes en la capa de socket del kernel del cliente, pero que la aplicación no la leyó. Esta diferencia suele significar que la aplicación, por ejemplo StackExchange.Redis, no lee los datos de la red tan rápido como el servidor lo envía.

StackExchange.Redis 1.1.603 y versiones posteriores incluyen la métrica local-cpu en mensajes de error de timeoutException. Asegúrese de usar la versión más reciente del paquete NuGet StackExchange.Redis, ya que los errores se corrigen periódicamente para que el código sea más resistente a los tiempos de espera. Para obtener más información, consulte Investigación de excepciones de tiempo de espera en StackExchange.Redis.

Solución de problemas del lado servidor

Los siguientes problemas del lado servidor pueden afectar al rendimiento y dar lugar a tiempos de espera.

Uso de memoria alto

La presión de memoria en el servidor puede provocar varios problemas de rendimiento que retrasan el procesamiento de solicitudes. Cuando se produce una presión de memoria, el sistema traslada los datos al disco, lo que hace que el sistema se ralentice significativamente.

Algunas causas posibles de presión de memoria son que la memoria caché está llena de datos a cerca de su capacidad máxima, o que el servidor de Redis tiene una fragmentación de memoria alta.

Es probable que la fragmentación ocurra si un patrón de carga almacena datos con una gran variación de tamaño, por ejemplo, cuando los datos se distribuyen en tamaños de 1 KB y 1 MB. Cuando se elimina una clave de 1 KB de la memoria existente, una clave de 1 MB no puede caber en el espacio, lo que provoca la fragmentación. De forma similar, si se elimina una clave de 1 MB, una clave agregada de 1,5 MB no puede caber en la memoria reclamada existente. Esta memoria libre sin usar da como resultado la fragmentación.

Si una caché está fragmentada y funciona bajo mucha presión de memoria, el sistema realiza un proceso de recuperación para intentar recuperar la memoria RSS (Resident Set Size). Redis expone dos estadísticas, used_memory y used_memory_rss, a través del comando INFO, que pueden ayudarle a identificar este problema. También puede ver estas métricas en Azure Portal.

Si el valor used_memory_rss es superior al 150 % de la métrica used_memory, hay fragmentación en la memoria. La fragmentación puede causar problemas cuando:

  • El uso de memoria está cerca del límite máximo de memoria de la memoria caché.
  • La used_memory_rss métrica es mayor que el límite máximo de memoria, lo que podría provocar fallos de página en la memoria.

Puede realizar varias acciones para ayudar a mantener el uso de memoria en buen estado.

Para obtener más recomendaciones sobre la administración de memoria, consulte Procedimientos recomendados para la administración de memoria.

Carga elevada del servidor

La carga alta del servidor significa que el servidor de Redis está ocupado y no puede mantenerse al día con las solicitudes, lo que conduce a tiempos de espera o respuestas lentas. Para mitigar la carga alta del servidor, investigue primero la causa, como comandos de larga duración debido a una presión de memoria alta.

Puede supervisar métricas como la carga del servidor desde Azure Portal. Para comprobar la métrica Carga del servidor, seleccione Información en Supervisión en el menú de navegación izquierdo de la página de caché y vea el gráfico Carga del servidor . O bien, seleccione Métricas en Supervisión en el menú de navegación izquierdo y, a continuación, seleccione Carga del servidor en Métricas.

Observe los picos de uso de la carga del servidor que se corresponden con los tiempos de espera. Cree alertas en las métricas de carga del servidor para recibir una notificación anticipada sobre posibles impactos.

Picos en la carga del servidor

En las cachés C0 y C1, es posible que vea picos cortos en la carga del servidor no causados por un aumento de las solicitudes mientras el examen interno de Defender se ejecuta en las máquinas virtuales. En estos niveles, verá una mayor latencia para las solicitudes mientras se producen exámenes internos de Defender.

La caché en los niveles C0 y C1 solo tienen un único núcleo a varias tareas, lo que divide el trabajo de atender solicitudes internas de análisis de Defender y Redis. Si la latencia adicional de los exámenes internos de Defender afecta negativamente a la carga de trabajo de producción en una caché de C1, puede escalar a una oferta de nivel superior con varios núcleos de CPU, como C2. Para obtener más información, consulte Elección del nivel correcto.

Para obtener más información sobre los cambios rápidos en el número de conexiones de cliente, consulte Evitar picos de conexión de cliente.

Ampliación

Puede escalar horizontalmente hacia más fragmentos para distribuir la carga entre varios procesos de Redis o escalar verticalmente a un tamaño de caché mayor con más núcleos de CPU. Las operaciones de escalado consumen mucha CPU y memoria, ya que pueden implicar mover datos alrededor de los nodos y cambiar la topología del clúster. Para más información, consulte Preguntas más frecuentes sobre planeamiento y escalado de Azure Cache for Redis.

Comandos de larga duración

Algunos comandos de Redis son más caros de ejecutar que otros. La documentación de comandos de Redis muestra la complejidad del tiempo de cada comando. El procesamiento de comandos de Redis es monohilo. Cualquier comando que tarde mucho tiempo en ejecutarse puede bloquear a otros usuarios que lo siguen.

Revise los comandos que emite en el servidor de Redis para comprender sus impactos en el rendimiento. Por ejemplo, el comando KEYS se usa a menudo sin saber que es una operación de Notación Big O (O(N)). Para reducir los picos de CPU, puede evitar KEYS mediante SCAN.

Puede ejecutar los siguientes comandos de Redis en una consola para investigar comandos de larga duración y costosos.

  • LISTA DE CLIENTES

    El CLIENT LIST comando devuelve información y estadísticas sobre el servidor de conexiones de cliente en un formato legible principalmente humano.

  • INFORMACIÓN

    El INFO comando devuelve información y estadísticas sobre el servidor en un formato sencillo para que los equipos analicen y sea fácil de leer. La CPU sección puede ser útil para investigar el uso de cpu. Un server_load de 100 (valor máximo) indica que el servidor de Redis estaba ocupado todo el tiempo y nunca estaba inactivo al procesar las solicitudes.

    En el ejemplo siguiente se muestra una salida del INFO comando :

    # CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1

  • MONITOR

    MONITOR es un comando de depuración que transmite todos los comandos procesados por el servidor de Redis. MONITOR puede ayudarle a comprender lo que sucede con la base de datos. Este comando es exigente y puede afectar negativamente y degradar el rendimiento.

  • SLOWLOG

    El registro lento de Redis es un sistema para registrar consultas que superaron un tiempo de ejecución especificado. El tiempo de ejecución no incluye operaciones de E/S como hablar con el cliente o enviar la respuesta, pero solo el tiempo necesario para ejecutar realmente el comando.

    El comando SLOWLOG lee y restablece el registro de consultas lentas de Redis y también se puede usar para investigar comandos de larga duración en el lado cliente. Puede supervisar y registrar comandos costosos que se ejecutan en el servidor de Redis mediante SLOWLOG GET.

Limitaciones de ancho de banda de red

Tamaños de caché diferentes tienen capacidades distintas de ancho de banda de red. Si el servidor supera el ancho de banda disponible, los datos no se envían al cliente tan rápidamente. Las solicitudes del cliente podría agotar el tiempo de espera debido a que el servidor no puede insertar datos al cliente lo suficientemente rápido.

Puede supervisar métricas como Lectura de caché y Escritura en caché en Azure Portal para ver cuánto ancho de banda del lado servidor se usa. Cree alertas sobre estas métricas para recibir una notificación anticipada sobre posibles impactos.

Para mitigar las situaciones en las que la utilización de ancho de banda de red está cerca de la capacidad máxima, haga lo siguiente:

Mantenimiento del servidor.

El mantenimiento planeado o no planeado puede provocar interrupciones con las conexiones de cliente. El número y el tipo de excepciones dependen de dónde se encuentre la solicitud en la ruta de acceso al código cuando la memoria caché cierra sus conexiones.

Si la caché de Azure Redis se somete a una conmutación por error, todas las conexiones de cliente del nodo que se ha caído se transfieren al nodo que sigue funcionando. La carga del servidor podría aumentar debido al aumento de las conexiones. Puede intentar reiniciar las aplicaciones cliente para que todas las conexiones de cliente se vuelvan a crear y redistribuir entre los dos nodos.

Una operación que envía una solicitud, pero no recibe una respuesta cuando se produce la conmutación por error podría obtener una excepción de timeout. Las nuevas solicitudes en el objeto de conexión cerrado reciben excepciones de conexión hasta que la reconexión se produce correctamente.

Para comprobar si hubo una conmutación por error en su caché de Azure Redis durante el periodo en que ocurrieron sus excepciones timeout, compruebe la métrica Errores. En la página del portal de Azure de la memoria caché, seleccione Métricas en Supervisión en el menú de navegación izquierdo. A continuación, cree un nuevo gráfico que mida la métrica Errores , dividida por ErrorType. Una vez creado este gráfico, verá un recuento de conmutación por error. Para obtener más información sobre las conmutaciones por error, vea Conmutación por error y aplicación de revisiones para Azure Cache for Redis.

Para obtener más información sobre la mitigación de problemas debido al mantenimiento del servidor, consulte los artículos siguientes:

Contenido relacionado