Это connection pooler. Т.е. серверных соединений меньше, чем клиентских, и они переиспользуются под разные клиентские соединения. Ну и таймауты всякие тоже есть.
Такое может быть, если перед коммунальной базой один общий pgbouncer без разделения пулов между пользователями. У нас пулы для каждого сервиса отделены, поэтому такая проблема не возникает.
Так на картинке используемые индексы указаны. Если что это PEV, он визуализирует план на основе вывода EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT JSON).
Можно и без него, если все тщательно настроить. Но ошибиться легко, изменяя что-нибудь несвязанное, а цена ошибки весьма высока. Особенно если база коммунальная, а не выделенная под сервис. Поэтому в Авито его добавляют ко всем сервисам. Тем более, оверхеда он добавляет не так много при правильном подходе.
Тут проблема была все-таки не в pgbouncer'е, а в pgx, так что замена на odyssey, возможно, и не помогла бы. Ну, и odyssey пока не в стеке компании; его использование пришлось бы долго обосновывать.
За подсветку проблемы с коннектами на поде — спасибо, полезно!
Мы тоже испытывали боли с pgbouncer и cancel request, и решили их комплексно...
Хороший вопрос. Непосредственные причины, по которым у нас появился pgbouncer, не назову: это было до меня. Думаю, дело вот в чем:
Можно работать и без connection pooler'а, но это требует от сервиса жесткой дисциплины:
Нельзя делать долгие транзакции; недопустимо оставлять незакрытые транзакции
Нужно всегда четко следить за размером пула
Звучит просто, но на практике ошибиться очень легко, особенно, когда делаешь несвязанную с базой задачу. А в старых сервисах на пыхе иногда пул вообще не ограничен.
Кроме того, база в LXC контейнере — это относительно новая конфигурация для Авито. Большинство сервисов работает с базами на "коммуналках" — базы делят один сервер. Ограничивать потребление ресурсов конкретной базой там непросто; основной способ — ограничение размера пула. ДБА хотят это явно контролировать, а не перекладывать на разработчиков.
В общем, хорошему сервису pgbouncer практически не мешает. А плохому не дает наделать глупостей и позволяет удовлетворительно работать. Как-то так.
Слушаю) Про запрос и нагрузочное тестирование будет в следующей статье. И то, наверное, оптимизацию запроса придется опустить, т.к. материала много. Но план запроса будет. Эта же статья посвящена починке конкретного бага, который мешал нагрузить базу как следует. Вопросов оптимизации статья не касается.
За моделирование данных, подбор индексов, за оптимизацию запросов у нас отвечает разработчик сервиса. Он при этом плотно взаимодействует с DBA, использует их экспертизу.
Долго размышляя над проблемами совместного владения огромным количеством кода, казалось, были ясны все проблемы, но не хватало хорошей метафоры, для закрепления мысли
Никогда создавать новый функционал, внося дополнения в уже существующие методы, он достоин быть замеченным в новых участках кода
Интересно, но статью стоит вычитать более тщательно, имхо.
Интересно, а почему на той страничке doctype отсутствует? МС отчаянно игнорит w3c? В принципе, неудивительно, что в ФФ и опере сайт выглядит криво: рендеринг происходит в quirk mode, где вообще тяжело предугадать поведение браузера.
Если нравится интерфейс pidgin - это дорогого стоит, т.к. клентов с хорошим интерфейсом немного. Имхо проще покопаться и найти причину крэшей: поотключать плагины, протоколы, попытаться сделать ошибку повторяемой. У этого клиента неплохие логи в debug-режиме, между прочим.
У меня pidgin падал регулярно, основательно портя мне жизнь. Когда наконец я потратил полчаса на выяснение отношений с ним, выяснилось, что виноват был не im-клиент, а библиотека libnotify. Отключил нотификейшены - больше не глючит.
Это connection pooler. Т.е. серверных соединений меньше, чем клиентских, и они переиспользуются под разные клиентские соединения. Ну и таймауты всякие тоже есть.
Такое может быть, если перед коммунальной базой один общий pgbouncer без разделения пулов между пользователями. У нас пулы для каждого сервиса отделены, поэтому такая проблема не возникает.
Так на картинке используемые индексы указаны. Если что это PEV, он визуализирует план на основе вывода
EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT JSON).А какие сомнения терзают?
Можно и без него, если все тщательно настроить. Но ошибиться легко, изменяя что-нибудь несвязанное, а цена ошибки весьма высока. Особенно если база коммунальная, а не выделенная под сервис. Поэтому в Авито его добавляют ко всем сервисам. Тем более, оверхеда он добавляет не так много при правильном подходе.
Тот неловкий момент, когда почувствовал себя Аристофаном
Впрочем, удачи им с Савелием
Да, получилось, даже в контейнере подтверждается: https://github.com/iosadchiy/pgx_pgbouncer_issue/tree/database-sql
Задал вопрос нашему другу https://github.com/jackc/pgx/issues/679#issuecomment-699638269
Djlu подскажи, пожалуйста, как тебе удалось увидеть проблему в связке с database/sql? Что-то у меня пока не получается превысить заданный размер пула.
И даже понятно, почему: пулер database/sql не ждет, пока PgConn закроет свои коннекты
Тут проблема была все-таки не в pgbouncer'е, а в pgx, так что замена на odyssey, возможно, и не помогла бы. Ну, и odyssey пока не в стеке компании; его использование пришлось бы долго обосновывать.
За подсветку проблемы с коннектами на поде — спасибо, полезно!
А как решили, если не секрет?
Хороший вопрос. Непосредственные причины, по которым у нас появился pgbouncer, не назову: это было до меня. Думаю, дело вот в чем:
Можно работать и без connection pooler'а, но это требует от сервиса жесткой дисциплины:
Звучит просто, но на практике ошибиться очень легко, особенно, когда делаешь несвязанную с базой задачу. А в старых сервисах на пыхе иногда пул вообще не ограничен.
Кроме того, база в LXC контейнере — это относительно новая конфигурация для Авито. Большинство сервисов работает с базами на "коммуналках" — базы делят один сервер. Ограничивать потребление ресурсов конкретной базой там непросто; основной способ — ограничение размера пула. ДБА хотят это явно контролировать, а не перекладывать на разработчиков.
В общем, хорошему сервису pgbouncer практически не мешает. А плохому не дает наделать глупостей и позволяет удовлетворительно работать. Как-то так.
Кстати, вот хорошая статья об этих проблемах https://brandur.org/postgres-connections
За моделирование данных, подбор индексов, за оптимизацию запросов у нас отвечает разработчик сервиса. Он при этом плотно взаимодействует с DBA, использует их экспертизу.
Спасибо!
Интересно, но статью стоит вычитать более тщательно, имхо.
У меня pidgin падал регулярно, основательно портя мне жизнь. Когда наконец я потратил полчаса на выяснение отношений с ним, выяснилось, что виноват был не im-клиент, а библиотека libnotify. Отключил нотификейшены - больше не глючит.