- Navios
- 5 de setembro de 2026 às 15:18 UTC
- Autor
- Kamo
- Enviar
- 4d5ccc4
Corrigindo o commit anterior, que estava meio certo e causou um curto intervalo. O diagnóstico de memória estava correto: quatro trabalhadores, cada carregando sua própria cópia ~3GB do conjunto do modelo argos, não cabe um limite 12Gi, e o kernel recuperando páginas de modelo mmapped foi o que fez cada par de idioma frio levar segundos. Deixar dois trabalhadores era o remédio errado. /as línguas são servidas por estes mesmo Gunicorn trabalhadores, então com ambos dentro de uma longa tradução a sonda de prontidão não pode ser respondida — e em 2026-09-05 ambas as réplicas deixaram o Endpoints de serviço de uma só vez e tradução parou completamente. O parâmetro de avaliação da saúde precisa de um trabalhador livre para responder. Quatro trabalhadores com a memória para realmente segurar seus modelos satisfaz ambos restrições. Essa memória não existe no k1m1, que carrega o comando plano, o banco de dados e os construtores de CI em ~ 95% de suas solicitações de memória — perguntando para isso, há o que fez a segunda réplica falhar em programar o rollout. Então... o pod se move para k3m1, em ~63% e já mantendo o mesmo modelo definido neste hostPath de um período anterior. Ambas as réplicas foram sempre presas a um único nó; isto muda qual nó, não a história de redundância. Verificado após o lançamento: ambas as réplicas prontas no k3m1, ambas no Serviço endpoints, en->ru retornando saída correta.