Redis é um banco de dados na memória que fornece desempenho incrivelmente rápido. Isso o torna uma alternativa atraente para bancos de dados baseados em disco quando o desempenho é uma preocupação. Talvez você já esteja usando a hospedagem do ScaleGrid para Redis™* para alimentar seus aplicativos sensíveis ao desempenho. Como você garante que sua implantação do Redis esteja íntegra e atenda aos seus requisitos? Você precisará saber quais métricas de monitoramento do Redis™ devem ser observadas e uma ferramenta para monitorar essas métricas críticas do servidor para garantir sua integridade. O Redis retorna uma grande lista de métricas de banco de dados quando você executa o comando info no shell do Redis. Você pode escolher uma seleção inteligente de métricas relevantes a partir delas. E isso pode ajudá-lo a garantir a integridade do seu sistema e a executar rapidamente a análise da causa raiz de qualquer problema relacionado ao desempenho que você possa encontrar.
Esta postagem de blog lista as métricas de banco de dados importantes a serem monitoradas. Analisaremos cada métrica a partir de uma perspectiva de desempenho do banco de dados e discutiremos os problemas comuns e as soluções associadas a elas.
1. Métrica de desempenho:taxa de transferência
Throughput informa quantas operações de banco de dados seu servidor está realizando em um determinado período de tempo. Depende da carga de trabalho do seu aplicativo e de sua lógica de negócios. Observando o histórico de taxa de transferência, você pode inferir o padrão de carga em um servidor, por exemplo. carga de pico, a frequência de carga de pico, os prazos de carga de pico, carga média, etc.
Você pode coletar valores de métricas de taxa de transferência para todos os comandos executados no servidor Redis executando “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
O Redis agrupa seus vários comandos em conexão, servidor, cluster, genérico etc. O monitoramento ScaleGrid para Redis™ agrega a taxa de transferência de vários comandos em um dos grupos mencionados acima. A taxa de transferência é representada como um gráfico de área empilhada, onde a altura de cada área colorida fornece a taxa de transferência de um grupo de comandos.
Uma taxa de transferência reduzida geralmente pode indicar que o servidor recebe menos consultas. Também pode indicar um problema em potencial, digamos, uma consulta cara. Da mesma forma, uma taxa de transferência aumentada significa uma carga de trabalho intensa em um servidor e uma latência maior.
2. Utilização da memória
A memória é um recurso crítico para o desempenho do Redis. Memória usada define o número total de bytes alocados pelo Redis usando seu alocador (libc padrão, jemalloc ou um alocador alternativo, como tcmalloc).
Você pode coletar todos os dados de métricas de utilização de memória para uma instância do Redis executando “memória de informações ”.
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
Às vezes, quando o Redis é configurado sem limite máximo de memória, o uso de memória eventualmente atingirá a memória do sistema e o servidor começará a gerar erros de "Sem memória". Outras vezes, o Redis é configurado com um limite máximo de memória, mas noeviction política. Isso faria com que o servidor não despejasse nenhuma chave, evitando assim qualquer gravação até que a memória fosse liberada. A solução para esses problemas seria configurar o Redis com memória máxima e alguma política de despejo. Nesse caso, o servidor começa a despejar as chaves usando a política de despejo à medida que o uso de memória atinge o máximo.
Memória RSS (Tamanho do conjunto residente) é o número de bytes que o sistema operacional alocou para o Redis. Se a proporção de 'memory_rss' para 'memory_used' for maior que ~ 1,5, isso significa fragmentação de memória. A memória fragmentada pode ser recuperada reiniciando o servidor.
3. Taxa de acertos de cache
A taxa de acertos do cache representa a eficiência do uso do cache. Matematicamente, é definido como (Total de acertos de tecla)/ (Total de acertos de tecla + Total de acertos de tecla).
“estatísticas de informações ” fornece keyspace_hits &keyspace_misses dados métricos para calcular ainda mais a taxa de acertos do cache para uma instância do Redis em execução.
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 .............
Se a taxa de acertos do cache for inferior a ~0,8, uma quantidade significativa das chaves solicitadas será despejada, expirada ou não existirá. É crucial observar essa métrica ao usar o Redis como cache. Uma taxa de acertos de cache mais baixa resulta em maior latência, pois a maioria das solicitações está buscando dados do disco. Indica que você precisa aumentar o tamanho do cache do Redis para melhorar o desempenho do seu aplicativo.
4. Conexões ativas
O número de conexões é um recurso limitado que é imposto pelo sistema operacional ou pela configuração do Redis. Monitorar as conexões ativas ajuda a garantir que você tenha conexões suficientes para atender a todas as suas solicitações no horário de pico.
5. Chaves despejadas/expiradas
O Redis oferece suporte a várias políticas de despejo que são usados pelo servidor quando o uso de memória atinge o limite máximo. Um valor positivo persistente dessa métrica é uma indicação de que você precisa aumentar a escala da memória.
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 ..............
O Redis suporta TTL (tempo de vida) para cada chave. O servidor exclui a chave se o TTL associado tiver decorrido. Se o aplicativo não definir essa propriedade, isso fará com que os dados expirados se acumulem na memória. Um valor de métrica positivo mostra que seus dados expirados estão sendo limpos corretamente.
6. Métricas de replicação
‘connected_slaves’ métrica informa a acessibilidade do servidor escravo a um mestre. A inacessibilidade do escravo pode levar a uma latência de leitura mais alta, dependendo da carga de leitura em um 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 ..............
‘master_slave_io_seconds_ago ' indica quanto tempo decorre durante a comunicação entre um escravo e o mestre. Um valor mais alto para esta métrica pode ser indicativo de problemas no mestre/escravo ou alguns problemas de rede. Além disso, faz com que o escravo forneça dados obsoletos.
Conclusão
Mencionamos algumas das métricas importantes que fornecerão boa visibilidade da integridade e do desempenho do seu servidor de banco de dados. Pode haver outros que sejam relevantes para seus servidores de banco de dados e casos de uso específicos. Recomendamos passar e entender todas as métricas relatadas pelo comando “info”.
Se você precisar de ajuda para gerenciar sua hospedagem da AWS para implantações do Redis™ , sinta-se à vontade para entrar em contato conosco por e-mail em [email protected] ou no Twitter @scalegridio.
