Tair (Redis® OSS-Compatible):Solução de problemas de alto uso de memória

Cenários de alto uso de memória

O uso elevado de memória geralmente se enquadra em um dos três cenários a seguir:

• O uso de memória permanece em um nível alto por um período prolongado. Geralmente, tome medidas quando o uso de memória exceder 95%.

• O uso de memória é consistentemente baixo, mas apresenta um pico repentino, chegando às vezes a 100%.

• O uso geral de memória da instância é baixo, porém o uso de memória de um nó de dados específico está próximo de 100%.

Para reduzir o uso de memória, aplique a solução correspondente ao seu cenário.

Soluções para uso de memória consistentemente alto

1. Verifique se as chaves existentes atendem aos requisitos do negócio e limpe prontamente quaisquer chaves desnecessárias.

2. Use o recurso de análise de cache para examinar a distribuição de chaves grandes e as políticas de expiração TTL. Para mais informações, consulte Offline key analysis.

   1. Analise se a chave possui uma política de TTL adequada.

      Nota

      No exemplo a seguir, nenhuma chave tem tempo de expiração definido. Recomendamos avaliar as necessidades do seu negócio e definir tempos de expiração apropriados no lado do cliente.

      Figura 1. Exemplo de distribuição de tempo de expiração de chaves

   2. Avalie a chave grande e divida-a no lado da aplicação.

      Na página de análise de cache, clique na aba Large Key Analysis para visualizar os detalhes. A tabela exibe informações como nome da chave, tipo da chave e tamanho dos dados. Clique em Export para baixar os resultados da análise para sua máquina local.

3. Defina uma política de evicção adequada com base nos requisitos do seu negócio configurando o parâmetro maxmemory-policy. Para instruções específicas, consulte Set parameters.

   Nota

   A política de evicção padrão para uma instância é volatile-lru. Para mais informações, consulte Eviction policies.

4. Configure uma frequência de execução razoável para exclusão ativa de chaves expiradas conforme as necessidades do seu negócio ajustando o valor do parâmetro hz. Para instruções específicas, consulte Adjust the execution frequency of scheduled tasks.

   Nota

   Recomendamos definir o parâmetro hz com um valor inferior a 100. Um valor maior pode impactar significativamente o uso da CPU. Você também pode ativar o ajuste automático se sua instância for compatível com Redis 5.0 ou posterior. Para mais informações, consulte Enable dynamic frequency control for background tasks.

5. Se o uso de memória permanecer alto após as otimizações anteriores, considere atualizar para uma especificação com mais memória para lidar com mais dados e melhorar o desempenho. Para mais informações, consulte Change instance configuration.

   Nota

   Antes de atualizar sua instância, adquira uma instância de pagamento conforme o uso para testar se a especificação alvo atende aos requisitos da sua carga de trabalho. Libere a instância após a conclusão do teste. Para informações sobre como liberar uma instância, consulte Release pay-as-you-go instances.

Soluções para aumentos repentinos de memória

Causas

Um aumento repentino no uso de memória pode ter as seguintes causas:

Um pico repentino de memória tem uma entre quatro causas possíveis. Use o indicador principal em cada linha para identificar qual se aplica ao seu caso.

Soluções para alta memória em um nó de dados

Sintomas

Para instâncias com arquitetura cluster, o uso elevado de memória em um nó de dados específico é indicado pelos seguintes sintomas:

• Você recebe um alerta de uso de memória do CloudMonitor. A mensagem de alerta indica que o uso de memória de um nó de dados específico excedeu o limiar.

• O relatório de diagnóstico da instância mostra um desbalanceamento no uso de memória.

• Na página de monitoramento de desempenho, você nota que o uso geral de memória da instância é baixo, mas um nó de dados específico apresenta alto uso de memória.

Causa

Se o uso geral de memória da instância estiver baixo enquanto o uso de um nó de dados específico estiver alto, isso indica um desbalanceamento no uso de memória.

Soluções

Verificar e dividir chaves grandes

Encontrar chaves grandes

Use o recurso offline key analysis para encontrar quaisquer chaves grandes.

Para mais métodos de localização de chaves grandes, consulte Large keys and hotkeys.

Dividir chaves grandes

Por exemplo, divida uma chave HASH com dezenas de milhares de membros em várias chaves HASH menores, cada uma com um número razoável de membros. Em uma instância cluster, dividir chaves grandes ajuda significativamente a equilibrar o uso de memória entre os shards de dados.

Verificar o uso de hash tag

Se você estiver usando uma hash tag que causa concentração de dados, considere dividi-la em múltiplas hash tags de acordo com a lógica da sua aplicação. Isso ajuda a distribuir os dados de forma mais uniforme entre diferentes shards de dados.

Atualizar a especificação da instância

Atualizar a especificação da instância aumenta a memória disponível para cada shard e pode ser uma solução temporária para desbalanceamento de memória. Para etapas detalhadas, consulte Change instance configuration.

Apêndice 1: Uso de memória do Redis

A memória de uma instância Redis consiste em três componentes principais:

Apêndice 2: Verificando o uso de memória

 1) "peak.allocated" // The peak memory consumed by the Redis process since startup.
 2) (integer) 79492312
 3) "total.allocated" // The total number of bytes allocated by Redis, which is the current total memory usage.
 4) (integer) 79307776
 5) "startup.allocated" // The initial amount of memory consumed by Redis at startup.
 6) (integer) 45582592
 7) "replication.backlog" // The size of the replication backlog buffer.
 8) (integer) 33554432
 9) "clients.slaves" // The total size of read and write buffers for all replica nodes in master-replica replication.
10) (integer) 17266
11) "clients.normal" // The total size of read and write buffers for all regular clients (excluding replica nodes).
12) (integer) 119102
13) "aof.buffer" // The buffer used for AOF persistence and the buffer generated during AOF rewrite.
14) (integer) 0
15) "db.0"  // The number of business databases.
16) 1) "overhead.hashtable.main" // The total memory overhead for the hash tables of the current database, which is the metadata memory.
    2) (integer) 144
    3) "overhead.hashtable.expires" // The memory consumed to store key expiration times.
    4) (integer) 0
17) "overhead.total" // The sum of all overhead memory. Calculated as: startup.allocated + replication.backlog + clients.slaves + clients.normal + aof.buffer + db.X.
18) (integer) 79273616
19) "keys.count" // The total number of keys in the current Redis instance.
20) (integer) 2
21) "keys.bytes-per-key" // The average size of each key in the current Redis instance. Calculated as: (total.allocated - startup.allocated) / keys.count.
22) (integer) 16862592
23) "dataset.bytes" // The size of memory occupied by pure business data.
24) (integer) 34160
25) "dataset.percentage" // The percentage of memory occupied by pure business data. Calculated as: dataset.bytes * 100 / (total.allocated - startup.allocated).
26) "0.1012892946600914"
27) "peak.percentage" // The ratio of the current total memory to the historical peak memory. Calculated as: total.allocated * 100 / peak.allocated.
28) "99.767860412597656"
29) "fragmentation" // The memory fragmentation ratio.
30) "0.45836541056632996"

r-bpxxxxxxxxxxxxxxxxxxxx.redis.rds.aliyuncs.com:6379> MEMORY DOCTOR
"Sam, I detected a few issues in this Redis instance memory implants:\n\n * High
 allocator RSS overhead: This instance has an RSS memory overhead is greater tha
n 1.1 (this means that the Resident Set Size of the allocator is much larger tha
n the sum what the allocator actually holds). This problem is usually due to a l
arge peak memory (check if there is a peak memory entry above in the report), yo
u can try the MEMORY PURGE command to reclaim it.\n\nI'm here to keep you safe,
 Sam. I want to help you.\n"

    int empty = 0;     /* Instance is empty or almost empty. */
    int big_peak = 0;       /* Memory peak is much larger than used memory. */
    int high_frag = 0;      /* High fragmentation. */
    int high_alloc_frag = 0;/* High allocator fragmentation. */
    int high_proc_rss = 0;  /* High process RSS overhead. */
    int high_alloc_rss = 0; /* High RSS overhead from the allocator. */
    int big_slave_buf = 0;  /* Replica buffers are too big. */
    int big_client_buf = 0; /* Client buffers are too big. */
    int many_scripts = 0;   /* Script cache has too many scripts. */

MEMORY USAGE Key0089393003

(integer) 1000072