Acabamos de atualizar de 3.0.6 para 3.1.2 e estou vendo muitos erros 503 em principalmente 3 pontos:
Muitos avatares falham ao carregar
Upload de imagens só funciona às vezes
Também estou vendo muitos erros para topics/timings
Eu olhei os logs do servidor e a maioria dos 503 nem sequer aparecem em production.log, mas o nginx está cheio deles. Pensando que poderia ser o rate limiting do nginx, tentei não usar o templates/web.ratelimited.template.yml, mas não pareceu ajudar. Ainda estou vendo uma grande quantidade de requisições respondidas com 503, principalmente user_avatars/show e pelo que entendi, production.log parece não vê-los.
Não notei nada de errado no sidekiq. No entanto, /logs teve erros com:
'hijack user_avatars show ' ainda está rodando após 90 segundos no db default, este processo pode precisar ser reiniciado!
mas estes foram há algumas horas e eu reconstruí a instância algumas vezes desde então e eles não apareceram novamente.
Esta instância está usando SSO, então os avatares (url) vêm de lá. Estamos usando S3 para imagens.
Estou um pouco confuso sobre o que está causando isso e estou sem ideias.
O servidor tem 16 GB e tem funcionado bem por meses antes da atualização.
É uma instância AWS e esta foi iniciada hoje, pouco antes da atualização (os dados do Discourse estão em volumes EBS) para alterar alguns parâmetros não relacionados.
O tráfego de rede (entrada e saída) aumentou significativamente após a atualização: os avatares parecem funcionar alguns segundos após o 503 inicial, então estou imaginando que há algum processo em execução na primeira vez que eles são solicitados.
No entanto, estou perdido sobre por que os uploads de imagens estão falhando aleatoriamente, assim como o endpoint topics/timings.
Não tenho certeza se pode estar relacionado a isso:
Pode ser que esse processo de atualização de fundo de avatar esteja atingindo o limite de taxa de 3500 PUT/s na AWS, causando falha nos uploads regulares enquanto os avatares são atualizados? /cc @sam
A atualização foi feita na manhã do dia 21. O tráfego de rede de entrada parece estar normalizando agora. O tráfego de saída ainda está mais alto que o usual, mas imagino que seja enquanto os avatares estão sendo cacheados. A quantidade de 503 para user_avatars/show é muito menor agora. Imagino que estes serão lentamente resolvidos com o tempo, à medida que mais avatares forem processados.
No entanto, ainda estamos vendo muitos erros 503 nos logs para principalmente outros dois endpoints:
POST /topics/timings
Ainda muitos erros 503 para este endpoint e alguns usuários relatando que tópicos visitados não estão sendo marcados como lidos. Não encontrei nenhuma informação sobre isso, pois a requisição não parece ser registrada no production.log. Os /logs não mostram nada relacionado.
Onde se poderia começar a depurar esses 503? Existe algum outro log que eu não conheça, ou há alguma maneira de tornar os logs mais verbosos talvez (em um sistema de produção)?
POST /uploads.json?client_id=...
Tudo que encontro no production.log para esses erros 503 são linhas como estas:
Extrato do production.log
Started POST “/uploads.json?client_id=X” for x.x.x.x at 2023-10-24 10:24:55 +0000
Processing by UploadsController#create as JSON
Parameters: {“upload_type”=>“composer”, “relativePath”=>“null”, “name”=>“Screenshot 2023-10-24 at 11.22.32.png”, “type”=>“image/png”, “sha1_checksum”=>“d1f11731320437724003c3840c5dcc5f934ba25a”, “file”=>#<ActionDispatch::Http::UploadedFile:0x00007f3c5e3c9898 @tempfile=#Tempfile:/tmp/RackMultipart20231024-1991-b30vit.png, @content_type=“image/png”, @original_filename=“Screenshot 2023-10-24 at 11.22.32.png”, @headers=“Content-Disposition: form-data; name="file"; filename="Screenshot 2023-10-24 at 11.22.32.png"\r\nContent-Type: image/png\r\n”>, “client_id”=>“X”}
Rendered text template (Duration: 0.0ms | Allocations: 1) Completed 503 Service Unavailable in 10ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 5007)
Nossos usuários relatam que eles tentam algumas vezes até funcionar… Consigo reproduzir o erro de forma mais ou menos consistente se tento fazer upload de (outro) arquivo se um já está em upload. Fazer upload deles um por um parece menos propenso a isso por algum motivo.
# free -h
total used free shared buff/cache available
Mem: 15Gi 3.8Gi 621Mi 1.1Gi 10Gi 10Gi
# lscpu --parse=core | egrep -v # | sort -u | wc -l
2
