Desde a reconstrução hoje, estamos enfrentando um alto número de erros no servidor. Parece ser um problema de conexão com o nginx; no nginx/error.log, às vezes vejo rajadas de mensagens como 768 worker_connections are not enough assim:
2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP removido), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"
Alguma ideia de como podemos resolver isso? Temos muita CPU/memória disponível — poderíamos aumentar o número de ‘worker connections’?
Atualização: por enquanto, aumentei as conexões do worker, mas ainda estou recebendo esses erros (com menos frequência e para um número maior de workers). Estou realmente curioso se algo mudou recentemente que possa ter causado isso ou como posso investigar melhor.
## Comandos personalizados para executar após a construção
run:
- exec: echo "Início dos comandos personalizados"
- replace:
filename: "/etc/nginx/letsencrypt.conf"
from: "worker_connections 768"
to: "worker_connections 1768"
É interessante que isso tenha acontecido após uma reconstrução. Você realizou alguma ação em massa recentemente? Eu verificaria os logs do Sidekiq para ver se há um grande número de jobs lá também.
Recentemente, tive algumas ações em massa, pois mudamos para a Visualização de Miniaturas TC, mas não há nada na minha fila do Sidekiq, então posso descartar essa possibilidade com certeza.
Não tenho ideia — talvez tenhamos? Alguma ideia de como posso verificar isso?
Correto. Mas desativei qualquer aceleração e estou basicamente usando apenas para armazenar em cache imagens e avatares. Nunca foi um problema até hoje..
Haha, geralmente as pessoas usam o Google Analytics ou algo assim para obter essas informações. O painel do Discourse também possui visualizações de página diárias e visitas de usuários que podem ser usadas para chegar a essa conclusão.
Não é verdade, todo o seu site é servido via Cloudflare:
Mas isso pode ser completamente irrelevante, já que seu nginx está reclamando de conexões upstream em vez de downstream, o que significa que ele está ficando sem conexões entre nginx ⟷ unicorn.
Como mantemos uma conexão aberta para cada visitante devido ao message_bus (serviço de atualizações em tempo real), isso é meio esperado se seu site for um pouco popular.
Aumentar o worker_processes e o worker_connections é seguro e parece fazer sentido no seu caso. Por padrão, definimos o worker_processes igual ao número de núcleos de CPU que você tem. Quantos núcleos de CPU você possui?
Verdade Nós abandonamos isso há muito tempo… Temos cerca de 250 mil visualizações de página por dia (incluindo bots), então 500 não parece incomum. As visitas de usuários só rastreiam visitas de usuários logados, certo?
Certo — precisamos passar nossas requisições pela CF, mas não permitimos que eles mexam no nosso JavaScript, etc.
Temos 12 núcleos e 64 GB de RAM. A carga típica é de cerca de 2, e usamos 50% da nossa memória RAM.
Nós abandonamos isso há muito tempo… Temos cerca de 250 mil visualizações de página por dia (incluindo bots), então 500 não parece incomum. As visitas de usuários só rastreiam visitas de usuários logados, certo?
Colei o código errado - tentei o modelo do letsencrypt primeiro, mas acabei alterando o nginx.conf para 1768 conexões de worker.