powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Глюки и низкая произодительность ODBC драйвера
36 сообщений из 36, показаны все 2 страниц
Глюки и низкая произодительность ODBC драйвера
    #38728018
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал тестовую утилиту и выложил ее сюда - https://github.com/vvromanov/db_test
Результат профилирования лежит тут http://freepcrf.com/files/db_test_pq.pdf
Тестировалось на Centos 6.5 x64, ноутбук Lenovo t500, 8Gb, SSD. База расположено локально, 9.3
Что видно.
Очень низкая скорость. Простейший запрос выполнятеся 10 тысяч раз в секунду. Например, TimesTen делает это в 20 раз быстрее

Основная нагрузка приходиться на работу с сетью и совсем ненужный tz_convert

Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

Jabber: vromanov@gmail.com
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728191
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

10К/sec - не так уж и плохо. покажите планы

tz_convert - а это база может и не делать, если уж "скорость" нам так нужна
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728203
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Misha Tyurin,

Какие такие планы? Выборка по первичному ключу в таблице из двух колонок! Вот сравнение этого теста с разными базами.

Код: plaintext
1.
2.
3.
4.
     Db Name | insert | select | update | delete |
  PostgreSql |   8034 |   9808 |   6857 |   9314 |
       MySql |  22675 |  16035 |  18782 |  19992 |
    TimesTen |  85792 | 198601 |  70466 |  66461 |
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728229
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

Чего вы хотите получить в результате таких (“выборка по первичному ключу в таблице из двух колонок”) тестов? Показать, что для очень простых (примитивных даже) запросов PostgreSQL медленнее MySQL и ORACLE TimesTen? Это вполне ожидаемо.

Сравнивать с TimesTen совсем не корректно, т.к. это база в памяти, нету там IO.

Вы не могли бы выделить SQL скрипты для (1) инициализации и (2) прогонки теста — я бы тоже погонял у себя.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728237
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorov,

Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять.

Запросы вот
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE bench (
    id integer NOT NULL, 
    value integer NOT NULL, 
    CONSTRAINT bench_pk PRIMARY KEY (id) 
);

INSERT INTO bench (id, value) VALUES ($1, $2)
SELECT value FROM bench WHERE id=$1
UPDATE bench SET value=$1 WHERE id=$2
DELETE FROM bench WHERE id=$1

...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728269
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

как портится ?
какая именно ошибка?


PS на одбс вы давно батон крошите, но как-то вяло.
может быть вам оно не надо ?
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728301
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovСделал тестовую утилиту и выложил ее сюда - https://github.com/vvromanov/db_test
Результат профилирования лежит тут http://freepcrf.com/files/db_test_pq.pdf
Тестировалось на Centos 6.5 x64, ноутбук Lenovo t500, 8Gb, SSD. База расположено локально, 9.3
Что видно.
Очень низкая скорость. Простейший запрос выполнятеся 10 тысяч раз в секунду. Например, TimesTen делает это в 20 раз быстрее

Основная нагрузка приходиться на работу с сетью и совсем ненужный tz_convert

Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

Jabber: vromanov@gmail.com


так уже обсуждалось что ODBC драйвер у PostgreSQL старый и небыстрый...
и опять же уже советовалось использовать напрямую libpq и сравнивать по скорости (не забывая использовать prepared запросы).

ODBC в общем устаревшее 100 лет назад решение... сейчас или Java+jdbc или Net+npgsql или нативные libpq для сишных клиентов.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728303
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovvyegorov,

Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять.



так известный факт и лечить его никто не будет ибо он никому кроме вас не нужен под highload где это становится актуально.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728312
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Сценарий такой
Код: plaintext
1.
2.
3.
4.
db_insert(1,1);
db_insert(1,2);
db_insert(2,3);
db_select(2,&value);
первый запрос успешно выполнятеся.
второй возращает
Код: plaintext
1.
2.
3.
4.
5.
6.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]ERROR: duplicate key value violates unique constraint "bench_pk"
Key (id)=(1) already exists.;
Error while executing the query
ODBC Error/Warning = 23505, Additional Error/Warning = 7
Третий возвращает
Код: plaintext
1.
2.
3.
4.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]Error while executing the query
ODBC Error/Warning = S1000, Additional Error/Warning = 7
Четвертый успешно работает
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728317
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqPS на одбс вы давно батон крошите, но как-то вяло.
может быть вам оно не надо ?
Оно нам надо по очень простой причине. Мы хотив нашем приложении поддержать работу с несколькими базами данных. Сейчас это TimesTen & PQ. ODBC именно для этого и предназначен - для стандартного интерфейса к разным базам данных.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728361
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukтак уже обсуждалось что ODBC драйвер у PostgreSQL старый и небыстрый...
и опять же уже советовалось использовать напрямую libpq и сравнивать по скорости (не забывая использовать prepared запросы).
Приделаю еще к тесту libpq. Посмотрим что получится. В крайнем случае похоже придется писать свою реализацию подмножества ODBC.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728382
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovODBC Error/Warning = S1000, Additional Error/Warning = 7

про S1000 вы писали уйму времени тому . так и не выяснили ?

в http://www.postgresql.org/docs/current/static/errcodes-appendix.html этого кода нет. (в отличии от 23505 )

наверняка за это время вы таки выяснили, что это, и чем борется (я догадываюсь, но голословно предполагать не хочу).
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728400
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovqwwq,

Сценарий такой
Код: plaintext
1.
2.
3.
4.
db_insert(1,1);
db_insert(1,2);
db_insert(2,3);
db_select(2,&value);
первый запрос успешно выполнятеся.
второй возращает
Код: plaintext
1.
2.
3.
4.
5.
6.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]ERROR: duplicate key value violates unique constraint "bench_pk"
Key (id)=(1) already exists.;
Error while executing the query
ODBC Error/Warning = 23505, Additional Error/Warning = 7
Третий возвращает
Код: plaintext
1.
2.
3.
4.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]Error while executing the query
ODBC Error/Warning = S1000, Additional Error/Warning = 7
Четвертый успешно работает

Я сильно подозреваю что реальный error code от базы это 7...
а это значит что у вас происходит следующее

begin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;

т.е. если внутри транзакции возникла ошибка то никакая комманда дальше в ней не пройдет пока вы ее не откатите.
И это не ошибка ODBC (хотя конечно диагностику она могла бы и более внятную давать).


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728407
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk <>
а это значит что у вас происходит следующее

begin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
<>
вопрос, кто за begin отвечает.

есть подозрение -- что default/fetch (был такой ключ-модификатор в драйвере. как его отключить параметром строки подключения -- не помню).
но в случае error надо бы "end;" руками прослать -- оно и получшает
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728422
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukbegin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728577
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,
Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
             Db Name |select1 | insert | select | update | delete |
  PostgreSql (libpq) |  22990 |  15975 |  16416 |  10610 |  15529 | unix_socket
  PostgreSql (libpq) |  14877 |  11791 |  12405 |   9006 |  11950 | tcp/ip
   PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
        MySql (ODBC) |  24884 |  22349 |  15943 |  18581 |  19848 | unix_socket, Memory
        MySql (ODBC) |  24806 |  14148 |  13864 |  11473 |  12225 | unix_socket, InnoDB 
        MySql (ODBC) |  13934 |  16372 |  12617 |  14208 |  15150 | tcp/ip, Memory
        MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
     TimesTen (ODBC) | 143061 |  82169 | 207125 |  73152 |  62719 | shm
     TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728589
Жоао!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vromanov,
ваша табличка еще и вот что показывает:
Код: plaintext
1.
2.
3.
          Db Name |select1 | insert | select | update | delete |
PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
     MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
  TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip
Сравнивать надо сравнимое, а не shared memory с tcp/ip.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728606
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovvromanov,
Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
             Db Name |select1 | insert | select | update | delete |
  PostgreSql (libpq) |  22990 |  15975 |  16416 |  10610 |  15529 | unix_socket
  PostgreSql (libpq) |  14877 |  11791 |  12405 |   9006 |  11950 | tcp/ip
   PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
        MySql (ODBC) |  24884 |  22349 |  15943 |  18581 |  19848 | unix_socket, Memory
        MySql (ODBC) |  24806 |  14148 |  13864 |  11473 |  12225 | unix_socket, InnoDB 
        MySql (ODBC) |  13934 |  16372 |  12617 |  14208 |  15150 | tcp/ip, Memory
        MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
     TimesTen (ODBC) | 143061 |  82169 | 207125 |  73152 |  62719 | shm
     TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip


основной и наиболее интересный вопрос в том что как мне кажется вы тестируете в 1 поток/коннект.
Результаты я должен признать у вас весьма интересные получились.
Но, как правило для базы вопрос в том сколько вообще запросов в секунду данный сервер может давать (в оптимальное количество потоков). PostgreSQL - 1 коннект - 1 процесс и никакой паралелизации обработки внутри (хотя что внутри SELECT 1 можно парралельно делать не очень понятно), так что производительность работы именно через 1 коннект обычно не очень критична.

Поскольку я кода вашего теста на libpq не вижу то могу предположить что вы могли не использовать prepared запросы и с ними даже в один коннект было бы заметно быстнее (
т.е. вместо PQexec или PQexecParams
использовать однократно PQprepare и далее для кажого вызова использовать в цикле измерения скорости PQexecPrepared
), eсли у вас так и сделано то скорее всего вы весьма близко подошли к пределу одного коннекта... если нет то попробуйте может будет повеселее (особенно за пределами select 1 запроса).

Наверное опять же для работы через Libpq в 1 коннект какую то дополнительную производительность вы сможете получить через http://www.postgresql.org/docs/9.4/static/libpq-async.html но это уже на мой перебор.

PS: интересно сколько ядер процессора timesten задействует через shm ? (всетаки 10 кратная разница это многовато).

PS: вам действительно критична производительность в 1 коннект?
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728644
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vromanovMaxim Bogukbegin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит.пока -- зря
переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728675
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Жоао!shared memory с tcp/ip.
Отлично! Как мне сравнить работу ODBC с PostgreSql через SHM или хотябы через сокет? Я собственно про это и пишу, что нет возможности выбрать правильный и быстрый способ подключения
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728683
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
эттапока -- зря
переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать

Переставил. Селект успешно выполняется и до и после insert, который падает. У нас просто уже это в продакшене и мы знаем, что после подобной ошибки надо разрушать стейтмент. Остальные работают.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728694
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim BogukПоскольку я кода вашего теста на libpq не вижу то могу предположить что вы могли не использовать prepared запросы и с ними даже в один коннект было бы заметно быстнее (
т.е. вместо PQexec или PQexecParams
Я же опубликовал в первом сообщении ссылку на код. На всякий случай вот так делается select 1 (см ниже). Timesten задействует ОДНО ядро. Там вообще вся работа с базой происходит внутри самого драйвера. Т.е. при прогоне теста 100% ядра будет жрать приложение, а сам сервер занимается всякой рутиной типа сброса логов на диск, репликации, итд. Проводя тесты в один поток я замеряю эффективность драйверов. Т.е. какие будут накладные работы при выполнениии любого запроса. Запросы у меня очень простые. Специально проверил сейчас - есть всего один join, который очеь редко вызывается. Но запросов много. И на их вызов тратится существенное время. Частично мы решаем проблему переносом даных SHM, но это не всегда удобно. Кстати, приложение в виде виртуалки лежит тут - http://freepcrf.com.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
void db_prepare() {
....
    res = PQprepare(conn, STMT_ID_SELECT1, Q_SELECT1, 0, NULL);
    CHECK_RESULT(res);
    PQclear(res);
....
}

void db_select1(int32_t* value) {
    if (debug) {
        fprintf(stderr, "db_select1()\n");
    }
    PGresult* res = PQexecPrepared(conn,
            STMT_ID_SELECT1,
            0,
            NULL,
            NULL,
            NULL,
            1);
    CHECK_RESULT(res);
    *value = -1;
    if (PQntuples(res) == 0) {
        fprintf(stderr, "db_select1() return no rows\n");
        if (exit_on_error) {
            exit(EXIT_FAILURE);
        }
    } else {
        *value = ntohl(*(int32_t *) PQgetvalue(res, 0, 0));
        if (debug) {
            fprintf(stderr, "db_select1() return %d\n", *value);
        }
    }
    PQclear(res);
}
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728739
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovЖоао!shared memory с tcp/ip.
Отлично! Как мне сравнить работу ODBC с PostgreSql через SHM или хотябы через сокет? Я собственно про это и пишу, что нет возможности выбрать правильный и быстрый способ подключения

Собственно проблема в том что тот режим использования базы который у вас получается не используется никем кроме вас (локальная In-memory db без конкурентного доступа... это совсем не то под что Postgresql его драйвера оптимизировали).
Все обсуждения о проблемах с производительностью PostgreSQL в моей практике начинались с уточнения "а случайно у вас приложение с базой не на одном сервере живет и если на одном давайте сначала по серверам разным разнесем а потом уже будем смотреть где и что тормозит".

C моей точки зрения штатный режим работы PostgreSQL это:
1)удаленный по TCP/IP
2)в кучу одновременно выполняемых запросов/активных соединений (~2xCPU cores на сервере)
3)всегда идущий активный IO (редко когда база только в памяти помещается)
(и в общем 95% баз с которыми я пересекался именно такие).

У вас же:
1)локальный доступ с приложением на том же сервере
2)1 поток
3)фактически чистый In-memory

Не удивительно что в таком режиме PostgreSQL сильно уступает специализированным in-memory решениям.

Если у вас вопрос в получении максимума TPS на ваших запросах то вам надо уходить от однопоточной модели работы с PostgreSQL.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728769
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются.
Сервера у нас в продакшене от 8 до 24-х ядер.
Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728849
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovMaxim Boguk,

Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются.
Сервера у нас в продакшене от 8 до 24-х ядер.
Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически.

на 24x ядерном сервере вы можете на простых запросах получить используя PostgreSQL где то 300.000-400.000 req/s (по тому что я тестировал)... это уже достаточный результ для многих применений.

PS: результаты TT over TCP/IP выглядят не особо радостно.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728875
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovВыборка по первичному ключу в таблице из двух колонок!

На NoSql похоже, не?
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728939
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovqwwqPS на одбс вы давно батон крошите, но как-то вяло.
может быть вам оно не надо ?
Оно нам надо по очень простой причине. Мы хотив нашем приложении поддержать работу с несколькими базами данных. Сейчас это TimesTen & PQ. ODBC именно для этого и предназначен - для стандартного интерфейса к разным базам данных.
Кстати попробуй чтоли MSSQL по протоколу Shared Memory.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38729074
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan DurakКстати попробуй чтоли MSSQL по протоколу Shared Memory.
Это работает только под виндой
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38729361
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovIvan DurakКстати попробуй чтоли MSSQL по протоколу Shared Memory.
Это работает только под виндой
да ты что
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38729376
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durakда ты что
RTFM

--protocol Value Connection Protocol Permissible Operating Systems
TCP TCP/IP connection to local or remote server All
SOCKET Unix socket file connection to local server Unix only
PIPE Named-pipe connection to local or remote server Windows only
MEMORY Shared-memory connection to local server Windows only
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38738231
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

Вот выложил картинки

...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38738243
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

Вот еще тест реального приложения. Тест эмулирует подключение и отключение от сети 500 000 пользователей со скоростью 1000 в секунду. На картинке загрузка CPU.

...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38741695
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38741806
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovvromanov,

Вот еще тест реального приложения. Тест эмулирует подключение и отключение от сети 500 000 пользователей со скоростью 1000 в секунду. На картинке загрузка CPU.



спасибо за очень интеренсые графики...
Вы уже писали что TT через odbc/shared memory там вообще не по SQL ходит а прямо в память базы.
С этим соревноваться классическому SQL серверу никак.

Очень показательны на этот счет результаты TT over tcp/ip кстати когда TT приходится честно работать как SQL база.

Если не секрет можете ответить про ваши тесты:
1)используемая OS (точнее версия ядра Linux)?
2)используемая версия PostgreSQL ?
3)сколько подключений к базе было одновременно установлено во время теста?
4)что за железо (особенно в плане количества ядер процессоров... что то многовато у вас system load получается на графике... или ядер мало или подключений много...)?

PS: на простых запросах ~200k rps PostgreSQL на нормальной железке дает легко... интересно было бы посмотреть на результаты TT и PostgreSQL на разумном 16-32ядерном сервере если у вас есть доступ.
Этот PS к тому что до 20-24 ядер современный PostgreSQL дает более менее линейный рост производительности от количества ядер (а про TT я ничего на этот счет сказать не могу наверняка).
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38742556
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

Timesten даже при SHM коннекте работает как SQL. Точно теже SQL запросы, тот же код итд. Более того в тот-же момент к нему вополен можно обратиться удаленно и делать SQL запросы. 32 это конечно круто, но становится экономически выгоднее приобрести TimesTen

1) Операционка - Centos 6.5 x86. 2.6.32-431.20.3.el6.x86_64
2) 9.3.4
3) В реальном приложении основных соединений 6. ([Число ядер]-1)*2. В простых тестах - одно.
4) 4 ядра. Это HP блейд
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Xeon(R) CPU           E5450  @ 3.00GHz
stepping	: 6
cpu MHz		: 3000.405
=======================================================
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
top - 06:46:28 up 50 days, 21:39,  1 user,  load average: 0.27, 0.23, 0.18
Tasks: 166 total,   4 running, 162 sleeping,   0 stopped,   0 zombie
Cpu(s): 41.3%us, 10.2%sy,  0.0%ni, 47.6%id,  0.3%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:  12194176k total,  6869348k used,  5324828k free,   198620k buffers
Swap:        0k total,        0k used,        0k free,  5654048k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                         
23348 postgres  20   0 6377m 556m 551m S 19.6  4.7 231:14.37 postgres: appuser pcrf [local]                                                                                                                                                  
23308 postgres  20   0 6377m 556m 550m S 18.9  4.7 230:59.38 postgres: appuser pcrf [local]                                                                                                                                                  
23338 postgres  20   0 6377m 556m 550m S 18.6  4.7 231:06.01 postgres: appuser pcrf [local]                                                                                                                                                  
23346 postgres  20   0 6377m 556m 550m S 18.6  4.7 231:09.18 postgres: appuser pcrf [local]                                                                                                                                                  
23349 postgres  20   0 6377m 556m 550m R 18.6  4.7 231:09.39 postgres: appuser pcrf [local]                                                                                                                                                  
23351 postgres  20   0 6377m 557m 551m R 18.6  4.7 231:10.45 postgres: appuser pcrf [local]                                                                                                                                                  
23245 root      15  -5  908m  13m 6272 S 13.6  0.1 161:41.58 /opt/pcrf_core/bin/pcrf_core worker 1                                                                                                                                           
23244 root      15  -5  908m  13m 6296 S 13.3  0.1 161:50.89 /opt/pcrf_core/bin/pcrf_core worker 0                                                                                                                                           
23247 root      15  -5  908m  13m 6268 S 13.3  0.1 161:41.48 /opt/pcrf_core/bin/pcrf_core worker 2                                                                                                                                           
23248 root      15  -5  908m  13m 6264 S 12.9  0.1 161:45.03 /opt/pcrf_core/bin/pcrf_core worker 3                                                                                                                                           
23250 root      15  -5  908m  13m 6292 S 12.9  0.1 161:31.96 /opt/pcrf_core/bin/pcrf_core worker 4                                                                                                                                           
23251 root      15  -5  908m  13m 6268 S 12.9  0.1 161:39.92 /opt/pcrf_core/bin/pcrf_core worker 5                                                                                                                                           
23374 root      15  -5 1306m 516m 4004 S  7.0  4.3  84:36.92 /opt/drug/bin/drug -d -l notice                         
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38742595
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

И да, кстати, где-то прочитал что ODBC не работает с unix сокетом. Оказалось, что вполне себе работает. С ним немного побыстрее получается.
...
Рейтинг: 0 / 0
36 сообщений из 36, показаны все 2 страниц
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Глюки и низкая произодительность ODBC драйвера
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]