через seamless_database_pool и mysql2.
Запущено в docker-like среде. Т.е контейнер с кастомным init.
Иногда у некоторых воркеров unicorn сносит крышу и они перестают отправлять определенные запросы в mysql - в лог сразу пишется closed MySQL connection.
Это прекрасно видно в strace - воркер принимает соединение, и дальше до ближайшего accept() видны только запись в лог и в сетевой сокет в сторону клиента. Подтверждается отсутствием этих запросов в tcpdump.
Из найденных пока закономерностей:
1) происходит не со всеми воркерами, а только с 5-7 из ~250
2) Фейлится только запросы типа SELECT x FROM y WHERE y.z = 'asdf';. Т.е они все связаны с одной и той же моделью и, соответственно, таблицей в БД.
3) Судя по логам unicorn, начинается после того, как какой-то из запросов в mysql не уложился в read_timeout.
Продолжается до тех пор, пока сломанные воркеры не умрут.
Есть идеи, в чем может быть проблема?
А что с сокетами на машинах происходит?
Один процесс = одно приложение. И крайне желательно, чтобы потоков тоже одна штука была. Просто попробуй, скорее всего решит твою проблему
Давно с рельсами работал. Там была беда с потерей в функциях таймаутов. Тут тоже могли в коде что-то потерять. Думаю, проблема в коде гема. Какой-нибудь коннекшн класс закрылся, но гем юзает его. И шлёт в закрытый гем-обьект. Обработку забыли прописать и все - тихие фейлы. Раньше так бывало в гемах
Обсуждают сегодня