Alguém pode fornecer clareza sobre o pooling de banco de dados do Sidekiq worker?
Atualmente, definimos DISCOURSE_DB_POOL para 15, com 2 workers do Sidekiq, cada um com concorrência de 10. Após ler a documentação do Sidekiq, parece que as threads do Sidekiq compartilham o pool de banco de dados, daí eu prever um máximo de 15 * 2 = 30 conexões de banco de dados dos workers do Sidekiq. No entanto, apesar desse entendimento, estamos observando picos em conexões de banco de dados excedendo o máximo esperado de 30.
Receio não saber os detalhes de como tudo isso funciona de imediato.
Pode valer a pena verificar se você personalizou o UNICORN_SIDEKIQS env. Isso indica quantos processos sidekiq são iniciados (cada um terá muitas threads).
O que exatamente seu gráfico está mostrando? São ‘conexões simultâneas’? Ou é ‘número de conexões criadas’? Se for o último, talvez algumas conexões estejam sendo criadas e destruídas muito rapidamente.
E uma última pergunta: que problema você está tentando resolver aqui? Há algum problema sendo causado pelo número de conexões?
Isso significa que temos 2 processos Sidekiq, cada um com 10 threads.
O gráfico mostra o número atual de conexões de clientes.
Estamos tentando configurar corretamente o tamanho do pool de conexões (RDS proxy na frente do PostgreSQL). Para fazer isso, precisamos de um melhor entendimento do pooling de conexões no lado da aplicação. Por que a aplicação não está respeitando a configuração DISCOURSE_DB_POOL como esperado?
Se DISCOURSE_DB_POOL estiver funcionando como esperado, por que vemos picos tão grandes nas conexões do banco de dados? Esses picos parecem estar alinhados com as execuções do job agendado PeriodicalUpdates.
Por favor, me avise se tiver mais perguntas. Agradeço a ajuda para desvendar o mistério.
