Redis es una base de datos en memoria que proporciona un rendimiento increíblemente rápido. Esto lo convierte en una alternativa convincente a las bases de datos basadas en disco cuando el rendimiento es una preocupación. Es posible que ya esté utilizando el alojamiento de ScaleGrid para Redis™* para potenciar sus aplicaciones sensibles al rendimiento. ¿Cómo se asegura de que su implementación de Redis esté en buen estado y cumpla con sus requisitos? Necesitará saber qué métricas de monitoreo debe monitorear Redis™ y una herramienta para monitorear estas métricas críticas del servidor para garantizar su salud. Redis devuelve una gran lista de métricas de la base de datos cuando ejecuta el comando de información en el shell de Redis. Puede elegir una selección inteligente de métricas relevantes de estos. Y estos pueden ayudarlo a garantizar la salud de su sistema y realizar rápidamente un análisis de causa raíz de cualquier problema relacionado con el rendimiento que pueda encontrar.
Esta publicación de blog enumera las métricas importantes de la base de datos para monitorear. Analizaremos cada métrica desde la perspectiva del rendimiento de la base de datos y discutiremos los problemas comunes y las soluciones asociadas con ellos.
1. Métrica de rendimiento:Rendimiento
El rendimiento le indica cuántas operaciones de base de datos está realizando su servidor en un período de tiempo determinado. Depende de la carga de trabajo de su aplicación y su lógica empresarial. Al observar el historial de rendimiento, puede inferir el patrón de carga en un servidor, p. carga máxima, la frecuencia de la carga máxima, los marcos de tiempo de la carga máxima, la carga promedio, etc.
Puede recopilar valores de métricas de rendimiento para todos los comandos que se ejecutan en el servidor de Redis ejecutando "info commandstats ”.
127.0.0.1:6379> info commandstats # Commandstats cmdstat_get:calls=797,usec=4041,usec_per_call=5.07 cmdstat_append:calls=797,usec=4480,usec_per_call=5.62 cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86 cmdstat_auth:calls=147,usec=288,usec_per_call=1.96 cmdstat_info:calls=46,usec=902,usec_per_call=19.61 cmdstat_config:calls=2,usec=130,usec_per_call=65.00 cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42 cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
Redis agrupa sus diversos comandos en conexión, servidor, clúster, genérico, etc. El monitoreo de ScaleGrid para Redis™ agrega el rendimiento de varios comandos en uno de los grupos mencionados anteriormente. El rendimiento se representa como un gráfico de áreas apiladas, donde la altura de cada área coloreada proporciona el rendimiento de un grupo de comandos.
Un rendimiento reducido generalmente podría indicar que el servidor recibe menos consultas. También podría indicar un problema potencial, por ejemplo, una consulta costosa. Del mismo modo, un mayor rendimiento significa una carga de trabajo intensiva en un servidor y una mayor latencia.
2. Utilización de memoria
La memoria es un recurso fundamental para el rendimiento de Redis. Memoria usada define el número total de bytes asignados por Redis usando su asignador (ya sea libc estándar, jemalloc o un asignador alternativo como tcmalloc).
Puede recopilar todos los datos de métricas de uso de memoria para una instancia de Redis ejecutando "memoria de información ”.
127.0.0.1:6379> info memory # Memory used_memory:1007280 used_memory_human:983.67K used_memory_rss:2002944 used_memory_rss_human:1.91M used_memory_peak:1008128 used_memory_peak_human:984.50K
A veces, cuando Redis está configurado sin límite máximo de memoria, el uso de la memoria eventualmente alcanzará la memoria del sistema y el servidor comenzará a generar errores de "Memoria insuficiente". En otras ocasiones, Redis está configurado con un límite máximo de memoria pero sin desalojo. política. Esto haría que el servidor no desaloje ninguna clave, evitando así cualquier escritura hasta que se libere la memoria. La solución a tales problemas sería configurar Redis con memoria máxima y alguna política de desalojo. En este caso, el servidor comienza a desalojar claves utilizando la política de desalojo a medida que el uso de la memoria alcanza el máximo.
Memoria RSS (Tamaño del conjunto residente) es la cantidad de bytes que el sistema operativo ha asignado a Redis. Si la proporción de 'memory_rss' a 'memory_used' es mayor que ~1.5, entonces significa fragmentación de la memoria. La memoria fragmentada se puede recuperar reiniciando el servidor.
3. Proporción de aciertos de caché
La proporción de aciertos de la caché representa la eficiencia del uso de la caché. Matemáticamente, se define como (Total de aciertos de teclas)/ (Total de aciertos de teclas + Total de errores de tecla).
“estadísticas de información El comando ” proporciona keyspace_hits &keyspace_misses datos métricos para calcular aún más la proporción de aciertos de caché para una instancia de Redis en ejecución.
127.0.0.1:6379> info stats # Stats ............. sync_partial_err:0 expired_keys:10 evicted_keys:12 keyspace_hits:4 keyspace_misses:15 pubsub_channels:0 pubsub_patterns:0 .............
Si la proporción de aciertos de la memoria caché es inferior a ~0,8, una cantidad significativa de las claves solicitadas se desalojan, caducan o no existen en absoluto. Es fundamental observar esta métrica al usar Redis como caché. Una proporción de aciertos de caché más baja da como resultado una mayor latencia, ya que la mayoría de las solicitudes obtienen datos del disco. Indica que necesita aumentar el tamaño de la memoria caché de Redis para mejorar el rendimiento de su aplicación.
4. Conexiones activas
La cantidad de conexiones es un recurso limitado que impone el sistema operativo o la configuración de Redis. Supervisar las conexiones activas lo ayuda a asegurarse de que tiene suficientes conexiones para atender todas sus solicitudes en las horas pico.
5. Claves desalojadas/caducadas
Redis admite varias políticas de desalojo que utiliza el servidor cuando el uso de la memoria alcanza el límite máximo. Un valor positivo persistente de esta métrica es una indicación de que necesita escalar la memoria.
127.0.0.1:6379> info stats # Stats .............. sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 ..............
Redis admite TTL (tiempo de vida) propiedad para cada clave. El servidor elimina la clave si ha transcurrido el TTL asociado. Si la aplicación no define esta propiedad, hace que los datos caducados se acumulen en la memoria. Un valor de métrica positivo muestra que sus datos caducados se están limpiando correctamente.
6. Métricas de replicación
‘esclavos_conectados’ La métrica informa la accesibilidad del servidor esclavo a un maestro. La inaccesibilidad del esclavo podría generar una mayor latencia de lectura según la carga de lectura en un servidor.
127.0.0.1:6379> info replication # Replication role:master/slave connected_slaves:0/master_slave_io_seconds_ago:0 master_repl_offset:0 ..............
‘maestro_esclavo_io_segundos_ago La métrica dice cuánto tiempo transcurre durante la comunicación entre un esclavo y el maestro. Un valor más alto para esta métrica puede ser indicativo de problemas en el maestro/esclavo o algunos problemas de red. Además, hace que el esclavo sirva datos obsoletos.
Conclusión
Hemos mencionado algunas de las métricas importantes que proporcionarán una buena visibilidad del estado y el rendimiento de su servidor de base de datos. Podría haber otros que sean relevantes para sus servidores de bases de datos y casos de uso particulares. Recomendamos revisar y comprender todas las métricas reportadas por el comando "info".
Si necesita ayuda para administrar su alojamiento de AWS para implementaciones de Redis™, no dude en comunicarse con nosotros por correo electrónico a [email protected] o en Twitter @scalegridio.
