Problemas persistentes de conexão

Regras de entrada:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Tipo: TCP Regra personalizada;

Protocolo: TCP

Port Range: 1024-65535

Fonte: 0.0.0.0/0 (ou crie regras individuais para as sub-redes do cluster) ElastiCache

Allow/Deny: Allow

Regras de saída:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Tipo: TCP Regra personalizada;

Protocolo: TCP

Port Range: 6379

Fonte: 0.0.0.0/0 (ou as sub-redes do cluster). ElastiCache Lembre-se de que o uso específico IPs pode criar problemas em caso de failover (ou escalonamento do cluster).

Allow/Deny: Allow

Regras de entrada:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Tipo: TCP Regra personalizada;

Protocolo: TCP

Port Range: 6379

Fonte: 0.0.0.0/0 (ou crie regras individuais para as sub-redes do cluster) ElastiCache

Allow/Deny: Allow

Regras de saída:

Número da regra: preferencialmente inferior a qualquer regra de negação;

Tipo: TCP Regra personalizada;

Protocolo: TCP

Port Range: 1024-65535

Fonte: 0.0.0.0/0 (ou as sub-redes do cluster). ElastiCache Lembre-se de que o uso específico IPs pode criar problemas em caso de failover (ou escalonamento do cluster).

Allow/Deny: Allow

CPUuso: Valkey e Redis OSS são aplicativos multiencadeados. No entanto, a execução de cada comando ocorre em um único thread (principal). Por esse motivo, ElastiCache fornece as métricas CPUUtilization EngineCPUUtilization e. EngineCPUUtilizationfornece a CPU utilização dedicada ao OSS processo Valkey ou Redis e CPUUtilization o uso em todos. vCPUs Os nós com mais de um v CPU geralmente têm valores diferentes para CPUUtilization eEngineCPUUtilization, sendo o segundo geralmente mais alto. A alta EngineCPUUtilization pode ser causada por um número elevado de solicitações ou operações complexas que levam muito CPU tempo para serem concluídas. Você pode identificar ambos com o seguinte:

Seu aplicativo não suporta o modo de ElastiCache cluster e ElastiCache tem o modo de cluster ativado;

Seu aplicativo não suportaTLS/e ElastiCache tem SSL a criptografia em trânsito ativada;

O aplicativo suportaTLS/SSL, mas não tem os sinalizadores de configuração corretos ou autoridades de certificação confiáveis;

Número máximo de conexões: há limites rígidos para conexões simultâneas. Cada ElastiCache nó permite até 65.000 conexões simultâneas em todos os clientes. Esse limite pode ser monitorado por meio das CurrConnections métricas ativadas CloudWatch. No entanto, os clientes também têm seus limites para conexões de saída. No Linux, verifique o intervalo de portas efêmeras permitido com o comando:

# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

No exemplo anterior, 28231 conexões serão permitidas da mesma origem, para o mesmo IP de destino (ElastiCache nó) e porta. O comando a seguir mostra quantas conexões existem para um ElastiCache nó específico (IP 1.2.3.4):

ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

Se o número for muito alto, seu sistema pode ficar sobrecarregado tentando processar as solicitações de conexão. É aconselhável considerar a implementação de técnicas como grupo de conexões ou conexões persistentes para lidar melhor com as conexões. Sempre que possível, configure o grupo de conexões para limitar o número máximo de conexões a algumas centenas. Além disso, a lógica de recuo para lidar com tempo limite ou outras exceções de conexão seria aconselhável para evitar rotatividade de conexão em caso de problemas.

Limites de tráfego de rede: verifique as seguintes CloudWatch métricas do Redis OSS para identificar possíveis limites de rede atingidos no ElastiCache nó:

As métricas acima são a maneira ideal de confirmar que os nós atingem seus limites de rede. No entanto, os limites também são identificáveis por platôs em métricas de rede.

Se os platôs forem observados por longos períodos, provavelmente serão seguidos por atraso na replicação, aumento nos bytes usados para cache, queda na memória liberável, alta troca e uso. CPU EC2As instâncias da Amazon também têm limites de rede que podem ser rastreados por meio de métricas de ENA drivers. Instâncias Linux com suporte de rede aprimorado e ENA drivers 2.2.10 ou mais recentes podem analisar os contadores de limite com o comando:

# ethtool -S eth0 | grep "allowance_exceeded"

Redis OSS SlowLogs: a configuração ElastiCache padrão retém os últimos 128 comandos que levaram mais de 10 milissegundos para serem concluídos. O histórico de comandos lentos é mantido durante o tempo de execução do mecanismo e será perdido em caso de falha ou reinicialização. Se a lista atingir 128 entradas, eventos antigos serão removidos para abrir espaço para novas entradas. O tamanho da lista de eventos lentos e o tempo de execução considerado lento podem ser modificados através dos parâmetros slowlog-max-len e slowlog-log-slower-than em um grupo de parâmetros personalizado. A lista de logs lentos pode ser recuperada executando SLOWLOG GET 128 no mecanismo, 128 sendo os últimos 128 comandos lentos relatados. Cada entrada tem os seguintes campos:

1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

O evento acima aconteceu em 26 de dezembro, às 19:26:07UTC, levou 4,8 segundos (4.823ms) para ser concluído e foi causado pelo comando solicitado ao cliente 1.2.3.4. KEYS

No Linux, o carimbo de data/hora pode ser convertido com a data do comando:

$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

Com Python:

>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

Ou no Windows com PowerShell:

PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

Muitos comandos lentos em um curto período de tempo (mesmo minuto ou menos) são motivo de preocupação. Revise a natureza dos comandos e como eles podem ser otimizados (consulte exemplos anteriores). Se comandos com complexidade de tempo O (1) forem frequentemente relatados, verifique os outros fatores de alto CPU uso mencionados anteriormente.

Métricas de latência: ElastiCache (RedisOSS) fornece CloudWatch métricas para monitorar a latência média de diferentes classes de comandos. O ponto de dados é calculado dividindo o número total de execuções de comandos na categoria pelo tempo total de execução no período. É importante entender que os resultados da métrica de latência são um agregado de vários comandos. Um único comando pode causar resultados inesperados, como tempos limite, sem impacto significativo nas métricas. Para tais casos, os eventos de log lento seriam uma fonte de informação mais precisa. A lista a seguir contém as métricas de latência disponíveis e os respectivos comandos que as afetam.

Comandos de tempo de OSS execução do Redis:

Backup e replicação: as versões ElastiCache (RedisOSS) anteriores à 2.8.22 usam um processo bifurcado para criar backups e processar sincronizações completas com as réplicas. Esse método pode incorrer em sobrecarga de memória significativa para casos de uso intensivo de gravação.

A partir do ElastiCache Redis OSS 2.8.22, AWS introduziu um método de backup e replicação sem bifurcação. O novo método pode atrasar as gravações para evitar falhas. Ambos os métodos podem causar períodos de maior CPU utilização, levar a maiores tempos de resposta e, consequentemente, levar ao tempo limite do cliente durante sua execução. Sempre verifique se as falhas do cliente acontecem durante a janela de backup ou a métrica SaveInProgress foi 1 no período. É aconselhável agendar a janela de backup para períodos de baixa utilização para minimizar a possibilidade de problemas com clientes ou falhas de backup.

Bugs na aplicação do cliente podem fazer com que as conexões sejam esquecidas e mantidas estabelecidas com um estado ocioso. Isso é chamado de "vazamento de conexão", e a conseqüência é um aumento constante no número de conexões estabelecidas observadas na métrica CurrConnections. Esse comportamento pode resultar em saturação no cliente ou no ElastiCache lado. Quando uma correção imediata não é possível do lado do cliente, alguns administradores definem um valor de “tempo limite” em seu grupo de ElastiCache parâmetros. O tempo limite é o tempo em segundos permitido para que as conexões ociosas persistam. Se o cliente não enviar nenhuma solicitação no período, o OSS mecanismo do Redis encerrará a conexão assim que a conexão atingir o valor de tempo limite. Pequenos valores de tempo limite podem resultar em desconexões desnecessárias e os clientes precisarão lidar com eles corretamente e reconectar, causando atrasos.

A memória usada para armazenar chaves é compartilhada com buffers do cliente. Clientes lentos com grandes solicitações ou respostas podem exigir uma quantidade significativa de memória para lidar com seus buffers. As configurações padrão ElastiCache (RedisOSS) não restringem o tamanho dos buffers de saída regulares do cliente. Se o limite maxmemory for atingido, o mecanismo tentará despejar itens para cumprir o uso do buffer. Em condições de memória extremamente baixa, o ElastiCache (RedisOSS) pode optar por desconectar clientes que consomem grandes buffers de saída do cliente para liberar memória e manter a integridade do cluster.

É possível limitar o tamanho dos buffers do cliente com configurações personalizadas e os clientes que atingirem o limite serão desconectados. No entanto, os clientes devem ser capazes de lidar com desconexões inesperadas. Os parâmetros para lidar com o tamanho de buffers para clientes regulares são os seguintes:

Além dos buffers de cliente regulares, as seguintes opções controlam o buffer para nós de réplica e clientes Pub/Sub (Publish/Subscribe):

CPU:

Rede

On the network: Tcpdump and Wireshark (tshark na linha de comando) são ferramentas úteis para entender quanto tempo a solicitação levou para percorrer a rede, acionar o ElastiCache motor e obter uma devolução. O exemplo a seguir destaca uma única solicitação criada com o seguinte comando:

$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

Paralelamente ao comando acima, tcpdump estava em execução e retornou:

$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

Na saída acima, podemos confirmar que o handshake TCP tridirecional foi concluído em 222 microssegundos (918091 - 917869) e que o comando ping foi enviado e retornado em 173 microssegundos (918295 - 918122).

Demorou 438 microssegundos (918307 - 917869) da solicitação ao fechamento da conexão. Esses resultados confirmam que os tempos de resposta da rede e do mecanismo são bons e que a investigação pode concentrar-se em outros componentes.

No sistema operacional: Strace pode ajudar a identificar intervalos de tempo no nível do sistema operacional. A análise de aplicações reais seria muito mais extensa, e profilers ou depuradores especializados de aplicações são aconselhados. O exemplo a seguir mostra apenas se os componentes básicos do sistema operacional estão funcionando como esperado, caso contrário, investigações adicionais podem ser necessárias. Usando o mesmo OSS PING comando Redis com, strace obtemos:

$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

No exemplo acima, o comando levou um pouco mais de 54 milissegundos para ser concluído (752110 - 697712 = 54398 microssegundos).

Foi necessário um tempo significativo, aproximadamente 20 ms, para instanciar nc e fazer a resolução do nome (de 697712 a 717890). Depois disso, foram necessários 2 ms para criar o TCP soquete (745659 a 747858) e 0,4 ms (747858 a 748330) para enviar e receber a resposta da solicitação.