Estou enfrentando um problema hoje que não consigo explicar e espero que alguém consiga me colocar na direção certa.
Tenho uma frota de servidores EC2 executando um script python. Quando um usuário se conecta aos meus servidores (tratados por meio de um balanceador de carga), uma coisa que faço é obter o nome reverso com base no endereço IP (ou PTR).
Até agora, este é o código que eu estava usando:
import socket
details = socket.gethostbyaddr(request.user_ip)
print('User PTR is', details[0])
O que percebi hoje foi que a consulta gethostbyaddrpode demorar alguns segundos (algumas consultas demoraram até 300 segundos!!). A média é de 1s e um número frequente entre 20 e 30 segundos!
(Alguns mencionam gethostbyaddrum tempo limite de 5s, o que não parece ser o caso na minha situação).
Agora, lendo sobre gethostbyaddr, parece que ele usa resolv.conf(estou usando o Debian 12) para encontrar o inverso. Nos meus servidores, o conteúdo desse arquivo é:
nameserver 172.31.0.2
search .
Portanto, meus servidores dependem do resolvedor DNS VPC da AWS.
O que fiz foi acompanhar o tempo entre o gethostbyaddrcomando e se fosse maior que 1s, exibir a duração, junto com o IP.
Quando eu tinha alguns IPs, executei o mesmo código no mesmo servidor, mas em outro shell Python, e muitas vezes obtive um resultado em alguns ms, ou um erro (host não resolvido), em geral muito rapidamente. Alguns apresentavam erros que podiam levar segundos (ou até minutos) para aparecer.
Minha hipóteseé que o Python está enfileirando o gethostbyaddrcomando para executá-los sequencialmente, apesar de ter vários processos, e se alguns deles ficarem presos, os outros serão atrasados até que alguns soquetes sejam liberados para serem usados para aquela consulta.
Isso faz sentido? Isso é possível ?
Então tentei uma alternativa: em vez disso, criei a consulta reversa usando o DNS arpa ("[ip-in-reverse].in-addr.arpa.") e consultei o DNS diretamente, usando o DNS da Cloudflare (1.1. 1.1).
Isso fez com que a duração caísse para alguns ms, o que resolveu o problema.
Eu "meio que" consertei o bug, mas não consigo explicar exatamente por que isso aconteceu. Tenho alguns servidores conectados à minha instância do EC2 com um reverso inválido, portanto, gethostbyaddrfazer sentido travar, mas é possível que outro processo usando o mesmo código possa ficar travado em alguma fila? Talvez no nível Linux?
Aqui está minha hipótese:
- O Debian (Linux) está enfileirando as consultas para recuperar o gethostbyaddr e quando uma determinada quantidade está demorando muito, as demais são colocadas em uma fila antes de serem processadas
- A Amazon tem alguns problemas com seu DNS ou implementou alguma limitação de taxa ou atraso nas consultas, fazendo com que a resolução demore mais
- ???
O que estou perdendo que poderia explicar os atrasos?
Não há necessidade de amostra de código aqui, pois o problema não está relacionado diretamente ao código, mas como ele gethostbyaddré usado.
Obrigado pela ajuda.
Responder1
A rapidez com que você obtém uma resposta depende da rapidez com que o servidor DNS responsável pelo domínio responderá à pesquisa. O servidor DNS da AWS simplesmente encaminhará a consulta para o servidor apropriado (que poderá encaminhar para outro), a menos que a consulta e o resultado já estejam armazenados em cache. E como o DNS é tradicionalmente feito com UDP, esses servidores externos podem simplesmente não responder e, nesse caso, as solicitações serão repetidas até que ocorra algum tempo limite.
Em geral, é uma má ideia incluir uma consulta DNS de bloqueio (como gethostbyaddr) em seu código, quando a consulta precisa ser resolvida externamente. Você depende totalmente de algum servidor externo para continuar no seu programa, mas não tem controle de quanto tempo a consulta levará.