Acúmulo de memória até o serviço parar
Welcome!
- [x] Yes, I have searched for similar issues on GitHub and found none.
What did you do?
Possu aproximadamente 79 instâncias no meu evolution, destas (neste momento), 47 instâncias "connecting" e 32 instâncias "abertas". Noto que no log do evolution há muita info do tipo ChannelStartupService, proveniente dos "connectings". O que acontece é que a memória do container sobe até um pouco mais de 4gb até crashar (gráfico do zabbix em anexo), fazendo com que o container reinicie. Tentei usar mem_limit, mem_swaplimit, além de tuning no postgres, mas não surtiu nenhum efeito prático.
What did you expect?
Que o container se mantenha estável ou alguma variável que possa ajudar no desempenho.
What did you observe instead of what you expected?
O container para de funcionar, fazendo com que o serviço seja reiniciado.
Screenshots/Videos
Esta a info que recebo no console
Which version of the API are you using?
image: atendai/evolution-api:latest (2.2.3)
What is your environment?
Docker
Other environment specifications
Intel(R) Xeon(R) E-2176G CPU @ 3.70GHz 64Gb RAM
If applicable, paste the log output
No response
Additional Notes
.env
AUTHENTICATION_API_KEY=xxxxxxxxxxxxxxx DATABASE_ENABLED=true DATABASE_PROVIDER=postgresql DATABASE_CONNECTION_URI='postgresql://postgres:xxxxxxxx@evolution-postgres:5432/evolution?schema=public' CACHE_REDIS_ENABLED=true CACHE_REDIS_URI=redis://evolution-redis:6379/6 CACHE_REDIS_PREFIX_KEY=evolution CACHE_LOCAL_ENABLED=false WEBSOCKET_ENABLED=true WEBHOOK_EVENTS_ERRORS=true WEBHOOK_EVENTS_ERRORS_WEBHOOK=true
Já tentou com ignore groups normal? Tenho 60 instâncias aqui tranquilo
Essa situação pode depender muito da quantidade de demanda que essas instâncias recebem. Se você limitar a memória as instâncias vão cair e você não receberá mais msgs. Tentou conceder mais memória e vê se o gráfico estabiliza?
Mesmo erro aqui. Começou do nada
Pessoal, pode não ter relação direta, mas nas novas versões do Evolution (acho que da 2.1 para cima) ele tem um processo que roda de 30 em 30 minutos para recuperar mensagens perdidas aonde ele faz uma sincronização das mensagens com o chatwoot e existe uma query gigantesca que acaba degradando bastante o ambiente. Em teoria, se o sistema operacional enfileirar muitos processos simultaneamente, os dados desses processos podem ser carregados para a memória RAM, desde que haja espaço disponível. Com várias instâncias acredito que seja uma possibilidade.
Tente analisar se o aumento de memória tem algum padrão de subida, no meu caso o processamento sobe bastante como na imagem abaixo.
Se alterar para false a variável DATABASE_SAVE_MESSAGE_UPDATE esse consumo para de ocorrer, mas a funcionalidade de recuperação de mensagens perdidas também para de funcionar. Ela roda em 2 momentos: quando a instância fica open e de 30 em 30 minutos.
Meu erro tinha a ver com isso aqui: https://github.com/EvolutionAPI/evolution-api/issues/1509 Segui a solução da thread e o erro parou.