¿Por qué el uso de CPU de una instancia de DCS Redis es 100%?

Síntomas

El uso de CPU de una instancia de Redis aumenta drásticamente en un corto período de tiempo. Si el uso de la CPU es demasiado alto, las conexiones pueden agotarse y se puede activar la conmutación principal/en espera.

Causas posibles

1. El servicio QPS es alto. En este caso, consulte Comprobación de QPS.
2. Se utilizaron los comandos que consumen recursos, como KEYS. En este caso, consulte Localización y deshabilitación de comandos intensivos en la CPU.
3. Se activó la reescritura de Redis. En este caso, consulte Comprobación de reescritura de Redis.

Comprobación de QPS

En la página Cache Manager de la consola de DCS, haga clic en una instancia para ir a la página de detalles de la instancia. En el menú de la izquierda, elija Performance Monitoring y, a continuación, vea la métrica Ops per Second.

Localización y deshabilitación de comandos intensivos en la CPU

Se utilizan comandos que consumen recursos (comandos con complejidad de tiempo O(N) o superior), como KEYS. Generalmente, cuanto mayor es la complejidad temporal, más recursos utiliza un comando. Como resultado, el uso de la CPU es alto, y se puede activar fácilmente una conmutación principal/en espera. Para obtener más información sobre la complejidad temporal de cada comando, visite el sitio web oficial de Redis. En este caso, utilice el comando SCAN en su lugar o desactive el comando KEYS.

1. En la página Performance Monitoring de la consola de DCS, localice el período en el que el uso de la CPU es alto.

2. Utilice los métodos siguientes para encontrar los comandos que consumen un gran número de recursos.
   • Redis registra las consultas que exceden una duración de ejecución especificada. Puede encontrar los comandos que consumen un gran número de recursos analizando las consultas lentas y su duración de ejecución. Para obtener más información, consulte la sección Vista de consultas lentas de Redis.
   • Utilice la función de diagnóstico de instancia para analizar el porcentaje de duración de ejecución de diferentes comandos durante el período en que el uso de CPU es alto. Para obtener más información, consulte Diagnóstico de una instancia.

     

3. Resuelva el problema.
   • Evalúe y deshabilite los comandos de alto riesgo y alto consumo, como FLUSHALL, KEYS y HGETALL.
   • Optimice los servicios. Por ejemplo, evite las operaciones frecuentes de clasificación de datos.
   • (Opcional) Realice las siguientes operaciones para ajustar las instancias en función de los requisitos de servicio:
     • Cambie el tipo de instancia a separación de lectura/escritura para separar las solicitudes de lectura y escritura de los comandos o aplicaciones de alto consumo.
     • Amplíe la instancia.

Comprobación de reescritura de Redis

La persistencia de AOF, que está habilitada de forma predeterminada para las instancias principal/en espera y de clúster de DCS Redis, tiene lugar en los siguientes escenarios:

• Si se escribe una pequeña cantidad de datos y el archivo AOF no es grande, la reescritura de AOF se realiza de 01:00 a 04:00 de la mañana todos los días, y el uso de la CPU puede aumentar repentinamente durante este período.
• Cuando se escribe una gran cantidad de datos y el tamaño del archivo de AOF excede el umbral (de tres a cinco veces la capacidad de instancia de DCS), la reescritura de AOF se activa automáticamente en segundo plano independientemente de la hora actual.

La reescritura de Redis se realiza ejecutando el comando BGSAVE o BGREWRITEAOF, que puede consumir muchos recursos de CPU (vea la discusión). Los comandos BGSAVE y BGREWRITEAOF necesitan bifurcar(), lo que resulta en picos de uso de la CPU en un corto período de tiempo.

Si no se requiere persistencia, desactívela cambiando el valor de appendonly a no en la página Parameters de la instancia. Sin embargo, si desactiva la persistencia, la pérdida de datos puede ocurrir debido a la falta de vaciado de datos en el disco en las situaciones extremas.