Das Problem wurde behoben, nachdem wir begonnen hatten, die Verbindungen zur Datenbank wiederherzustellen. Wir haben sequel verwendet des Projekts, und Passenger behandelt das Problem nur dann selbst, wenn ActiveRecord verwendet wird.
Um dies zu erweitern, verwendet Passenger standardmäßig Smart Spawning für Ruby-Apps. Es erzeugt zuerst den Preloader-Prozess, der das Framework und alle Bibliotheken lädt. Danach erzeugt der Preloader-Prozess bei Bedarf Worker-Prozesse, die die Anfragen bearbeiten. Beim Spawnen von Arbeitsprozessen werden alle Dateideskriptoren vom Preloader-Prozess geerbt. Wenn Sie also die Verbindung zur Datenbank nicht wiederherstellen, teilen sich alle Worker-Prozesse eine, die vom Preloader hergestellt wurde. Was zu allen möglichen seltsamen Verhaltensweisen führt. Zum Beispiel Anfragen, die zu lange dauern.
Davor haben wir auch die Handhabung von WebSocket-Verbindungen in einen separaten Prozess verschoben. Ich bin mir jedoch nicht sicher, ob es zu dem Problem beigetragen hat.
Mehr dazu hier:
Verbindung trennen, wenn Forking-Webserver mit Code-Preloading verwendet wird
Unbeabsichtigtes Teilen von Dateideskriptoren
Ausführen des Action Cable-Servers auf demselben Host und Port unter einem Sub-URI
