Проблемът беше разрешен, след като започнахме да възстановяваме връзките към базата данни. Използвахме sequel
в проекта и Passenger сам се справя с проблема само когато се използва ActiveRecord.
За да го разшири, по подразбиране Passenger използва интелигентно генериране на ruby приложения. Първо ражда процес на предварително зареждане, който зарежда рамката и всички библиотеки. След този процес на предварително зареждане ражда работни процеси, когато възникне необходимост, които обработват заявките. Когато се създават работни процеси, всички файлови дескриптори се наследяват от процеса на предварително зареждане. Така че, ако не възстановите връзката с базата данни, всички работни процеси споделят една, установена от предварителното зареждане. Което води до различни видове странно поведение. Като заявки, които отнемат твърде много време.
Преди това също преместихме обработката на WebSocket връзките в отделен процес. Не съм сигурен обаче дали е допринесло за проблема.
Повече за това тук:
Прекъснете връзката, ако използвате разклонителен уеб сървър с предварително зареждане на код
Неволно споделяне на файлов дескриптор
Изпълнение на сървъра на Action Cable на същия хост и порт, под под-URI