Monitorización del Rendimiento de Redis

RedisRedisBeginner
Practicar Ahora

💡 Este tutorial está traducido por IA desde la versión en inglés. Para ver la versión original, puedes hacer clic aquí

Introducción

En este laboratorio, aprenderá cómo monitorizar y solucionar problemas de rendimiento de Redis. El laboratorio se centra en identificar y abordar problemas de latencia, analizar el uso de memoria y optimizar el rendimiento de las consultas.

Utilizará el comando LATENCY DOCTOR para diagnosticar la latencia, MEMORY STATS para verificar el uso de la memoria, SLOWLOG GET para analizar las consultas lentas y MEMORY PURGE para optimizar la memoria. Siguiendo la guía paso a paso, obtendrá experiencia práctica en el mantenimiento de una implementación de Redis eficiente y con buena capacidad de respuesta.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL redis(("Redis")) -.-> redis/RedisGroup(["Redis"]) redis/RedisGroup -.-> redis/access_cli("Connect Using CLI") subgraph Lab Skills redis/access_cli -.-> lab-552100{{"Monitorización del Rendimiento de Redis"}} end

Monitorizar la latencia con LATENCY DOCTOR

En este paso, exploraremos cómo usar el comando LATENCY DOCTOR en Redis para diagnosticar y solucionar problemas de latencia. Comprender y abordar la latencia es crucial para mantener una implementación de Redis eficiente y con buena capacidad de respuesta.

¿Qué es la latencia?

La latencia se refiere al retraso entre el envío de una solicitud a un servidor Redis y la recepción de una respuesta. Una latencia alta puede afectar negativamente el rendimiento de la aplicación, lo que lleva a tiempos de respuesta lentos y a una mala experiencia de usuario.

Presentación de LATENCY DOCTOR

El comando LATENCY DOCTOR es una potente herramienta integrada en Redis que ayuda a identificar posibles fuentes de latencia. Analiza varios aspectos del funcionamiento de Redis y proporciona información sobre qué podría estar causando retrasos.

Guía paso a paso

  1. Conectarse a Redis:

    Primero, conéctese a su servidor Redis utilizando el comando redis-cli. Abra una terminal en su VM de LabEx y ejecute lo siguiente:

    redis-cli

    Esto abrirá la interfaz de línea de comandos de Redis.

  2. Ejecutar LATENCY DOCTOR:

    Una vez conectado, simplemente ejecute el comando LATENCY DOCTOR:

    LATENCY DOCTOR

    Redis analizará entonces el sistema y proporcionará un informe.

  3. Interpretar la salida:

    La salida de LATENCY DOCTOR puede ser bastante extensa, pero proporciona información valiosa. Desglosemos una salida de ejemplo:

    127.0.0.1:6379> LATENCY DOCTOR
    I am The Doctor, and I am here to help you with your latency problems.
    Please wait...
    
    --- SUMMARY ---
    
    Nominal latency seems ok.
    
    --- DETAILS ---
    
    * Key lookup seems ok.
    * Slow calls:
        - command: slowlog get 128
          occurred 1 times
          max latency: 1 milliseconds
    
    --- ADVICE ---
    
    Check the slowlog to understand what queries are taking the most time.
    • SUMMARY (RESUMEN): Esta sección proporciona una visión general de alto nivel de la situación de la latencia. En este ejemplo, indica que la latencia nominal parece estar bien.
    • DETAILS (DETALLES): Esta sección ofrece información más específica sobre posibles áreas problemáticas. Aquí, destaca las "Slow calls" (llamadas lentas) y sugiere revisar el slowlog.
    • ADVICE (CONSEJO): Esta sección proporciona recomendaciones sobre cómo investigar más a fondo y abordar cualquier problema identificado.
  4. Analizar consultas lentas (como sugiere LATENCY DOCTOR):

    La salida de LATENCY DOCTOR a menudo sugiere examinar el slowlog (registro de consultas lentas). El slowlog es una característica de Redis que registra las consultas que exceden un tiempo de ejecución especificado. Exploraremos el slowlog con más detalle en el siguiente paso. Por ahora, simplemente veamos el slowlog como se sugiere.

    SLOWLOG GET 128

    Este comando recupera las 128 entradas más recientes del slowlog. La salida le mostrará los comandos que tardaron más en ejecutarse, junto con sus tiempos de ejecución y marcas de tiempo (timestamps).

  5. Salir de redis-cli:

    Para asegurarse de que los comandos se registren, salga de redis-cli escribiendo:

    exit

Comprender la importancia

Al utilizar LATENCY DOCTOR y analizar el slowlog, puede obtener información valiosa sobre el rendimiento de su implementación de Redis. Esto le permite identificar y abordar los cuellos de botella (bottlenecks), optimizar sus consultas y garantizar una experiencia de usuario fluida y con buena capacidad de respuesta.

Comprobar la memoria con MEMORY STATS

En este paso, aprenderemos cómo usar el comando MEMORY STATS en Redis para monitorizar y comprender el uso de la memoria. Una gestión eficiente de la memoria es crucial para la estabilidad y el rendimiento de su servidor Redis.

¿Por qué monitorizar la memoria?

Redis es un almacén de datos en memoria (in-memory data store), lo que significa que almacena todos sus datos en la RAM. Si Redis se queda sin memoria, puede provocar una degradación del rendimiento, pérdida de datos o incluso fallos. La monitorización del uso de la memoria le permite identificar y abordar de forma proactiva los posibles problemas relacionados con la memoria.

Presentación de MEMORY STATS

El comando MEMORY STATS proporciona una visión general detallada del consumo de memoria de Redis. Desglosa el uso de la memoria en varias categorías, lo que le permite conocer dónde se está utilizando su memoria.

Guía paso a paso

  1. Conectarse a Redis:

    Conéctese a su servidor Redis utilizando el comando redis-cli. Abra una terminal en su VM de LabEx y ejecute lo siguiente:

    redis-cli

    Esto abrirá la interfaz de línea de comandos de Redis.

  2. Ejecutar MEMORY STATS:

    Una vez conectado, ejecute el comando MEMORY STATS:

    MEMORY STATS

    Redis recopilará entonces las estadísticas de memoria y mostrará los resultados.

  3. Interpretar la salida:

    La salida de MEMORY STATS es un diccionario de pares clave-valor, donde cada clave representa una estadística de memoria y el valor representa su valor correspondiente. Veamos una salida de ejemplo y expliquemos algunas de las métricas clave:

    127.0.0.1:6379> MEMORY STATS
     1) "peak.allocated"
     2) (integer) 1114480
     3) "total.allocated"
     4) (integer) 1114480
     5) "startup.allocated"
     6) (integer) 948480
     7) "replication.buffer"
     8) (integer) 0
     9) "clients.slaves"
    10) (integer) 0
    11) "clients.normal"
    12) (integer) 6456
    13) "aof.buffer"
    14) (integer) 0
    15) "lua.vm"
    16) (integer) 0
    17) "overhead.total"
    18) (integer) 165992
    19) "keys.count"
    20) (integer) 0
    21) "keys.bytes-per-key"
    22) (integer) 0
    23) "dataset.bytes"
    24) (integer) 948488
    25) "dataset.percentage"
    26) "0.00%"
    27) "bytes-per-replica.avg"
    28) (integer) 0
    29) "bytes-per-replica.min"
    30) (integer) 0
    31) "bytes-per-replica.max"
    32) (integer) 0
    33) "allocator.fragratio"
    34) "1.00"
    35) "allocator.fragbytes"
    36) (integer) 0
    37) "allocator.rss"
    38) (integer) 835584
    39) "allocator.peak"
    40) (integer) 1114112
    41) "total.system"
    42) (integer) 4194304
    43) "allocator.resident"
    44) (integer) 835584

    Aquí tiene un desglose de algunas de las métricas clave:

    • peak.allocated: La cantidad más alta de memoria que Redis ha asignado desde que se inició.
    • total.allocated: La cantidad total de memoria asignada actualmente por Redis.
    • dataset.bytes: El tamaño total de los datos almacenados en Redis (excluyendo la sobrecarga).
    • overhead.total: La cantidad total de memoria utilizada para la sobrecarga de Redis (por ejemplo, estructuras de datos, metadatos).
    • keys.count: El número de claves almacenadas actualmente en Redis.
    • allocator.fragratio: La relación de fragmentación del asignador de memoria (memory allocator). Un valor más alto indica más fragmentación.
    • allocator.rss: La cantidad de memoria que Redis está utilizando según lo informado por el sistema operativo (Resident Set Size).
    • total.system: La cantidad total de memoria disponible en el sistema.
  4. Salir de redis-cli:

    Para asegurarse de que los comandos se registren, salga de redis-cli escribiendo:

    exit

Usar la información

La información proporcionada por MEMORY STATS se puede utilizar para:

  • Identificar fugas de memoria (memory leaks).
  • Optimizar las estructuras de datos para reducir el uso de memoria.
  • Ajustar los parámetros de configuración de Redis para mejorar la eficiencia de la memoria.
  • Determinar si necesita aumentar la cantidad de RAM disponible para su servidor Redis.

Analizar consultas lentas con SLOWLOG GET

En este paso, profundizaremos en el análisis de consultas lentas utilizando el comando SLOWLOG GET en Redis. Identificar y optimizar las consultas lentas es esencial para mantener una implementación de Redis eficiente y con buena capacidad de respuesta. Como sugirió LATENCY DOCTOR en el primer paso, analizar el slowlog (registro de consultas lentas) es un paso crucial para depurar problemas de latencia.

¿Qué es el Slowlog?

El slowlog es un sistema en Redis que registra las consultas que exceden un tiempo de ejecución especificado. Esto le permite identificar las consultas que tardan más de lo esperado y que potencialmente afectan al rendimiento.

Guía paso a paso

  1. Conectarse a Redis:

    Conéctese a su servidor Redis utilizando el comando redis-cli. Abra una terminal en su VM de LabEx y ejecute lo siguiente:

    redis-cli

    Esto abrirá la interfaz de línea de comandos de Redis.

  2. Recuperar entradas del Slowlog:

    Utilice el comando SLOWLOG GET para recuperar las entradas del slowlog. Puede especificar el número de entradas que desea recuperar. Por ejemplo, para recuperar las 10 entradas más recientes del slowlog, utilice el siguiente comando:

    SLOWLOG GET 10

    Si desea recuperar todas las entradas del slowlog, puede utilizar:

    SLOWLOG GET
  3. Interpretar la salida:

    La salida de SLOWLOG GET es una matriz de entradas del slowlog. Cada entrada contiene la siguiente información:

    • Unique ID (ID único): Un identificador único para la entrada del slowlog.
    • Timestamp (Marca de tiempo): La marca de tiempo Unix (Unix timestamp) cuando se ejecutó la consulta.
    • Execution Time (Tiempo de ejecución): El tiempo de ejecución de la consulta en microsegundos.
    • Command (Comando): El comando completo que se ejecutó.
    • Client IP and Port (if available) (IP y puerto del cliente, si está disponible): La dirección IP y el puerto del cliente que ejecutó el comando.
    • Client Name (if set) (Nombre del cliente, si está configurado): El nombre del cliente que ejecutó el comando.

    Aquí tiene un ejemplo de una entrada del slowlog:

    1) 1) (integer) 1
       2) (integer) 1678886400
       3) (integer) 12345
       4) 1) "KEYS"
          2) "*"

    En este ejemplo:

    • El ID único es 1.
    • La marca de tiempo es 1678886400.
    • El tiempo de ejecución es 12345 microsegundos (12.345 milisegundos).
    • El comando fue KEYS *.
  4. Analizar el Slowlog:

    Una vez que haya recuperado las entradas del slowlog, puede analizarlas para identificar las consultas lentas. Busque consultas con tiempos de ejecución elevados. Considere lo siguiente:

    • Frequency (Frecuencia): ¿Con qué frecuencia se produce la consulta lenta? Si se produce con frecuencia, es probable que tenga un mayor impacto en el rendimiento.
    • Command Type (Tipo de comando): ¿Qué tipo de comando es? Algunos comandos, como KEYS *, se sabe que son lentos y deben evitarse en entornos de producción.
    • Data Size (Tamaño de los datos): ¿La consulta está operando sobre una gran cantidad de datos? Si es así, considere la posibilidad de optimizar las estructuras de datos o la propia consulta.
  5. Ejemplo: Simulación de una consulta lenta

    Para demostrar cómo se pueden identificar las consultas lentas, vamos a insertar un gran número de claves en Redis y, a continuación, utilizaremos el comando KEYS *, que se sabe que es lento.

    En primer lugar, vamos a añadir algunos datos. Ejecute los siguientes comandos en redis-cli:

    for i in $(seq 1 1000); do SET key$i value$i; done

    Esto creará 1000 claves en su base de datos Redis.

    Ahora, ejecute el comando KEYS *:

    KEYS *

    Este comando recuperará todas las claves de la base de datos. Debido a que tenemos un gran número de claves, este comando probablemente será lento.

    Ahora, compruebe el slowlog:

    SLOWLOG GET 1

    Debería ver una entrada para el comando KEYS * en el slowlog, junto con su tiempo de ejecución.

  6. Salir de redis-cli:

    Para asegurarse de que los comandos se registren, salga de redis-cli escribiendo:

    exit

Usar la información

Al analizar el slowlog, puede identificar las consultas lentas y tomar medidas para optimizarlas. Esto podría implicar:

  • Reescribir la consulta para que sea más eficiente.
  • Optimizar las estructuras de datos utilizadas por la consulta.
  • Añadir índices para mejorar el rendimiento de la consulta.
  • Evitar comandos que se sabe que son lentos, como KEYS *.

Resumen

En este laboratorio, exploramos las técnicas de monitorización del rendimiento de Redis. Comenzamos utilizando el comando LATENCY DOCTOR para diagnosticar y solucionar problemas de latencia, entendiendo que la latencia es el retraso entre una solicitud y una respuesta. El comando analiza el funcionamiento de Redis y proporciona información sobre las posibles causas de los retrasos.

El laboratorio demostró cómo conectarse a Redis utilizando redis-cli y ejecutar el comando LATENCY DOCTOR. A continuación, aprendimos a interpretar la salida, centrándonos en las secciones SUMMARY (RESUMEN), DETAILS (DETALLES) y ADVICE (CONSEJOS) para identificar posibles cuellos de botella y comprender las consultas lentas.