La connexion à MySQL peut être interrompue par un certain nombre de moyens, mais je recommanderais de revoir la réponse de Mario Carrion car c'est une réponse très sage.
Il semble probable que la connexion soit interrompue car elle est partagée avec les autres processus, provoquant des erreurs de protocole de communication...
... cela pourrait facilement se produire si le pool de connexions est lié au processus, ce que je pense, dans ActiveRecord, ce qui signifie que la même connexion peut être "extraite" plusieurs fois simultanément dans différents processus.
La solution est que les connexions à la base de données doivent être établies uniquement APRÈS le fork déclaration dans le serveur d'application.
Je ne sais pas quel serveur vous utilisez, mais si vous utilisez un warmup fonctionnalité - ne pas.
Si vous exécutez des appels de base de données avant la première requête réseau, ne le faites pas.
L'une ou l'autre de ces actions pourrait potentiellement initialiser le pool de connexions avant fork ing se produit, entraînant le partage du pool de connexions MySQL entre les processus alors que le système de verrouillage ne l'est pas.
Je ne dis pas que c'est la seule raison possible du problème, comme l'a indiqué @sloth-jr, il existe d'autres options... mais la plupart d'entre elles semblent moins probables selon votre description.
Remarque :
Chaque processus peut contenir un certain nombre de connexions. Dans votre cas, vous pourriez avoir jusqu'à 500 x 36 connexions . (voir modification)
En général, le nombre de connexions dans le pool peut souvent être le même que le nombre de threads dans chaque processus (il ne doit pas être inférieur au nombre de threads, sinon la contention vous ralentira). Parfois, il est bon d'en ajouter quelques-uns de plus en fonction de votre application.
MODIF :
Je m'excuse d'avoir ignoré le fait que le nombre de processus faisait référence aux données MySQL et non aux données d'application.
Le nombre de processus que vous avez montré correspond aux données du serveur MySQL, qui semble utiliser un thread par schéma d'E/S de connexion . Les données "Process" comptent en fait les connexions actives et non des processus ou des threads réels (bien que cela devrait également se traduire par le nombre de threads).
Cela signifie que sur 500 connexions possibles par processus d'application (c'est-à-dire, si vous utilisez 8 processus pour votre application, ce serait 8 x 500 =4 000 connexions autorisées), votre application n'a ouvert que 36 connexions jusqu'à présent.
