Dimensionar corretamente o `maxmemory` do Redis: reservas de memória para dados e funcionamento

O que limita efetivamente o `maxmemory`

maxmemory cria no Redis Open Source um Limiar de despejo Não existe um limite máximo rígido para o processo Redis ou para o seu contentor. Se o consumo relevante para a gestão da memória atingir o limiar, o Redis tentará remover chaves, dependendo da política selecionada. No caso de uma política sem evicção, os comandos de escrita que aumentam a utilização de memória podem, em vez disso, falhar.

O indicador used_memory abrange a memória ocupada pelo Redis através do seu alocador. Isto inclui não só os valores propriamente ditos da sua aplicação, mas também estruturas de gestão e outras áreas de memória do Redis. Quem calcular o limite apenas com base no tamanho estimado dos dados úteis não tem em conta esta sobrecarga.

Uma parte de used_memory é excluído do teste de evicção: mem_not_counted_for_evict destaca, em particular, os buffers temporários de replicação e AOF. No entanto, estes buffers requerem memória física. O valor já está definido em used_memory está incluído e, por isso, não pode ser somado uma segunda vez a este indicador sem ser verificado.

Isso não significa que toda a memória do cliente ou de replicação esteja excluída do cálculo de evicção. Além disso, um único comando de grande dimensão pode ultrapassar significativamente o limiar, mesmo que temporariamente. Se definires maxmemory Se se atingir o limite máximo do contentor, não resta margem de manobra fiável para tais picos e consumo adicional de recursos do processo.

Para o planeamento, é, portanto, necessário responder separadamente a duas questões: de quanto espaço necessitam o conjunto de dados e a sobrecarga do Redis no âmbito da gestão de memória? E de quanto espaço de reserva necessita, além disso, todo o ambiente de execução? Só a combinação destas duas perspetivas permite determinar se um valor escolhido abaixo do limite real de memória é plausível.

RSS, alocador e picos de persistência

Após um pico de carga, pode used_memory diminuem, enquanto used_memory_rss permanece elevado: embora o Redis tenha libertado memória através do alocador, esta não foi necessariamente devolvida imediatamente ao sistema operativo. O RSS descreve a memória residente do processo do ponto de vista do sistema operativo e constitui, por isso, um nível de observação diferente.

Suponhamos que uma cache cresça significativamente durante uma ação e que, posteriormente, muitas chaves expirem. O facto de o valor de memória do Redis ser menor não significa automaticamente que o contentor recupere de imediato uma reserva livre correspondente. Para o próximo pico, é, portanto, mais importante a evolução do consumo real do que a suposição de que a memória libertada desaparece imediatamente.

Também mem_fragmentation_ratio não é apenas uma percentagem de fragmentação. Este rácio inclui outros aspetos do processo; para a análise das causas, deves considerá-lo em conjunto com os dados disponíveis allocator_*- Analisar as métricas e o histórico de carga. Não é possível deduzir uma reserva universalmente válida a partir de um único rácio.

No caso de instantâneos RDB e reescritas AOF, o Redis cria um processo filho. Através de Copy-on-Write Podem ser necessárias páginas de memória física adicionais se, durante o ciclo de persistência, forem alteradas páginas. Quanto mais intensa e abrangente for a carga de gravação durante esse período, mais importante é ter em conta esta fase no planeamento da capacidade.

A administração do Redis indica que, em casos extremos, as aplicações com grande volume de gravações podem necessitar de até o dobro da memória normalmente utilizada. Trata-se de um aviso sobre condições de carga desfavoráveis, não de um multiplicador genérico. Além disso, não basta somar simplesmente os valores RSS do processo pai e do processo filho: as páginas partilhadas seriam contadas várias vezes; o que é relevante é a monitorização adequada do host ou do contentor.

As réplicas precisam de orçamentos próprios

Uma réplica mantém, por princípio, uma cópia do conjunto de dados e, para tal, necessita de memória RAM própria. O primário e a réplica são, portanto, consumidores de memória distintos: uma reserva no primário não liberta espaço no contentor da réplica. Planeia cada membro com base no seu próprio limite e no consumo observado.

Por predefinição, uma réplica ignora o seu maxmemory para as próprias remoções. O Primary decide sobre a remoção de chaves e replica as eliminações. No entanto, os valores armazenados podem diferir, por exemplo, devido a buffers ou estruturas de dados diferentes; por isso, o mesmo valor limite não garante uma utilização idêntica.

No caso de uma Promoção A antiga réplica assume o papel de primária. Por isso, verifica não só se dispõe de espaço suficiente enquanto cópia de leitura, mas também se o seu limite de armazenamento e a sua configuração suportam o funcionamento como primária. Isto inclui, em particular, a carga de escrita, as ligações de replicação e o controlo de evicção então em vigor.

Desde o Redis 7.0 que o buffer de réplicas e a fila de réplicas partilham a memória. mem_clients_slaves pode, por isso, indicar zero, apesar de a replicação ocupar memória. Não interprete este campo isoladamente e não some o backlog e o buffer de réplica sem verificar, como se fossem áreas totalmente separadas.

Para além do consumo de memória, o avanço na transmissão de dados é relevante para o funcionamento: um atraso apresenta uma característica diferente da capacidade de um buffer. A forma como o estado da replicação e o atraso podem ser classificados é explicada no artigo sobre o Offset de replicação do Redis. No entanto, para a reserva de armazenamento, os padrões de consumo reais de cada instância continuam a ser determinantes.

Registar a memória em três níveis

Para o dimensionamento, precisas de valores do Redis e do ambiente em que a instância está a ser executada. O Nível de observação determina o que um número representa: a alocação do Allocator, o RSS do processo e o consumo de contentores são grandezas diferentes e não podem ser simplesmente somadas.

Com INFO memory Lês, entre outras coisas, os valores armazenados no Redis e a política configurada. MEMORY STATS completa os detalhes sobre a distribuição da memória. Ambos os comandos são de leitura; os campos disponíveis dependem da versão do Redis, das autorizações e do plano de alojamento.

Para verificar a relação temporal, deves também verificar INFO persistence quanto à atividade de persistência e aos valores de «copy-on-write» disponíveis. INFO replication Mostra a função e o estado de replicação. Registe estes dados separadamente para o Primário e a Réplica, para que uma troca de funções ou uma sincronização seja identificável na análise.

Um único valor não indica nem a carga típica nem a reserva de pico necessária. Por isso, recolhe séries temporais relativas ao funcionamento normal, aos picos de escrita e às execuções de persistência, e associa-as ao consumo do anfitrião ou do contentor observado simultaneamente. Desta forma, também poderás perceber se um valor RSS elevado acompanha uma carga atual ou se persiste após um pico anterior.

Calcular um orçamento de armazenamento robusto

O ponto de partida é a medida efetivamente aplicável Limite de armazenamento: No caso de um contentor, pode ser inferior à memória RAM do anfitrião. Identifique quais os outros processos e componentes do sistema que ocupam esse mesmo limite. O espaço que lhes está reservado não está disponível para o Redis utilizar para dados ou picos de carga.

Em seguida, subtraia as reservas para efeitos adicionais do RSS e do alocador, os buffers não contabilizados para a evicção, os picos de persistência e uma margem de segurança. O resultado é um valor provisório maxmemory- Orçamento, não é uma equação interna do Redis. As reservas têm de corresponder ao mesmo limite e a condições de carga que ocorram simultaneamente de forma realista.

Exemplo de cálculo ilustrativo, não se trata de uma medição: de um limite de contentor de 8 GiB, são deduzidos 0,5 GiB para outros consumidores, 0,5 GiB para efeitos RSS adicionais, 0,5 GiB para buffers excluídos do cálculo de evicção, 1 GiB para um pico de persistência e 0,5 GiB de margem de segurança. Como valor provisório, restam 5 GiB para maxmemory.

Estes números não constituem uma recomendação para uma instância concreta. O exemplo pressupõe que as reservas atribuídas descrevem contributos adicionais e não sobrepostos para o limite do contentor. Especialmente numa execução persistente, as páginas de memória partilhadas e o «copy-on-write» podem dificultar a atribuição; uma simples soma dos valores RSS do processo pai e do processo filho seria inadequada para esse efeito.

Evita Contagens duplicadas: mem_not_counted_for_evict já está presente em used_memory. Se partires do consumo total observado de RSS ou do contentor, não deves voltar a somar essa percentagem de buffer sem a verificar. O orçamento de evicção restante deve abranger tanto o conjunto de dados como a sobrecarga do Redis que foi contabilizada; verifica depois esta abordagem sob uma carga comparável.

Comparação prática das políticas de despejo

O Política de despejo determina a forma como o Redis reage aos comandos de gravação em caso de escassez de memória. Não substitui o planeamento de capacidade: mesmo uma política adequada requer reservas para além do cálculo de evicção. A decisão depende, acima de tudo, das chaves que podem ser perdidas e da forma como a aplicação reage aos erros.

No caso de um cache puro, pode allkeys-lru são adequadas quando as entradas eliminadas podem ser reconstruídas a partir de outra fonte. No Redis, o LRU é uma aproximação e não uma ordenação global exata. As evacuações frequentes podem provocar mais acessos ao backend; por isso, não são apenas os bytes livres que são importantes, mas também a taxa de acertos da cache e a capacidade do backend.

No caso de dados que não podem ser apagados arbitrariamente, noeviction Outra decisão: a aplicação deve ser capaz de lidar com operações de gravação falhadas, em vez de partir do princípio de que o armazenamento foi bem-sucedido. A política não visa nem a persistência nem a proteção contra um OOM ao nível do sistema operativo ou do contentor.

No caso de lotes mistos, a Modalidade TTL decisivo: Uma volatile-*- A política só pode selecionar chaves com prazo de validade. Se houver poucos candidatos adequados, o TTL, por si só, não protege contra erros de gravação. Por isso, verifica se a cache e os dados importantes devem realmente partilhar a mesma instância e estratégia de gestão de erros.

Os dados da sessão ilustram o conflito de objetivos: a eliminação de um registo pode significar, para os utilizadores, a perda do estado da sessão, mesmo que a aplicação continue a funcionar do ponto de vista técnico. Avalie as consequências e a possibilidade de recuperação antes de escolher a política; o artigo sobre o tema fornece informações adicionais sobre Gestão de sessões com o Redis e outras memórias.

Verificar a reserva sob carga

Um valor calculado para maxmemory É, em primeiro lugar, um ponto de partida. Teste-o num ambiente isolado com uma versão do Redis, uma estrutura de dados e um limite de memória comparáveis. A carga não deve refletir apenas o funcionamento normal, mas também picos de gravação e fases em que a persistência e a replicação estão ativas simultaneamente.

Observa, ao fazê-lo, o Consumo de contentores ou a métrica do host correspondente, bem como os valores de memória do Redis. Regista quando está a ser executado um snapshot ou uma reescrita AOF e se uma réplica está a ser sincronizada. O que é decisivo é a distância que resta até ao limite real durante a sobreposição de eventos, e não apenas no período de inatividade que se segue.

Com o comando de leitura INFO stats Entre outros aspetos, regista o contador de evicções. Analisa a variação desses valores por intervalo de tempo: um valor histórico elevado, por si só, não indica se as chaves estão a ser substituídas neste momento. Relaciona o aumento das evicções com os acertos na cache e a carga do backend, desde que a tua aplicação forneça esses dados.

Registe também as respostas OOM do Redis na aplicação e os eventos dos contentores relacionados com a memória na plataforma. Ambos os erros podem ocorrer com uma carga semelhante, mas dizem respeito a limites diferentes. Por isso, um sistema de alertas deve ter em conta tanto a reserva disponível como os erros observados e a sua evolução ao longo do tempo.

Repita a avaliação após alterações no conjunto de dados, na carga de escrita ou na persistência e replicação. Uma promoção também altera o papel de uma réplica e, consequentemente, o perfil de carga a ser analisado. Os resultados obtidos no ambiente isolado não substituem a monitorização contínua das instâncias em produção.

Identificar de forma específica os problemas de memória

Se o RSS do processo aumentar enquanto used_memory se isso acontecer, analise primeiro o histórico e a carga anterior. A memória libertada não tem de ser devolvida imediatamente ao sistema operativo. A Métricas do alocador de INFO memory ajudam a contextualizar; o índice de fragmentação, por si só, não prova nem a existência de uma fuga de memória nem a sua causa.

Verifica, em seguida, se o aumento coincide, em termos temporais, com uma corrida de resistência ou com uma sincronização. Para tal, servem INFO persistence e INFO replication. Um valor isolado para um buffer que não foi contabilizado na evicção descreve apenas o estado atual. Para calcular uma reserva, é necessário dispor de observações ao longo de fases relevantes de carga e de perturbação.

No caso de uma Resposta OOM do Redis Verifique a política configurada e se existem chaves adequadas para uma evicção. Em particular, um comando de gravação pode falhar se o Redis não conseguir libertar espaço suficiente ao abrigo da política em vigor. A aplicação deve tratar este erro, em vez de pressupor que a operação de gravação foi bem-sucedida.

No caso de um encerramento do contentor devido a problemas de memória, por outro lado, analise os eventos da plataforma e o consumo em relação ao limite do contentor. Tenha em conta os picos de persistência e outros consumidores registados no contentor. Um OOM do Redis e um OOM do contentor não são equivalentes: mesmo sem uma resposta prévia de OOM do Redis, o limite máximo de memória pode ser atingido.

maxmemory-clients pode, além disso, limitar a memória ocupada pelos clientes. Se a memória do cliente em questão ultrapassar o limite configurado, o Redis pode desligar os clientes com elevado consumo; as aplicações têm de lidar com as interrupções de ligação. Esta configuração não limita todas as ligações de replicação e não substitui nem o orçamento total nem a monitorização de picos de buffer.

Avaliar as opções de alojamento e arquitetura do Redis

Se a reserva observada não for suficiente com uma carga representativa, pode fazer sentido aumentar a RAM, caso se pretenda que o conjunto de dados e a carga permaneçam, em princípio, numa única instância. No entanto, a capacidade adicional tem de fazer parte do limite efetivo do anfitrião ou do contentor. Um limite Redis mais elevado, por si só, não cria memória física adicional.

Em alternativa, pode ser utilizada uma Distribuição da carga distribuir as necessidades de memória e as operações de gravação por várias instâncias. Isso requer uma divisão adequada dos dados e um orçamento específico para cada instância envolvida. As réplicas não devem ser equiparadas a uma divisão do conjunto de dados: mantêm, por princípio, uma cópia e, para tal, necessitam de memória RAM própria.

Uma alteração na arquitetura também pode ajudar, por exemplo, a separação de uma cache tolerante a perdas dos dados com requisitos mais rigorosos. Desta forma, é possível definir políticas e capacidades de forma independente. No entanto, nem esta separação, nem mais RAM, nem a distribuição de carga garantem que, no futuro, não venham a ocorrer picos de persistência, replicação e gravação.

Ao comparar Limites do fornecedor Esclareça se o valor indicado corresponde a um limite de contentores, a um limite de instâncias ou a outro limite definido pela base de dados. Pergunte ainda quais as métricas e comandos de diagnóstico disponíveis, se as réplicas estão incluídas no espaço de armazenamento reservado e qual o impacto de uma promoção nos recursos disponíveis.

O Redis Open Source, o Redis Software e o Redis Cloud devem ser considerados separadamente. No caso do Redis Software, o limite de base de dados documentado aplica-se tanto aos shards primários como aos réplicas; daí não decorre nenhuma regra correspondente para uma instância individual do Redis OSS. No caso do Redis Cloud e de outras ofertas de alojamento, deve consultar as condições específicas de cada produto, em vez de aplicar esta definição sem a verificar.