Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
насчет индексов. если в метаданных есть например индекс supplier_nationkey, то на самом деле это я виновник появления этих индексов :-) я начал интересоваться tpc-r в плане его прогона на IB еще в 2000 году, и специально добавил ряд индексов, "для ускорения". Так что если есть желание проводить тест без "лишних" индексов, то вот они: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. кстати. для некоторых запросов в IB фатальным оказался именно lineitem_shipdate, и решением в одном случае являлся именно хинт для исключения этого индекса. но сейчас я не знаю, имеет ли смысл перепроверять тесты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 18:01 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Ну вот, "лошадь тут была непричём, совершенно". Поставил специально DB2 Express на винды. Худшее время - 4.750. А последующие, когда уже всё в кэше-гораздо быстрее: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 19:40 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
До оракла всё равно не дотянул ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 20:26 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Фигня. Зато в 5м тесте - 38с, 10 - 37.9, 11 - 3.36, что заметно лучше оракла. Табличные пространства все дефолтные SMS, объём кэша тоже дефолтный По-моему, неплохо в любом случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 20:44 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
У ora 5-й хапрос 12 сек ;-). Расслабтесь я заного ставлю DB2 EE и буду снова прогонять тест, возможно я когда менял размеры журнала транзакций случайно ткнул какой-то параметр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 23:10 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Локшин Марк Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась. Во-первых, в обсуждаемых тестах "основная" конфигурация была с двумя гигами (см. приложенный к одному из предыдущих олеговых писем excel-файл). Во-вторых, я использовал дефолтные настройки, в том числе буферный пул в 250 страниц, а каждая страница в 4 кило. Ах, вот оно что. По дефолту SMS-пространства (каждая таблица в отдельном файле) кешируются ОС, а я про это забыл, так как обычно ими не пользуюсь. Так что да, для ухудшения результатов надо было это отключить ;-). С другой стороны, Interbase, Oracle, MS SQL используют DMS-пространства (т.е., грубо говоря, много таблиц в файле или на raw device), так что и для DB2 стоило бы создавать именно такую базу (т.е. задать для данных именно DMS-табличное пространство, тогда как прочие два, системное и временное, IBM рекомендует делать SMS). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 23:34 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Локшин Марк Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась. В принципе да, согласен. Но исходные параметры тестов были не мои, а как это Oracle может выигрывать у DB2, не укладывается в моей голове ;-). Несколько позже я буду делать свои (DB2 и пара-тройка версий Oracle), для своего собственного развлечения, возьму scale factor побольше (настолько большой, настолько смогу; у меня теперь на домашней машине теперь на дисках больше терабайта, но ведь может не хватить терпения дожидаться результатов) и постараюсь выжать как можно больше скорости, не ограничиваясь ничем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 23:47 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaПро 18 символов не напоминай, матерился их обрезая что есть мочи. Сount в таблицах выдай сюда. В приципе я могу повторно его прогнать - может и в правду что-то накосячил с параметрами БД. Count завтра, а сейчас скажу, что у меня есть опасение насчёт сбора статистики. Возможно, вы просто выбираете в Control Center схему, выбираете в меню "собрать статистику" и жмёте ОК. Но там важно правильно расставить галочки, или лучше вместо этого запустить мой скрипт (исправив имя схемы). По дефолту там статистика по индексам и distribution не собираются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 23:59 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaи буду снова прогонять тест Ура! Шоу продолжается! Линтер, кстати, забыл добавить в коллекцию. Рекомендую задуматься о продаже билетов, прохладительных (или горячительных) напитков и привлечении букмекеров Victor Metelitsaдля своего собственного развлечения, возьму scale factor побольше (настолько большой, настолько смогу; у меня теперь на домашней машине теперь на дисках больше терабайта, но ведь может не хватить терпения дожидаться результатов) и постараюсь выжать как можно больше скорости, не ограничиваясь ничем. Для чего тест понадобился Олегу, я представляю. Но вот потратить личное время на такое... Хотя, по крайней мере, это развлечение безопасно, в отличие от многих других. Например взять бочонок пива побольше и постараться выжать как можно больше скорости на дорогах общего пользования, не ограничиваясь ничем: ни знаками, ни дорожными условиями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 00:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Для чего тест понадобился Олегу, я представляю. Но вот потратить личное время на такое... Хотя, по крайней мере, это развлечение безопасно, в отличие от многих других. Например взять бочонок пива побольше и постараться выжать как можно больше скорости на дорогах общего пользования, не ограничиваясь ничем: ни знаками, ни дорожными условиями А я вот не понимаю пивопийц на футбольных трибунах (и вообще всех спортивных болельщиков разом), женщин, получающих кайф от шоппинга, и кучу другого народа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 08:43 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Некоторые граждане, пишущие под именем "Victor Metelitsa" вовсе не предполагали, что задача теста получить максимальную производительность. Но некоторые граждане предполагали, что, тем не менее, некоторые другие граждане будут на этот "тест" ссылаться, и хотели, например, получить от некоторых "третьих" граждан скрипт, чтобы понять, что пошло не так, потому что то получилось что-то странное - то, чего не должно было быть, по мнению некоторых граждан. Имеются также некоторые граждане, (часть которых пишет под именем "Victor Metelitsa") которые считают, что тесты полезны, чтобы искать "узкие места" у себя в голове, заниматься самообразованием (этот процесс бесконечный), а соревнования делают этот процесс веселее. Наконец, если некие граждане не ощущают себя вредителями, это ещё не означает, что они таковыми не являются фактически. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 09:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Мой тест имел направленность одну - улучшение функционала FB2. Что и бло сделано, т.к. пару недоработок устранили. Максимальную производительнсоть никто и не искал, поэтому всё и по дифолтам. А теперь самое интересное. Я опять создал базу, влил данные собрал статистику твоим скриптом и опять время выполнения 2-го запроса - минут 7. При этом 100 загрузка проца и никакой нагрузки на диск. Вот так. Что может ещё влиять, на что грешить. Может HT отрубить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 10:39 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Пока никаких идей, разве что и правда HT обвинить. На выходных напишу свой полный скрипт, как это сделано для FB/IB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 10:51 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaПока никаких идей, разве что и правда HT обвинить. На выходных напишу свой полный скрипт, как это сделано для FB/IB. Ну вот, Вам спортивного интересу больше. А я, глядя на скрипты создания индексов и самих запросов и так знаю, где и почему тесты отработались плохо для ASA9 и что нужно сделать, чтобы они летали. Тут даже консультант индексов и граф. план запросов не нужен, поэтому пущай остается в тестах как есть, лениво тестить то, что и так знаешь, как можно ускорить - никакого млин спортивного интереса. IMHO как оказалось, в DB2 есть свои тонкие ньюансы, коих немалое множество, хотя прикола с FIRST я так и не понял честно говоря. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kdvнасчет индексов. если в метаданных есть например индекс supplier_nationkey, то на самом деле это я виновник появления этих индексов :-) я начал интересоваться tpc-r в плане его прогона на IB еще в 2000 году, и специально добавил ряд индексов, "для ускорения". Так что если есть желание проводить тест без "лишних" индексов, то вот они: На самом деле, судя по описанию на tpc.org, нет ограничений на индексы и другие ухищрения. И странно было бы иное. Я надеюсь как-нибудь попробовать это на GemStone/S, которая вовсе даже не SQL-СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:08 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
блин да не прикол это, и не хинты, а документированные SQL Statements. Как говорится, документированный баг == фича :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:10 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Ну, OPTIMIZE это всё-таки хинт, даже если официально он так не называется. Подсказка компилеру и клиентскому обеспечению, как надо выполнять запрос и передавать по сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:24 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
авторПодсказка компилеру и клиентскому обеспечению клиентское обеспечение парсит sql-запросы, передаваемые на сервер? а по поводу оптимизации first, я все-таки не врубаюсь, какие вообще хинты могут быть для "оптимизации выборки первых записей": select first 100 * from table order by last_name order by так или иначе должен отсортировать таблицу? должен. select first 100 должен прекратить выдачу данных клиенту после 100-го fetch? должен. Где тут может быть оптимизация??? И оптимизация чего, собственно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:44 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
кроме fetch first 100 может быть optimize for 10 rows то есть первые 10 будут вернуты мгновенно, для их извлечения будет оптимизирован запрос. Пока пользователь их изучит, там и остальные будут извлечены, а ему может уже и не понадобится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 11:48 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
optimize for n rows - говрит, что результирующий набор (результат работы курсора, или запроса) будет достраиваться динамически. Т.е. не сразу , а по мере прихода FETCH. Если кому-то это не понятно зачем это нужно, или кто-то хочет пощупать "как это работает" могу выслать маленькое тестовое приложение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Нее, товарищи, HT не виноват. Я до кучи сравнивал свой "подстольный" компьютер с Athlon XP с P4 w/HT под Ораклом и DB2 - ухудшения не заметил. Тем более в какие-то жуткие разы. А вообще-тест полезен хотя бы тем, что поневоле придётся подучить матчасть, расширить кругозор ;) Гораздо полезнее пресловутого питья пива на стадионе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:11 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Скажем, у Oracle есть хинты /*+ ALL_ROWS */ The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption). и /*+ FIRST_ROWS */ The FIRST_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). This hint causes the optimizer to make the following choices: If an index scan is available, then the optimizer may choose it over a full table scan. If an index scan is available, then the optimizer may choose a nested loops join over a sort-merge join whenever the associated table is the potential inner table of the nested loops. If an index scan is made available by an ORDER BY clause, then the optimizer may choose it to avoid a sort operation. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:16 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Про что я ещё забыл, так это про ACTIVATE DATABASE, хотя на 2-й запрос это повлиять не должно, коль скоро 100%-я загрузка процессора. DB2, если нет ни одного коннекта, освобождает память базы данных. Если вы сделали коннект к базе, прогнали тесты в первый раз, сделали дисконнект, затем коннект и прогнали тесты во второй раз, результаты могут оказаться, как в первом, если коннект был единственный. Чтобы содержимое буферных пулов не пропало, надо либо постоянно держать ещё один коннект, либо выполнить ACTIVATE DATABASE <имя>. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:22 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:29 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33576439&tid=1553502]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 172ms |
| total: | 278ms |

| 0 / 0 |
