VL
вываливай ответ
приложение построено на передаче reform.Querier (интерфейс: либо транзакция, либо API для получения коннекта к базе) через DI. В одном месте внутри транзакции неявно получался ещё один коннект
Size: a a a
2019 January 15
Е
я 1 раз в жизни для гоу использовал gdb
AC
Хотя - ну, ппроф тоже, да
VL
всё это отлично работало, пока не случался спайк во внешней системе
VL
с кучей таймаутов
Е
и то потому что про некоторые функции не знал
Е
в итоге wget /pprof/trace
AC
> В одном месте внутри транзакции неявно получался ещё один коннект
Как ты сказал: "Это не проблема с Go"?
Как ты сказал: "Это не проблема с Go"?
VL
> В одном месте внутри транзакции неявно получался ещё один коннект
Как ты сказал: "Это не проблема с Go"?
Как ты сказал: "Это не проблема с Go"?
это не проблема Go. Это проблема логики работы с транзакциями.
AC
Ну да - это не проблема с Go
Е
приложение построено на передаче reform.Querier (интерфейс: либо транзакция, либо API для получения коннекта к базе) через DI. В одном месте внутри транзакции неявно получался ещё один коннект
по кол-ву ps aux было бы видно
Е
кол-во воркеров с лимитом
AC
Попробуй такого добиться в расте
Е
кстати, я сталкивался с подобной проблемой, где start transaction делался, но не делался возврат в пул транзакции
Е
в итоге она коммитилась через время
Е
когда другой юзер коннект заюзает
AC
Так try-with-resources есть же уже даже в Go
AC
Как вам это всё удается-то
VL
tl;dr в итоге при спайке появлялась 1000 транзакций, которые после таймаута от внешней системы пытались получить коннект от БД. Но все коннекты заняли сами.
AC
Но, с другой стороны - опытным путем я знаю, что достижимый лимит для постгреса это где-то 2000+ коннектов