Re: Драйвер для postgresql

[Andrei Soroker]

Драйвер:
https://github.com/wg/epgsql

Пул:
https://github.com/devinus/poolboy

2013/2/3 Nikolai Sevostjanov <nikolai.s...@gmail.com>:
> Добрый день,
>
> Прошло два года с момента создания прошлой аналогичной темы и мне хочется
> узнать что изменилось в плане драйверов для postgresql.
>
> Мы хотим сделать restful API для нашего сервиса и если в случае выбора
> библиотек для этого restful особо вариантов нету, точнее их всего два:
> cowboy rest и mochiweb + webmachine - и оба выглядят безпроблемными,
> развивающимися библиотеками (но скорее всего возмем первый вариант потому
> что "модно и молодежно"), то в случае драйвера для postgresql не всё так
> радужно. Насколько я понял, есть 4 варианта: а) pgsql б) pgsql2 (непонятно в
> каком состоянии) в) epgsql г) epgsql асинхронный форк - и какой вариант
> подойдет нам - я не могу понять. Так что если кто то использует какой нибудь
> драйвер для postgresql - поделитесь пожалуйста информацией насколько он
> "проблемный"/"безпроблемный", "быстрый"/"не быстрый" и т.д..
>
> --
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Чат: xmpp://erl...@conference.jabber.ru
> Чат для оффтопа: xmpp://erlang...@conference.jabber.ru
> Правила, действующие в чате и рассылке:
> http://erlanger.ru/ru/erlang-at-conference-jabber-ru
>
> Написать письмо: erlang-...@googlegroups.com
> Отписаться: erlang-russia...@googlegroups.com
> ---
> Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
>
> Чтобы отказаться от подписки на эту группу и перестать получать из нее
> сообщения, отправьте электронное письмо на адрес
> erlang-russia...@googlegroups.com.
> Подробнее о функциях можно узнать на странице
> https://groups.google.com/groups/opt_out.
>
>

[Sergey Prokhorov]

Я использую "асинхронный форк" epgsql, но асинхронные возможности пока не использовал. Всё устраивает, на глаз ~50 INSERT транзакций, по 5-15 инсертов в каждой в секунду на пуле в 10-25 коннектов справляется хорошо.

Пул poolboy, но я запускаю без промежуточного gen-server - 

    %% supervisor spec:
    {ok, DbPoolOpts} = application:get_env(db_pool),
    PoolName = sp_db,
    PoolArgs = [{name, {local, PoolName}},
                {worker_module, PoolName},
                {size, proplists:get_value(size, DbPoolOpts, 10)},
                {max_overflow, proplists:get_value(max_overflow, DbPoolOpts, 15)}],

    {ok, PoolWorkerArgs} = application:get_env(db),

    ...
    Childs = [
        poolboy:child_spec(PoolName, PoolArgs, PoolWorkerArgs), % postgres

        ...
    ]

-module(sp_db).
-behaviour(poolboy_worker).


-export([start_link/1]).
-export([get_conn/0, return_conn/1, transaction/1]).


start_link([Host, Username, Password, Opts]) ->
    pgsql:connect(Host, Username, Password, Opts).


-spec get_conn() -> pid().
get_conn() ->
    poolboy:checkout(?MODULE).


-spec return_conn(pid()) -> ok.
return_conn(C) ->
    poolboy:checkin(?MODULE, C).

воскресенье, 3 февраля 2013 г., 19:06:03 UTC+4 пользователь Nikolai Sevostjanov написал:

[Nikolai Sevostjanov]

Спасибо за подробный ответ. Я так понимаю с epgsql + poolboy никаких проблем не возникало?

понедельник, 4 февраля 2013 г., 11:04:29 UTC+3 пользователь Sergey Prokhorov написал:

[Sergey Prokhorov]

С poolboy и epgsql есть 2 небольших проблемы и одно подозрительное наблюдение =)

Проблема 1:

Может завалиться если postgresql отправить перезагружаться. Сам не пробовал, но говорят есть такое.

Проблема 2:

Сразу гасит Overflow воркеры. У пулбоя есть 2 параметра - первый - это сколько воркеров он запустит сразу и будет поддерживать в живом состоянии всегда и 2-й это сколько он может запустить дополнительных воркеров, если всех расхватали (overflow). Так вот, если возвращаешь коннекшн в "переполненный" пул, то его сразу прибивают. А хотелось бы, чтобы делали это после некоторого таймаута.

Наблюдение:

У меня выставлен размер пула 10 соединений с max_overflow 15 Т.е. в пике может создавать до 25 подключений. Но 90% времени используется менее 10 подключений.

И почему-то, если наблюдать за процессами постгреса в htop, то видно, что время от времени все 10 воркеров одновременно гасятся и запускаются заново (pid-ы процессов OS меняются). И происходит это когда poolboy переходит из состояния ready в состояние overflow (или обратно, точно не знаю).

Каких-то существенных проблем мне это не создаёт, поэтому пока не разбирался.

вторник, 5 февраля 2013 г., 13:50:54 UTC+4 пользователь Nikolai Sevostjanov написал:

[Igor Karymov]

проблемма с пулбоем очень простая, если вдруг пропадёт коннекция или перезапустишь БД

то пул завалится, а вмести с ним вероятно и вся нода.

Используем специальный форк пулбоя от ddosia для борьбы с данным эффектом.

[Max Lapshin]

А чего в мастер не запушили?

2013/2/7 Igor Karymov <ingh...@gmail.com>

проблемма с пулбоем очень простая, если вдруг пропадёт коннекция или перезапустишь БД

то пул завалится, а вмести с ним вероятно и вся нода.

Используем специальный форк пулбоя от ddosia для борьбы с данным эффектом.

--

[Igor Karymov]

Часть уже запушили.

Вторая часть я так понимаю слишком сильно меняет поведение исходного пулбоя.

https://github.com/unisontech/poolboy/tree/dch-backoff

[Daniil Churikov]

С этими изменениями некоторые существующие тесты концептуально перестают работать, надо написать новые и
больше тестинга, потом оформлю пулреквест (не уверен что пройдет, сильно кардинальные изменения)

четверг, 7 февраля 2013 г., 17:59:12 UTC+4 пользователь Max Lapshin написал: