Compartir vía

Solución de problemas de tiempos de espera y latencia de Azure Cache for Redis

  • Artículo

Una operación de cliente que no recibe una respuesta a tiempo puede dar lugar a una alta latencia o una excepción de tiempo de espera. Una operación podría superar el tiempo de espera en varias fases. Saber de dónde procede el tiempo de espera ayuda a determinar la causa y la mitigación.

En esta sección se describe la solución de problemas de tiempo de espera y latencia que se producen al conectarse a Redis Cache.

Nota

Algunos de los pasos de solución de problemas de esta guía incluyen instrucciones para ejecutar comandos de Redis y supervisar diversas métricas de rendimiento. Para más información e instrucciones, consulte los artículos de la sección Información adicional .

Solución de problemas de lado cliente

Esta es la solución de problemas del lado cliente.

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 soportar un pico repentino de tráfico.

Supervise cómo las estadísticas de ThreadPool cambian a lo largo del tiempo con un ejemplo ThreadPoolLogger. Puede usar mensajes deTimeoutException StackExchange.Redis para seguir investigando:

    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)

En la excepción anterior, hay varias incidencias que son interesantes:

  • Observe que en la sección IOCP y la sección WORKER tiene un valor de Busy que es mayor que el valor de Min. Esta diferencia significa que es necesario ajustar la configuración de ThreadPool.
  • También puede ver in: 64221. Este valor indica que se recibieron 64 221 bytes en la capa de socket del kernel del cliente, pero que la aplicación no los leyó. Esta diferencia normalmente significa que la aplicación (por ejemplo, StackExchange.Redis) no está leyendo los datos de la red con la rapidez con la que el servidor se los envía.

Puede configurar las opciones de ThreadPool para asegurarse de que su grupo de subprocesos se escala verticalmente a gran velocidad en escenarios de ráfaga.

Valor de clave grande

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.

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

  • Aumento del tamaño de la máquina virtual para obtener mayores capacidades 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 la utilización actual de la red en ambas máquinas con los límites del tamaño actual de la máquina virtual. Más ancho de banda solo en el servidor o solo 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.

Uso elevado de CPU en hosts de cliente

Un uso elevado de la CPU del cliente indica que el sistema no puede seguir el ritmo del trabajo asignado. Aunque la caché haya enviado la respuesta rápidamente, el cliente podría no procesarla a tiempo. Nuestra recomendación es mantener la CPU del cliente menos del 80 %. Compruebe la métrica "Errores" (tipo: UnresponsiveClients) para determinar si los hosts cliente pueden procesar las respuestas del servidor Redis a tiempo.

Supervise la utilización de la CPU de todo el sistema del cliente mediante las métricas disponibles en Azure Portal o a través de los contadores de rendimiento en la máquina. Tenga cuidado de no supervisar la CPU de un proceso, porque un solo proceso puede tener un uso de CPU bajo pero la CPU de todo el sistema puede ser elevada. Busque picos de uso de CPU que correspondan a tiempos de espera agotados. La CPU alta también puede provocar valores in: XXX altos en TimeoutException mensajes de error, tal y como se describe en la sección [ráfaga de tráfico].

Nota:

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 StackExchange.Redis de NuGet. Los errores se solucionan periódicamente en el código para que sea más resistente a agotar los tiempos de espera. Es importante tener la versión más reciente.

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

  • Investigue lo que está provocando los picos en la CPU.
  • Actualice la máquina virtual del cliente a un tamaño mayor con más capacidad de CPU.

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

Dependiendo de la arquitectura de las máquinas cliente, pueden tener limitaciones en cuanto al ancho de banda de red del que disponen. Si el cliente supera el ancho de banda disponible por una sobrecarga de la capacidad de red, los datos no se procesarán en el lado cliente con la rapidez con la que el servidor se los envía. Esta situación puede provocar tiempos de espera.

Supervise cómo cambia la utilización del ancho de banda a lo largo del tiempo mediante un ejemplo BandwidthLogger. Es posible que este código no se ejecute correctamente en algunos entornos con permisos restringidos (como sitios web de Azure).

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.

Configuración de TCP para aplicaciones cliente hospedadas en Linux

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

Tiempo de espera de reintento de RedisSessionStateProvider

Si usa RedisSessionStateProvider, asegúrese de establecer el tiempo de espera de reintento correctamente. 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. Para más información, consulte Proveedor de estado de sesión de ASP.NET para Azure Cache for Redis y Proveedor de caché de resultados de ASP.NET para Azure Cache for Redis.

<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"
>

Solución de problemas del lado servidor

Esta es la solución de problemas del lado servidor.

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. Por ejemplo, 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 tiempo de espera. Las nuevas solicitudes en el objeto de conexión cerrado reciben excepciones de conexión hasta que la reconexión se produce correctamente.

Para obtener más información, consulte estas otras secciones:

Para comprobar si el Azure Cache for Redis ha tenido una conmutación por error durante el tiempo de espera, compruebe la métrica Errores. En el menú de la izquierda de Azure Portal, seleccione Métricas. A continuación, cree un gráfico que mida la métrica Errors, dividido 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.

Carga elevada del servidor

Una carga elevada del servidor significa que el servidor de Redis no puede mantenerse al día con las solicitudes, lo que provoca que se agote el tiempo de espera. Puede que el servidor tarde en responder y sea capaz de seguir el ritmo con las tasas de solicitud.

Supervise las métricas, como la carga de la CPU o el servidor. Busque picos de uso de Server Load que correspondan a tiempos de espera agotados. Cree alertas en métricas sobre la carga del servidor para recibir una notificación anticipada sobre los impactos potenciales.

Hay varios cambios que puede hacer para mitigar la carga elevada en el servidor:

  • Investigue lo que está causando una carga elevada del servidor, como comandos de ejecución prolongada, indicado en este artículo, debido a una presión de memoria alta.
  • Escale horizontalmente a más particiones 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. Para obtener más información, consulte Preguntas frecuentes sobre Azure Cache for Redis.
  • Si la carga de trabajo de producción de un caché C1 se ve afectada negativamente por la latencia adicional de algunas ejecuciones de examen de Defender internas, puede reducir el efecto mediante el escalado a una oferta de nivel superior con varios núcleos de CPU, como C2.

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 un par de veces al día mientras el examen interno de Defender se ejecuta en las máquinas virtuales. Verá una mayor latencia para las solicitudes mientras que los exámenes internos de Defender se producen en estos niveles. 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.

Uso de memoria alto

Esta sección se ha movido. Para obtener más información, consulte Uso elevado de la memoria.

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 de tiempo de cada comando. El procesamiento de comandos de Redis es de un solo subproceso. Cualquier comando que tarda mucho tiempo en ejecutarse puede bloquear todos los demás que vienen después de él.

Debe revisar los comandos que emite al servidor de Redis para comprender sus efectos en el rendimiento. Por ejemplo, el comando KEYS a menudo se usa el sin saber que se trata de una operación O(N). Puede evitar el comando KEYS mediante el uso de SCAN para reducir los picos de la CPU.

Mediante el comando SLOWLOG GET, puede medir los comandos caros que se ejecutan en el servidor.

Los clientes pueden usar una consola para ejecutar estos comandos de Redis para investigar comandos de larga duración y costosos.

  • SLOWLOG se usa para leer y restablecer el registro de consultas lentas de Redis. Se puede usar para investigar comandos de larga duración en el lado cliente. 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, enviar la respuesta, etc., pero solo el tiempo necesario para ejecutar realmente el comando. Los clientes pueden medir/registrar comandos costosos que se ejecutan en su servidor de Redis mediante el comandoSLOWLOG.
  • MONITOR es un comando de depuración que transmite todos los comandos procesados por el servidor de Redis. Puede ayudarle a comprender lo que sucede en la base de datos. Este comando es exigente y puede afectar negativamente al rendimiento. Puede degradar el rendimiento.
  • INFO: este comando devuelve información y estadísticas sobre el servidor en un formato fácil de analizar para equipos y fácil de leer para personas. En este caso, la sección CPU podría ser útil para investigar el uso de CPU. Una carga de servidor de 100 (valor máximo) indica que el servidor de Redis estaba ocupado todo el tiempo y nunca estaba inactivo al procesar las solicitudes.

Ejemplo de salida:

# 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
  • CLIENT LIST: devuelve información y estadísticas sobre el servidor de conexiones de cliente en un formato legible principalmente por el usuario.

Límites del 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.

Las métricas de "Lectura de caché" y "Escritura de caché" pueden usarse para ver el ancho de banda del lado servidor que se está usando. Puede ver estas métricas en el portal. Crear alertas en métricas como la lectura de caché o la escritura de caché para recibir una notificación anticipada sobre los impactos potenciales.

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:

Excepciones de tiempo de espera de StackExchange.Redis

Para obtener información más específica sobre cómo solucionar los tiempos de espera al usar StackExchange.Redis, consulte Investigación de excepciones de tiempo de espera en StackExchange.Redis.

Contenido relacionado