Сравнение RDBMS в OLTP readonly тестах

в блокирующем режиме

>Statpack для какого именно теста? там несколько десятков результатов,

1. в описании говорится о 3х селектах, что тестируют десятки ?
2. выложи там где фигурирует селекты.

anonymous1

> выбор по одному индексу из таблицы Selectom через pgsql сишную библиотеку и соотвественно обратно туда складывание update.
на каждый запрос свой PQconnectdb ? PQexec или PQexecPrepared ?

> Похоже что какой бы ни был benchmark, сторонники БД с не найлучшими результатами всегда будут говорить про кривой тест, параметры и т.д.

Я хочу заметить, что БД -- штука сложная, и наилучшая производительность достигается точным подбором настроек. И это именно то, чего автор не делал. Ну и о каких "тестах" может идти речь?

>Ну и о каких "тестах" может идти речь?
о ламерских, от аффтора даже не просят настроить, просят просто выдать репорт, но даже это ему не подсилу.

>>Ну и о каких "тестах" может идти речь?
>о ламерских, от аффтора даже не просят настроить, просят просто >выдать репорт, но даже это ему не подсилу.

Ну нечего так нервничать, всему свое время.
Лучше бы посоветовали какие параметры настроить.
Те кто в этом хоть что-то понимает - так и сделали.
Сейчас прогоняется новый цикл.

Но как я понимаю, от "супер спецов-отцов" опять будут вопли, параметры не те, тест не годится.

2Bizon

какие советы ты ожидаешь получить если о системе извесно только то что "тест" прогнал не спец по ораклу ? индексы создать и т.п. ?
покажи statpack - будут советы.

>какие советы ты ожидаешь получить если о системе извесно только то >что "тест" прогнал не спец по ораклу ? индексы создать и т.п. ?
>покажи statpack - будут советы.

Ну по-моему если известна таблица, известны индексы, известны запросы, известны параметры запуска, то человек занимавшийся настройкой Oracle хобя год-два, сможет сказать что надо поменять...
Ну если без statpack никак - будет statpack.

ok, для тех кому надо statpack:

http://mysql.apachephp.com/files/sp_3_4.lst

> http://mysql.apachephp.com/files/sp_3_4.lst



Я бы начал с борьбы с приложением.
SELECT c from sbtest where id=:1 исполнялся 4,739,374 раз!
Я понимаю, что иногда хочется писать "по деревенски",
типа "как думаю, так и пишу", даже сам грешен бываю. Но если важна
скорость, то приходится разбираться с данными, строить временные
таблицы для соединения, использовать внешние таблицы, читать что
такое bulk collect, и прочее интересное чтиво. Главное правило:
"обработать как можно больше данных за как можно меньше sql-операторов".

2ed

PQconnectdb один открывая сессию. дальше PQexec вытаскивает Selectom по одной строке из базы.

cpu_tuple_cost=0.01 cpu_index_tuple_cost=0.001

закоментарены то-есть по дефолту...

Вы верно шутите
лениво разбирать все, но то что бросилось в глаза сразу.

db_block_size 8192

почему не 16к? Мы же об OLTP говорим??


sga_max_size 1073741824
это вообще не смешно.. зачем вам 4гига оперативки??

и я так понял, что ни о каком RAW device речи тоже не идет , небось еще все это на ext3 ?

2 ifconfig:
Это такой прикол?
Вы решили выложить все что знаете?

Зачем тут RAW device? ВСЯ таблица помещается в cache! Дисковая активность отсутсвует!

Хмм.
В OLTP меня больше интересовали бы равные доли чтения/модификации/добавления.
"Только чтение" не интересует абсолютно.
Это в качестве скоростемера фронтофиса.

А по бэкофису интересовали бы аналитические выборки с пересечением до 15 таблиц, с разными типами сабселектов, с интенсивным использованием MIN, MAX, AVG и COUNT по результатам группировки из дюжины-другой таблиц.
Где-то 100 выборок на запись.

> Вы верно шутите? лениво разбирать все, но то что бросилось в глаза сразу. db_block_size 8192

Это как раз неплохо для OLTP, вот для DW 16k лучше, но есть же statspack spreport, там видно, что это не играло роли вообще.

> почему не 16к? Мы же об OLTP говорим??

Сам тоже ставлю 16k, было б можно, и 32k поставил :) > sga_max_size 1073741824 это вообще не смешно.. зачем вам 4гига оперативки??

Опять, по барабану для базы в 300Мб. Реально всё равно всё в памяти. По statspack отчёту хорошо видно, что тестировалось выполнение запроса select c from table where id = :1, при условии, что вся база в памяти. Очень важный тест, нельзя отнять.

> и я так понял, что ни о каком RAW device речи тоже не идет , небось еще все это на ext3 ?

не считая того, что это в данном случае по барабану :) RAW devices в линуксе под ораклом... Вы пробовали? Я пробовал, и поставил под оракл в итоге ... XFS! Хочется, конечно, спрыгнуть на OCFS2, но жду пока скажут, что для RHEL4 есть стабильная версия.

> PQconnectdb один открывая сессию. дальше PQexec вытаскивает Selectom по одной строке из базы.
Очень рекомендую использовать PQprepare/PQexecPrepared вместо PQexec.

Какая лучшая файлуха под oracl под Linux на 2.6 ? Где об этом чего-нить написанно, желательно с тестами :).

>В OLTP меня больше интересовали бы равные доли >чтения/модификации/добавления.
>"Только чтение" не интересует абсолютно.
>Это в качестве скоростемера фронтофиса.

Ok, это в планах - стандартная просьба, с параметрами для Postgкes / Oracle поможешь?
ReadWrite намного критичнее по параметрам для I/O.
один параметр изменил и результат в два раза ниже.

>А по бэкофису интересовали бы аналитические выборки с пересечением >до 15 таблиц, с разными типами сабселектов, с интенсивным >использованием MIN, MAX, AVG и COUNT по результатам группировки из >дюжины-другой таблиц.
>Где-то 100 выборок на запись.

Тоже неплохо, давай с тебя testcase - с меня тесты :)

>>Вы решили выложить все что знаете

лад, у меня нет настроя вступать в какого либо дисскусию по данному поводу. Вы уверены в свое "правоте", дисскусия лиш это укрепит.

>>RAW devices в линуксе под ораклом... Вы пробовали?

Я никогда не пишу того, что не пробовал/использую. Кстати, на эту тему года-полтора назад была дисскусия в которой многое подробно я рассписывал.

> Я никогда не пишу того, что не пробовал/использую. Кстати, на эту тему года-полтора назад была дисскусия в которой многое подробно я рассписывал.

Расскажите, пожалуйста. Или дайте ссылку. Поскольку у меня в Linux ни разу Oracle на RAW не был быстрее, чем на FS. Когда недавно я снова стал разбирать вопрос, нашёл исследование в сети, и там автор тоже удивлялся чего это у него RAW не всех заборол, а наоборот, показал довольно средний результат.

> Какая лучшая файлуха под oracl под Linux на 2.6 ? Где об этом чего-нить написанно, желательно с тестами :).

Смотря какие "тесты" :) К сожалению, последние тесты от самой Oracle относятся к 2.4 ядру, и там у них наилучшую масштабируемость показали OCFS и RAW. У меня проблема в том, что нужны очень большие файлы, а Oracle, при размере блока 16к, согласен их делать только по 64Г, так что мне довольно неудобно нарезать их в страйпе, жду официального OCFS2 для RHEL 4. А пока использую XFS из соображений (и ненаучных тестов), что она с большими файлами лучше всех себя показывала.

>cpu_tuple_cost=0.01 cpu_index_tuple_cost=0.001 > закоментарены то-есть по дефолту

вот я и писал тебе - почитай, подтюнь.

performance-tips.html

runtime-config.html

в доках.

>вот я и писал тебе - почитай, подтюнь.

>performance-tips.html

>runtime-config.html

>в доках.

почитал. cpu_tuples влияет только на оценку планера. То-есть искать по индексам или просто так. Для моей таблицы из 600 рядов по 31 поле, где поиск всегда ведется тольпо по первому полю, особой разницы вродебы нет.

или я не прав?

Поменял некоторые параметры для Oracle.

Тем кому интересно, новые результаты можно посмотреть тут
http://mysql.apachephp.com/?page_id=14

> RAW devices в линуксе под ораклом... Вы пробовали?

Пробовал. Понравилось :-) Очень пользительно, когда много клиентов и постоянно перелопачиваются большие объемы данных.

> Пробовал. Понравилось :-) Очень пользительно, когда много клиентов и постоянно перелопачиваются большие объемы данных.

У меня "клиентов" мало -- бэкенд, но объёмы здоровые... Жду OCFS2...