A conexão com o MySQL pode ser interrompida de várias maneiras, mas eu recomendaria revisitar a resposta de Mario Carrion, pois é uma resposta muito sábia.

Parece provável que a conexão seja interrompida porque está sendo compartilhada com os outros processos, causando erros de protocolo de comunicação...

... isso pode acontecer facilmente se o pool de conexão for vinculado ao processo, o que acredito que seja, no ActiveRecord, o que significa que a mesma conexão pode ser "retirada" várias vezes simultaneamente em diferentes processos.

A solução é que as conexões de banco de dados devem ser estabelecidas somente APÓS o fork instrução no servidor de aplicativos.

Não tenho certeza de qual servidor você está usando, mas se estiver usando um warmup recurso - não.

Se você estiver executando qualquer chamada de banco de dados antes da primeira solicitação de rede, não faça isso.

Qualquer uma dessas ações poderia inicializar o pool de conexões antes de fork ing ocorre, fazendo com que o pool de conexão do MySQL seja compartilhado entre os processos enquanto o sistema de bloqueio não é.

Não estou dizendo que essa é a única razão possível para o problema, conforme declarado por @sloth-jr, existem outras opções ... mas a maioria delas parece menos provável de acordo com sua descrição.

Nota:

Cada processo pode conter várias conexões. No seu caso, você pode ter conexões de até 500X36 . (veja a edição)

Em geral, o número de conexões no pool geralmente pode ser o mesmo que o número de threads em cada processo (não deve ser menor que o número de threads, ou a contenção o atrasará). Às vezes é bom adicionar mais alguns dependendo da sua aplicação.

EDITAR:

Peço desculpas por ignorar o fato de que a contagem de processos estava referenciando os dados do MySQL e não os dados do aplicativo.

A contagem de processos que você mostrou são os dados do servidor MySQL, que parece usar um encadeamento por esquema de E/S de conexão . Os dados de "Processo" realmente contam conexões ativas e não processos ou threads reais (embora também deva se traduzir no número de threads).

Isso significa que das 500 conexões possíveis por processos de aplicativo (ou seja, se você estiver usando 8 processos para seu aplicativo, isso seria 8X500 =4.000 conexões permitidas), seu aplicativo abriu apenas 36 conexões até agora.