виртуалку под квм
железо хоста своё
конфиг виртуалки идентичен, сервер в остальном пуст, диски были сас, стали ссд
был старый дебиан, стала новая убунта
эликсир и эрланг поставлен через asdf
конфиг постгреса идентичен
на новом месте сыпятся
(ErlangError) Erlang error: {:timeout, {:gen_server, :call, [#PID<0.3127.0>, {:checkout, #Reference<0.2969689412.2365325315.153707>, true, 15000}, 5000]}}
(DBConnection.ConnectionError) connection not available because of disconnection
как бы подебажить и получить более подробную информацию по причинам ошибок?
iex -S mix run --no-start Запустит шелл без старта аппы Оттуда можете проверить конфигурации И попробовать запустить аппликейшн экто с данными конфигурациями
Проблемы с запуском нет. Более того оно работает несколько часов, а потом начинает сыпаться. Часть запросов обрабатывается, часть нет
А, тоесть это не при запуске, хым Ну тут видно, что соединение теряется, а не постгря или эликсир отключаются. Так что дело в сети Я бы помониторил что пишет ss -tulpn по поводу соединений, посмотрел бы на ping. Ещё я бы посмотрел на состояния интерфейсов и dmesg, вдруг что-то хардварное Можно даже собрать tcpdump на всякий случай, но я думаю он ничего особенного не покажет, только tcp-пакеты, которые остались без ответа
Ещё может быть дело в неправильной конфигурации ресурсов машины с базой данных. Может быть там очень много тредов, которые кушают всё время CPU, и не дают базе держать сокеты открытыми
Такое ещё часто бывает, когда система уходит в своп, кстати
У нового постгреса меньший лимит коннекшнов чем у старого?
Тогда бы было connrefused
На новой машине меньший лимит на количество открытых сокетов чем на старой?
Если вопрос про net.core.somaxconn то 4096
Скорее про ulimit
Там только на файлы 1024, надо поднять
В момент когда начинают сыпаться ошибки получается ли подключиться к постгресу каким-нибудь клиентом?
Пробовали обновить db_connection? В новых версиях эта ошибка вообще не пишется
Я посмотрел код db_connection Такая ошибка скорее всего происходит когда connection занят чем-то. Вам бы попрофилировать процессы модуля DBConnection.Connection и посмотреть как какой функции и с каким стейтом они висят. Можно банально посомтреть пиды в обсервере и потыкать их через Process.info (ErlangError) Erlang error: {:timeout, {:gen_server, :call, [#PID<0.3127.0>, {:checkout, #Reference<0.2969689412.2365325315.153707>, true, 15000}, 5000]}} А такая ошибка бывает только когда дисконнект вызван явно, либо когда используется только-только созданный connection (DBConnection.ConnectionError) connection not available because of disconnection
Я бы ещё сделал поллинг через :sys.get_state. Это замедлит работу процесса, но позволит понять его стейт, с которым он таймаутится
в целом из интересного удалось выяснить только то, что похоже проблема касается только отдельных процессов у низ зашкаливает очередь сообщений с сообщениями о чекауте
Значит в одном connection зависает транзакция или долго исполняется запрос
с ними же по истечении какого-то времени что-то должно произойти, чтобы они вечно не висели?
С обычными запросами — да. С транзакциями — нет
проблема именно с самыми тривиальными селектами причём после перезагрузки постгреса процесс db_connection так и остался висеть и не прибился это в какую сторону бы покопать?
Хым, я тут даже не знаю. Опять же, вы используете очень старый db_connection, может попробуете его обновить? Может этот баг уже известен и пофикшен
ну да, это была первая идея, обновить коннекшн, а для него экто, а для него феникс, ... только с приложением на 3000 тестов это тянет не на день))
Ну, обновить рано или поздно придётся А чинить такой плавающий баг, наверное, придётся патчами в db_connection
Обсуждают сегодня