Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe cómo usar y supervisar la carga de una caché de Redis administrada de Azure.
Tamaños de valor
El diseño de la aplicación cliente determina si debe almacenar muchos valores pequeños o un número menor de valores mayores. Desde la perspectiva del servidor Redis, los valores menores ofrecen un mejor rendimiento. Se recomienda mantener un tamaño de valor inferior a 100 kB.
Si el diseño requiere que almacene valores mayores en el Azure Redis administrado, la carga del servidor será mayor. En este caso, es posible que tenga que usar un nivel de caché superior para asegurarse de que el uso de CPU no limita el rendimiento.
Incluso si la caché tiene suficiente capacidad de CPU, los valores más grandes aumentan las latencias, por lo que debe seguir las instrucciones que se indican en Configuración de tiempos de espera adecuados.
Evitar picos de conexión de los clientes
La creación y el cierre de las conexiones es una operación costosa para el servidor Redis. Si la aplicación cliente crea o cierra demasiadas conexiones en un período de tiempo pequeño, podría sobrecargar el servidor Redis.
Si va a instanciar muchas instancias de cliente para conectarse a Redis a la vez, considere escalonar las nuevas conexiones para evitar un pico excesivo en el número de clientes conectados.
Presión de memoria
El uso elevado de memoria en el servidor hace que sea más probable que el sistema tenga que paginar los datos en el disco, lo que da lugar a errores de página que pueden ralentizar significativamente el sistema.
Evitar comandos de larga duración
El servidor Redis es un sistema de un solo subproceso. Los comandos de larga duración pueden provocar latencia o tiempos de espera en el lado cliente porque el servidor no puede responder a otras solicitudes mientras está ocupado trabajando en un comando de larga duración. Para obtener más información, consulte Solucionar problemas del lado del servidor en Azure Cache para Redis.
Supervisión de la carga del servidor y la CPU
Agregue supervisión en la carga del servidor y la CPU para asegurarse de que recibe notificaciones cuando cualquiera de ellas es alta. La supervisión puede ayudarle a comprender las restricciones de la aplicación. Luego, puede trabajar de forma proactiva para mitigar los problemas. Se recomienda intentar mantener la carga del servidor por debajo del 80 % para evitar efectos negativos en el rendimiento. Una carga sostenida del servidor superior al 80 % puede provocar conmutaciones por error no planeadas. Actualmente, Azure Managed Redis expone dos métricas en Insights bajo Monitoring en el menú de Recursos a la izquierda del portal: CPU y Server Load. Comprender lo que mide cada métrica es importante al supervisarlos.
La métrica CPU (a.k.a. percentProcessorTime) indica el uso de CPU para el nodo que hospeda la memoria caché. La métrica CPU también incluye procesos que no son estrictamente procesos del servidor Redis. La CPU incluye procesos en segundo plano para antimalware y otros. En consecuencia, la métrica CPU a veces puede presentar picos y podría no ser un indicador perfecto del uso de la CPU para el servidor Redis.
La métrica Carga del servidor refleja la propia evaluación del servidor de Redis de la carga general y es similar a la métrica de CPU, pero en un nivel de clúster.
Recomendaciones para SKU más pequeñas
En las SKU de Azure de Redis administrados y respaldados por máquinas virtuales de 2 vCPU (B0-B5, X3 y M10), las métricas en porcentaje, como Server Load y CPU, son intrínsecamente más sensibles. Un único subproceso en segundo plano de corta duración puede consumir un porcentaje significativo de CPU total, lo que provoca que las métricas aparezcan elevadas incluso cuando la carga de trabajo real sea ligera. Como resultado, estas métricas pueden sobrestimar la carga real en SKU pequeñas y es posible que no indiquen la saturación de la carga de trabajo.
Al revisar las métricas durante períodos de tiempo más largos, como varias horas o días, se recomienda:
- Usar LA CPU en lugar de la carga del servidor, ya que puede visualizarse a nivel de instancia, lo que añade más granularidad.
- División por identificador de instancia de las máquinas virtuales que respaldan la instancia de Redis administrada de Azure
- Uso de la agregación promedio en lugar de Máximo para estos intervalos de tiempo más largos
Todavía puede usar la agregación de Máximo en ventanas de tiempo cortas para detectar breves picos o eventos (como aquellos que podrían provocar tiempos de espera o fallos por conmutación), mientras se basa en Promedio en ventanas más largas para el análisis de tendencias en pequeñas SKU, especialmente cuando se usa CPU.
Prueba del aumento de la carga del servidor después de la conmutación por error
En el caso de las SKU estándar y prémium, cada caché está hospedada en dos nodos. Un equilibrador de carga distribuye las conexiones de cliente a los dos nodos. Cuando se produce un mantenimiento planeado o no planeado en el nodo principal, este cierra todas las conexiones de cliente. En este caso, todas las conexiones de cliente podrían distribuirse a un solo nodo, lo que provocaría que la carga del servidor aumentara en el nodo restante. Para probar este escenario, se recomienda reiniciar el nodo principal y asegurarse de que un nodo puede controlar todas las conexiones de cliente sin que la carga del servidor sea demasiado alta.