|
|
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Сделал тестовую утилиту и выложил ее сюда - 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 12:41:56 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanov, 10К/sec - не так уж и плохо. покажите планы tz_convert - а это база может и не делать, если уж "скорость" нам так нужна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 15:29:21 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, Какие такие планы? Выборка по первичному ключу в таблице из двух колонок! Вот сравнение этого теста с разными базами. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 15:35:26 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanov, Чего вы хотите получить в результате таких (“выборка по первичному ключу в таблице из двух колонок”) тестов? Показать, что для очень простых (примитивных даже) запросов PostgreSQL медленнее MySQL и ORACLE TimesTen? Это вполне ожидаемо. Сравнивать с TimesTen совсем не корректно, т.к. это база в памяти, нету там IO. Вы не могли бы выделить SQL скрипты для (1) инициализации и (2) прогонки теста — я бы тоже погонял у себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 15:56:12 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vyegorov, Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять. Запросы вот Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 16:06:25 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanov Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново как портится ? какая именно ошибка? PS на одбс вы давно батон крошите, но как-то вяло. может быть вам оно не надо ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 16:25:10 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
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 для сишных клиентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 16:50:11 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovvyegorov, Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять. так известный факт и лечить его никто не будет ибо он никому кроме вас не нужен под highload где это становится актуально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 16:51:16 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
qwwq, Сценарий такой Код: plaintext 1. 2. 3. 4. второй возращает Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 16:58:41 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
qwwqPS на одбс вы давно батон крошите, но как-то вяло. может быть вам оно не надо ? Оно нам надо по очень простой причине. Мы хотив нашем приложении поддержать работу с несколькими базами данных. Сейчас это TimesTen & PQ. ODBC именно для этого и предназначен - для стандартного интерфейса к разным базам данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 17:01:17 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukтак уже обсуждалось что ODBC драйвер у PostgreSQL старый и небыстрый... и опять же уже советовалось использовать напрямую libpq и сравнивать по скорости (не забывая использовать prepared запросы). Приделаю еще к тесту libpq. Посмотрим что получится. В крайнем случае похоже придется писать свою реализацию подмножества ODBC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 17:33:03 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovODBC Error/Warning = S1000, Additional Error/Warning = 7 про S1000 вы писали уйму времени тому . так и не выяснили ? в http://www.postgresql.org/docs/current/static/errcodes-appendix.html этого кода нет. (в отличии от 23505 ) наверняка за это время вы таки выяснили, что это, и чем борется (я догадываюсь, но голословно предполагать не хочу). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 17:59:15 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovqwwq, Сценарий такой Код: plaintext 1. 2. 3. 4. второй возращает Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. Я сильно подозреваю что реальный error code от базы это 7... а это значит что у вас происходит следующее begin; insert...; --ошибка и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете rollback; т.е. если внутри транзакции возникла ошибка то никакая комманда дальше в ней не пройдет пока вы ее не откатите. И это не ошибка ODBC (хотя конечно диагностику она могла бы и более внятную давать). --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 18:19:54 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk <> а это значит что у вас происходит следующее begin; insert...; --ошибка и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете rollback; <> вопрос, кто за begin отвечает. есть подозрение -- что default/fetch (был такой ключ-модификатор в драйвере. как его отключить параметром строки подключения -- не помню). но в случае error надо бы "end;" руками прослать -- оно и получшает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 18:26:35 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukbegin; insert...; --ошибка и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете rollback; Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2014, 18:36:39 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanov, Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 01:01:08 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanov, ваша табличка еще и вот что показывает: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 01:40:53 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovvromanov, Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. основной и наиболее интересный вопрос в том что как мне кажется вы тестируете в 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 коннект? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 05:00:16 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovMaxim Bogukbegin; insert...; --ошибка и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете rollback; Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит.пока -- зря переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 08:00:45 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Жоао!shared memory с tcp/ip. Отлично! Как мне сравнить работу ODBC с PostgreSql через SHM или хотябы через сокет? Я собственно про это и пишу, что нет возможности выбрать правильный и быстрый способ подключения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 08:57:52 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
эттапока -- зря переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать Переставил. Селект успешно выполняется и до и после insert, который падает. У нас просто уже это в продакшене и мы знаем, что после подобной ошибки надо разрушать стейтмент. Остальные работают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 09:05:17 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 09:18:39 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 10:27:17 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются. Сервера у нас в продакшене от 8 до 24-х ядер. Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 10:49:40 |
|
||
|
Глюки и низкая произодительность ODBC драйвера
|
|||
|---|---|---|---|
|
#18+
vromanovMaxim Boguk, Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются. Сервера у нас в продакшене от 8 до 24-х ядер. Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически. на 24x ядерном сервере вы можете на простых запросах получить используя PostgreSQL где то 300.000-400.000 req/s (по тому что я тестировал)... это уже достаточный результ для многих применений. PS: результаты TT over TCP/IP выглядят не особо радостно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2014, 11:48:41 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38728269&tid=1998500]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
205ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 603ms |

| 0 / 0 |
