Сложная проблема, возникающая в производстве в течение длительного времени, мы понятия не имеем, откуда она взялась.Может иногда воспроизводить его на локальном хосте, поддержка Heroku Enterprise не имеет для этого никакого смысла.
В нашей производственной базе данных в настоящее время мы имеем следующую настройку:
- Passenger Standalone, многопоточность отключена, ограничено 25 процессами MAX.Нет минимальной настройки.
- 3 веб-дин
a SELECT * FROM pg_stat_activity GROUP BY client_addr и подсчет количества соединений на экземпляр показывает, что более одного соединения PSQL открыто для одного пассажирского процесса во время нашего пикадней.
Допущения:
- Один адрес равен одному Dyno (подтверждено персоналом Heroku)
- Пассажир не порождает более 25 процессов одновременно (подтвержденос
passenger-status во время этих пиков)
Вот скриншот того, что выглядит как SELECT * FROM pg_stat_activity;:
На скриншоте мы можемобратите внимание, что есть 45 psql соединений , поступающих от того же динамо, которое управляет пассажиром.Если мы следуем нашей предыдущей логике, у нее не должно быть более 1 соединения на процесс Passenger, поэтому 25.
Журналы не выглядят необычно, ничего не упоминая ни о сбое dyno / сбое процесса.
Вот скриншот нашего статуса пассажира для того же динамо (в другое время, просто чтобы доказать, что для одного динамо создано не больше 25 процессов): 
И, наконец, один из ответов, которые мы получили от службы поддержки Heroku (Кстати, потрясающая поддержка)
Я также видел предыдущие сообщения о том, что Passenger использует больше соединений, чем ожидалось, но большинство из них были закрыты из-за трудностей с воспроизведением, к сожалению,.
В документации для Пассажира объясняется, что Пассажир сам обрабатывает соединения ActiveRecord.
Любые выводы приветствуются.Спасибо!
Различная информация:
- Версия Ruby:
2.4.x - Версия Rails:
5.1.x - Версия для пассажиров:
5.3.x - PG Версия:
10.x - ActiveRecord Версия:
5.1.x
Если вам нужна дополнительная информация, просто дайте мне знать в комментарияхЯ с удовольствием обновлю этот пост.
И последнее. : Мы используем ActionCable.Я где-то читал, что пассажир странно обрабатывает сокетные соединения (открывает несколько скрытый процесс, чтобы поддерживать соединение).Это один из наших вариантов, но пока не повезло в воспроизведении на localhost.Если кто-нибудь может подтвердить, как Пассажир обрабатывает соединения ActionCable, он будет очень признателен.
Обновление 1 (01/10/2018):
Эксперимент:
- Отключите функцию автоматического объяснения NewRelic, как описано здесь: https://devcenter.heroku.com/articles/forked-pg-connections#disabling-new-relic-explain
- Локально запустите сервер Passenger с минимальным и максимальным размером пула, установленным в 3 (чем больше, тем больше горит мой компьютер), затемуничтожить процесс с помощью различных сигналов (SIGKILL, SIGTERM), чтобы попытаться проверить, правильно ли закрыты соединения.Они есть.