MySQLへの接続はさまざまな方法で中断される可能性がありますが、非常に賢明な回答であるため、MarioCarrionの回答を再検討することをお勧めします。
他のプロセスと共有されているために接続が中断され、通信プロトコルエラーが発生している可能性があります...
...これは、接続プールがプロセスにバインドされている場合に簡単に発生する可能性があります。これは、ActiveRecordでは、同じ接続が異なるプロセスで同時に何度も「チェックアウト」される可能性があることを意味します。
解決策は、データベース接続はforkの後でのみ確立する必要があるということです。 アプリケーションサーバーのステートメント。
使用しているサーバーはわかりませんが、warmupを使用している場合 機能-しないでください。
最初のネットワークリクエストの前にデータベース呼び出しを実行している場合は、実行しないでください。
これらのアクションのいずれかが、forkの前に接続プールを初期化する可能性があります が発生し、ロックシステムが共有されていないときにMySQL接続プールがプロセス間で共有されます。
@ sloth-jrが述べているように、これが問題の唯一の考えられる理由であると言っているわけではありません。他のオプションもあります...しかし、あなたの説明によれば、それらのほとんどは可能性が低いようです。
補足：
各プロセスは多数の接続を保持できます。あなたの場合、最大500X36の接続がある可能性があります 。 （編集を参照）
一般に、プール内の接続の数は、多くの場合、各プロセスのスレッドの数と同じである可能性があります（スレッドの数より少なくすることはできません。そうしないと、競合によって速度が低下します）。アプリケーションによっては、さらにいくつか追加するとよい場合があります。
編集：
プロセスカウントがアプリケーションデータではなくMySQLデータを参照していたという事実を無視して申し訳ありません。
表示されたプロセス数はMySQLサーバーデータであり、接続IOスキームごとにスレッドを使用しているようです 。 「プロセス」データは実際にアクティブな接続をカウントします 実際のプロセスやスレッドではありません（ただし、スレッドの数にも変換されるはずです）。
つまり、アプリケーションプロセスごとに可能な500の接続のうち（つまり、アプリケーションに8つのプロセスを使用している場合、8X500 =4,000の許可された接続になります）、アプリケーションはこれまでに36の接続しか開きませんでした。