Připojení k MySQL může být přerušeno řadou způsobů, ale doporučil bych znovu se podívat na odpověď Maria Carriona, protože je to velmi moudrá odpověď.
Zdá se pravděpodobné, že připojení je přerušeno, protože je sdíleno s ostatními procesy, což způsobuje chyby komunikačního protokolu...
...to se může snadno stát, pokud je fond připojení procesně vázán, což se domnívám, že v ActiveRecord je, což znamená, že stejné připojení může být "odhlášeno" několikrát současně v různých procesech.
Řešením je, že databázová připojení musí být navázána až PO fork příkaz na aplikačním serveru.
Nejsem si jistý, který server používáte, ale pokud používáte warmup funkce – ne.
Pokud před prvním síťovým požadavkem spouštíte nějaká databázová volání – nedělejte to.
Každá z těchto akcí by mohla potenciálně inicializovat fond připojení před fork dojde k zablokování, což způsobí sdílení fondu připojení MySQL mezi procesy, zatímco uzamykací systém nikoli.
Neříkám, že toto je jediný možný důvod problému, jak uvádí @sloth-jr, existují i jiné možnosti... ale většina z nich se podle vašeho popisu zdá méně pravděpodobná.
Vedlejší poznámka:
Každý proces může obsahovat několik spojení. Ve vašem případě můžete mít připojení až 500 x 36 . (viz úprava)
Obecně platí, že počet připojení ve fondu může být často stejný jako počet vláken v každém procesu (neměl by být menší než počet vláken, jinak vás spory zpomalí). Někdy je dobré přidat několik dalších v závislosti na vaší aplikaci.
UPRAVIT:
Omlouvám se za ignorování skutečnosti, že počet procesů odkazoval na data MySQL a ne na data aplikace.
Počet procesů, které jste ukázali, jsou data serveru MySQL, která zdá se, že používá vlákno na schéma IO připojení . Údaje „Proces“ ve skutečnosti počítají aktivní připojení a ne skutečné procesy nebo vlákna (ačkoli by se to mělo promítnout i do počtu vláken).
To znamená, že z možných 500 připojení na procesy aplikace (tj. pokud pro svou aplikaci používáte 8 procesů, bylo by to 8X500=4 000 povolených připojení) vaše aplikace dosud otevřela pouze 36 připojení.