Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
На news://news.gmane.org/gmane.comp.db.firebird.russian я увидел любопытную тему "Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)". Попытка написать туда не удалась - я получил письмо от Gmane Autoauthorizer, ответил на него, но на этом всё заглохло. На работе у меня интернет ограничен, и более подробные исследования я не могу сейчас произвести. Люди там насобирали кучу результатов с кучи баз, и это в некоторой степени любопытно. Но ценность этих цифр, мягко говоря, сомнительна. В частности, я не понимаю, почему у DB2 получился такой слабый результат, но не могу посмотреть ни скриптов, ни свойств/настроек базы. Вообще, у "тяжелых" СУБД есть много рукояток, за которые можно повертеть, а что навертели тестировщики, неизвестно. Итак, ценность тех цифр (для постороннего читателя) только в подтверждении факта, что люди сумели установить некие СУБД и что-то на них запустить. С другой стороны, сами по себе тесты интересны, если запускать их у себя. Интересны в плане тренировок "кручения ручек". На сайте TPC-R я нашёл некие "исходники" на C, но, как я понял, они негодны для непосредственного использования. Надо писать свой код для коннекта к базе. На ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось). Нет ли чего-то готового для других СУБД в других местах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 09:38 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Что-то я там увидел тока новый начинающий какой-то форум по БД. Значительно уступающий данному. Таких "тестов" наверняка полно и здесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 09:50 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Хуже этого форума я ещё не видел. Но меня интересует ответ на конкретный вопрос, и не буду пренебрегать даже мизерным шансом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 09:56 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite// Это open-source тестилка на SAP DB, правда. http://www.quest.com/benchmark_factory/index.asp Очень хорошая тестилка, одна проблема - глючная очень. :( И дорогая, кстати, безумно. А тот тест, что Вы упомянули - я пробовал, но создать хоть сколько-нибудь серьезную нагрузку на железо им не удалось :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 10:02 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
a_shats А тот тест, что Вы упомянули - я пробовал Как именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 10:32 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa пишет: > Вообще, у > "тяжелых" СУБД есть много рукояток, за которые можно повертеть, Есть. Только стимость кручения этих ручек может вылиться в цифры зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки зрения бизнеса уже не так здорово. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 12:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Есть. Только стимость кручения этих ручек может вылиться в цифры зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки зрения бизнеса уже не так здорово. Ну зачем Вы так говорите? 1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - вопрос времени. 2) Если по бизнесу хорошо, чтобы медленно работало, то нихай себе медленно что-то работает. Чего тогда вообще что-то тестить? 3) Если система не позволяет и с самыми продвинутыми DBA добиться нужного, то с точки зрения реального бизнеса (для которого позиция DBA в штатном расписнии не критично мягко говоря) это, возможно, тоже плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 12:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
vadiminfo пишет: > 1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - > вопрос времени. Разница между "хоть какого-то DBA" и выделенного DBA может составлять от 2-3 тыс $ в месяц на инсталляцию. > 2) Если по бизнесу хорошо, чтобы медленно работало, то нихай себе > медленно что-то работает. Чего тогда вообще что-то тестить? а кто сказал, что медленно? Если уж ведем речь про бизнес, то тестить нужно не абстрактные запросы, а решения. > то с точки зрения > реального бизнеса (для которого позиция DBA в > штатном расписнии не критично мягко говоря) Т.е. все что не нефть, газ и т.п. - не реальный бизнес? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 13:03 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Разница между "хоть какого-то DBA" и выделенного DBA может составлять от 2-3 тыс $ в месяц на инсталляцию Многие вопросы решит и хоть какой-то DBA. Я не знаю тада о каких системах Вы говорите, где нужен выделенный DBA на инстоляцию. Наверное, на таких по важности и ценности инфы и 2-3 тыс $ - дешево. Александр Гoлдун а кто сказал, что медленно? Если уж ведем речь про бизнес, то тестить нужно не абстрактные запросы, а решения. Ну это может быть взаимосвязано. Все таки РМД расчитана и на произвольные запросы. Да и данные меняются по объему и содержанию со временем. Но я не говорил ниче против тестирования решений. Просты Вы сказали о стоимости кручения. И так понял, что якобы без DBA можно, ну помедленнее чем с DBA. Александр Гoлдун Т.е. все что не нефть, газ и т.п. - не реальный бизнес? В нефти и газе - 2-3 тыс $ в месяц DBA смертельно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 14:10 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 14:28 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Victor Metelitsa пишет: > Вообще, у > "тяжелых" СУБД есть много рукояток, за которые можно повертеть, Есть. Только стимость кручения этих ручек может вылиться в цифры зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки зрения бизнеса уже не так здорово. А чего нам, спецам, плакать о бизнесе? Это "их" задача - заплатить поменьше, а наша задача - получить побольше. Поэтому, например, спецы по Oracle молодцы, а по Firebird/Interbase - вредители, рубящие сук, на котором сидят они сами и их коллеги. К счастью, у них пока не очень получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 14:38 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
hvlad Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2 Разумеется. Хотя из текстовых файлов проще. Но вот если мне захочется повертеть в руках что-то незнакомое, типа MS SQL/Sybase/Informix/etc, лучше было бы иметь более удобное решение. Также и кому-то с DB2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 14:43 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa hvlad Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2 Разумеется. Хотя из текстовых файлов проще. Но вот если мне захочется повертеть в руках что-то незнакомое, типа MS SQL/Sybase/Informix/etc, лучше было бы иметь более удобное решение. Также и кому-то с DB2. Не надо БД генерить. Качаете тест на FB2, ставите клиента FB2, запускаете генерилку DBGEN, она выплюнет TLB файлы, которые на самом деле просто CSV файлы с разделителем "|". Скрипты создания таблиц, индексов и сами запросы в тесте в виде скриптов присутствуют. IMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем, ни один сервер не будет в настройках по умолчанию держать нормальные настройки, так как, не зная даже задачи, он будет в ущерб скорости повышать надежность и дубовость работы. Так что настройки и без DBA могут самой инсталяцией уже ставиться конечного продукта, дальше уже от конкретного сервера зависит, насколько легко ему будет еще самому к железу привязаться и что он позволяет при инсталяции и настройке определить программным способом. P.S. Хотя в принципе нам асашникам грех на тесты жаловаться, не смотря на дефотный запуск прямо на демо БД, сервак отработал вполне шустро, что и следовало ожидать. Много траблов было с обновлением в одной транзакции 6,5 миллионной таблицы, вот здесь как раз настройки по умолчанию совершенно не прокатывали и у автора теста обновление заняло пару суток, а у меня на менее мощной машине один час. Поэтому совершенно не удивляюсь, что DB2 показала не сильно большие результаты - в этот сервере есть где и за что покрутить и это при таких нагрузках неплохо бы делать - я там вообще на демо базе при ее первом юзанье не смог больше 40 000 записей вставить, получив переполнение циклического лога ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 17:15 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaКак именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader? Насчет TPC-R не знаю, но dbgen для TPC-H я с сайта www.tpc.org утянул и с помощью него базу сгенерировал. Правда для MS SQL. Там в ней define'ы насколько я помню есть чего под какую базу генерить. Правда почему-то тот архив, который я скачал у меня под VC не собрался, пришлось пару строчек в коде править. И генератор запросов там же есть, насколько я помню. Если, конечно, Вы имеете ввиду тоже, что и я. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 18:39 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Господа DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ. Запросы выполнялисьь не один раз а несколько раз с целью изучения эффективности использования памяти. Специалист по ASA пусть объяснит почему другие специалисты из Sybase установили интервал допустимого восстановления базы после сбоя по умолчанию что update указанные мной в комментариях выполнялся так долго. (Для справки я изменил этот параметр и уложился в час) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 01:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
ASCRUSIMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 01:11 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-) Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть. Пожалуста, скажите здесь кем ставился тест. Все его награды, грамоты опишите. А если не трудно и про результат скажите теста скажите. Как он соотносится с TPC, где, насколько я слышал настраивают представители фирм производителей. А то что один Оракл обгоняет другого я наблюдал, хотя парни не первый день с Ораклом работали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 01:35 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaГоспода DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. Ну, смотря на сколько простых. Если настройки могут повлиять на план, выдаваемый оптимайзером, то иногда можно и в разы. За примерами ходить далеко не надо, гляда на ваши же с Димой обсуждения запросов, кажется 14-16. ASA возможно тоже мог бы улучшить свой результат, если поиграться опциями OPTIMIZATION_GOAL и OPTIMIZATION_LEVEL и выставить OPTIMIZATION_WORKLOAD в OLAP вместо дефолтного Mixed. Плюс если все-таки перед тестом на базе были сделаны массовые изменения, я бы на всякий случай пересоздал гистограммы. Это то, что пришло в голову уже после того - меня смутили запросы 7 и 12, в к-рых повторные выполнения оказались заметно дольше первого. Интересно было бы планы сравнить. Ну да ладно, не ASA меряли и не за золотой кубок боролись, тем более что я то потребитель, а не разработчик сервера, и даже не держатель акций ianywhere solutions :) olegloa Специалист по ASA пусть объяснит почему другие специалисты из Sybase установили интервал допустимого восстановления базы после сбоя по умолчанию что update указанные мной в комментариях выполнялся так долго. (Для справки я изменил этот параметр и уложился в час) Очевидно, уменьшение возможных потерь при сбое. Ну согласись, что запрос не из тех, что нужны повседневно за исключением каких-либо специфических задач. И к TPC-R он не имеет отношения. А если уж и припрет раз в год, то можно и индексы дропнуть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 02:00 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
vadiminfo Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть. Кусаются? vadiminfo Все его награды, грамоты опишите Не стоит беспокойства, Oracle в сумме выиграл у всех, даже у ASA, проиграв ему всего лишь в 6 запросах из 22 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 02:17 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa ASCRUSIMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-) Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я бы вообще столько индексов в структуре не стал создавать для ASA. P.S. Ну а почему дефолтные настройки в ASA выставлены на 2 минуты восстановления базы после запуска при обнаружении случая аварийного завершения - так это правильно. Кто знает - тот и поставит столько, сколько нужно. Кто не знает - значит сервер сам должен обеспечить максимальную скорость поднятия базы с откатом транзакций. Тем более что это не влияет на вставки, удаления и короткие апдейты, только на длинные апдейты, где апдейтом захватываются миллионы записей и это порождает много грязных страниц и переноса оригинальных страниц в Checkpoint log. Вот для таких случаев как раз параметрами и можно перевести БД в режим снижения частоты записи грязных страниц, увеличив скорость апдейта и соотвествующе увеличив время восстановления состояния БД, если бы на момент длинного апдейта сервер уронили. Кстати в ASA много чего установлено по умолчанию на скоростную загрузку БД при старте сервера - к примеру кэш часто используемых данных и наилучших планов запросов так же в БД по мере минимальной загрузки сервера пишется - то есть при перезапуске сервера он поднимет последние лучшие планы запросов и страницы данных в кэш, таким образом сразу же начав эффективно работать без повторного набора в кэш данных и с нуля вычислений всех планов запросов - этакий аналог режима hypernate. Тоже можно отключить, если скорость максимальной отдачи сразу с запуска БД не важна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 07:05 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaГоспода DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ. Да у DB2 и статистику можно собирать по-разному. Табличные пространства могут быть SMS и DMS, с разными размерами префетча, с разрешением кеширования средствами ОС или запрещением. Распределение памяти между буферным пулом и памятью для сортировки (которая используется также для хешджойнов). Специфичные настройки оптимизатора через db2set. Я собираюсь написать скрипт на REXX'е для перебора (естественно, не всех параметров, а по одному). Хотелось бы видеть, что именно вы запускали. Ну и, конечно, если вас не интересуют "специфичные веще типа кластерных индексов, секционирования и т.п.", то меня очень даже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 08:23 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест >заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в >стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я >бы вообще столько индексов в структуре не стал создавать для ASA. Никаких SP и прочей шелухи. Все запросы переписаны на view, и были приведены в первом сообщении с результатами. Так что никаких заточек под IB. Индексов не куча, а ровно столько, сколько было бы создано большинстовм при таких запросах. Могу оставить одни PK :-) и повторить тест для ASA, тока боюсь он его вообще не закончит никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 08:30 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Да у DB2 и статистику можно собирать по-разному. Табличные пространства >могут быть SMS и DMS, с разными размерами префетча, с разрешением >кеширования средствами ОС или запрещением. Распределение памяти между >буферным пулом и памятью для сортировки (которая используется также для >хешджойнов). Специфичные настройки оптимизатора через db2set. Никто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 08:32 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaНикто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже Приведите ваши скрипты, пожалуйста. Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках. Запросы 2, 3, 10, 21 содержат ограничение количества строк - а вы в курсе, что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма желательно писать OPTIMIZE FOR n ROWS? Кроме того, зачем вообще существуют настройки, если не настраивать? Кроме того, наш с вами интерес к этим тестам имеет разную природу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 08:50 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Чёйта я не понял, чё такое этот TPCR. TPC-H знаю, dbgen к нему есть. 22 запроса. Это оно и есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 09:09 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках. Имею в виду результат замены SMS на DMS и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 09:16 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Наверное, я всё же нифига не понимаю сути этого теста... Там писали ( http://article.gmane.org/gmane.comp.db.firebird.russian/2156/match=dbgen) "Тот самый update lineitem set l_comment = trim(l_comment) - 251 секунда." Я использовал вместо trim rtrim (ну нету в DB2 просто trim) - time db2 "update lineitem set l_comment = rtrim(l_comment)" DB20000I The SQL command completed successfully. real 0m45.509s При том, что машинка у меня заметно слабее - Athlon XP 1800+, памяти 384МБ, и база и её логи находятся на одном древнем IBMовском IDE диске. Что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 10:53 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Наверное, я всё же нифига не понимаю сути этого теста... Потому что читать нужно всё ветку было. Это запрос вообще никакого отношения к тестам не имеет, а возник из-за трудностей с этим запросом на ASA в силу определённых настроек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:30 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS? В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста. Точно также как и ручное планирование в IB7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:33 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
А. Ну извиняйте, как говорится-не осилил потому что много букв. И ещё раз извините. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:33 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Архив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:36 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Ребята, вы только не забывайте про то, что тесты эти Олег проводил на своём энтузиазме прежде всего для себя и для узкой группы людей, которые тусуются в известной конференции. Изначально хотели сравнить IB/FB/Ya разных версий между собой, а потом ради интереса захотелось померяться письками с ораклом и т.д. Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать. А вобще-то на тестах никто не обделался особо кроме IB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:40 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS? В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста. Это не одно и то же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:45 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Это время выполнения запроса? Тогда с запросом 2 как-то плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:46 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaАрхив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно. DB2 оказалась хуже Oracle. Чем не проблема? ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:51 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Это не одно и то же Что не одно и тоже? C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей. Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений. Если бы мне требовалось быстрее отобрать n записей из x, где n существенно меньше чем x то одновременное указание обоих конструкций для одного запроса имело бы смылс. У меня отбирались все x записей, т.е. n = x. Следовательно OPTIMIZE FOR n ROWS мне нафиг не нужно. Если логика DB2 иная, то сами буратины :-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:56 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Это время выполнения запроса? Угу >Тогда с запросом 2 как-то плохо. У кого? :-), там их много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 12:58 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
У DB2. План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:07 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa> C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей. Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений. Логично ожидать именно такого поведения. Беда в том, что реализовано это не так. Об этом говорили сами ibm-еры в их ньюсгруппе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:10 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Тогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо. Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kmikeУ DB2. План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе. Порядок тот же, что и требовалось доказать. Так что притензии не ко мне а к IBM :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:39 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Gold Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать. А вобще-то на тестах никто не обделался особо кроме IB. Собственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать. Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 13:44 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaТогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо. Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте. Видите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:08 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaСобственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать. Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации. Как я понимаю, опубликовать скрипты и настройки базы вы отказываетесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:13 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Здесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные. Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:26 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaВидите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал. Т.е. мне как разработчику нуджно говорить DB2: дай мне только 100 записей, не ты меня поняла, только 100 запсей... что непонятно, щас пну если не дашь только 100 записей ;-) Уже не смешно. Нахрена тогда байки про навороченность оптимизатора DB2 сочинять, если он не в состоянии сам сооброзить что если сказали отбирать только 100 записей, так и оптимизировать запрос нужно под 100 записей. Ты сам то вдумайся в то что пишешь. И зачем тогда приводить ссылку на обсуждение этой пробемы с разработчиками DB2, когджа это только подтвержадает её существование, т.к. в противном случае на это обратил внимание только я, а выходит и другие товарищи уже обращали внимание на эту проблему. Подсказка оптимизатору нужна тогда, когда явные критерии отбора данных указанные в запросе не позволяют однозначно выбрать оптимальный план. Какая неоднозначность может быть в конструкции "Отобрать только первые 100 записей и ВСЁ." Это уже не подсказка, а ручное планирование запроса, что условиями теста не допускалосось.... занавес. P.S. Начёнм лепить хинты к DB2, я прилеплю хинты к ORA/MS/IB-клонам и что тогда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:35 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Рассмотрим запрос: Код: plaintext 1. И такой: Код: plaintext 1. И такой: Код: plaintext 1. И вот такой: Код: plaintext 1. во всех приведенных случаях планы доступа будут разными с зависимости от наличия нужных индексов и правильности сбора статистики. Вариантов - просто миллион... мне чета даже лень писать все... нет определенно лень... (( optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях). fetch first - определяет размер этого самого результирующего набора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:46 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные. Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю. По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 14:55 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки). Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:08 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenman[quot olegloa]По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю. Для тех кто не в теме. От меня был комментарий, что те кто мог получали 80% от ОЗУ под свои нужды, в том числе и от DB2 и размер кэшей пулов и пр у всех серверов настраивался. Если не в курсе подробностей, то пишите в оригинальную конфу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:27 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки). Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:30 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenmanРассмотрим запрос: Код: plaintext 1. И такой: Код: plaintext 1. И такой: Код: plaintext 1. И вот такой: Код: plaintext 1. во всех приведенных случаях планы доступа будут разными с зависимости от наличия нужных индексов и правильности сбора статистики. Вариантов - просто миллион... мне чета даже лень писать все... нет определенно лень... (( optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях). fetch first - определяет размер этого самого результирующего набора. И при чём тут наш тест? У нас все записи уходят на клиента. Спосили 100 все 100 и забираем. К чему все эти рассуждения о разных планах при разных индексах? Есто возразить к тем логическим рассуждениям которые я привёл? Если я прошу отдать мне 100 записей и я их все 100 забираю, то какого я должен ещё делать какие-то телодвижения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:33 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenman olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные. Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю. По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю. Я вначале подозревал именно это, но потом решил, что Олег, должно быть, делал базу из CC, а CC после создания предлагает вызвать Configuration Assistant, который буферный пул всё-таки таким маленьким не оставит. Но он секрета так и не выдал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:34 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Ну, будем считать, что Configuration Adviser использовался. Хотя он вряд ли дал оптимальные настройки. Я тут на другое наткнулся, и ошизел (описание в следущем письме). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa пишет: > Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов О, у меня тоже была идея для ASA проверить что насоветует Index Consultant, но почему-то думал, что набор индексов жестко регламентирован в TCP-R Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:39 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
80% отдавал. Если мне укажут отптимальные параметры для DB2 при условии невыхода за рамки теста(т.е. никаких подсказок и доп индексов), то я протестирую заного. Так же я готов оттестить DB2 vs ORA если будут конкретные рекомендации по доп. оптимизации указанного теста для DB2, разумеется с доп оптимизацией ORA c моей стороны. Надеюсь, что после этого все стороны будут довольны ;-);-);-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:41 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Consultant, но почему-то думал, что набор индексов жестко регламентирован в TCP-R Именно так. Все сервера работали на одинаковых метаданных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:43 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Да 80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:46 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Итак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, на ней DB2 ESE FP10 (не думаю, что с Express'ом должна быть какая-то разница). Создал базу с самыми что ни на есть плохими настройками. Табличные пространства SMS. Кстати, если кому интересно, размер оказался менее 1,7 гига. Configuration Adviser я не запускал, буферный пул остался в 250 страниц. Посоветованные мне индексы не создавал. Выполнил второй запрос, который в Excel приводится как потребовавший 412,59 секунд в первый раз и 412,59 в третий. У меня это заняло 10 секунд при первом прогоне и менее секунды во втором. Привожу кусок лога (второго прогона). Прошу проверить, потому что не верю собственным глазам и думаю, что где-то глюканул: начало Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:51 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Victor Metelitsa пишет: > Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов О, у меня тоже была идея для ASA проверить что насоветует Index Consultant, но почему-то думал, что набор индексов жестко регламентирован в TCP-R Поэтому я создавать не стал. Но резервами поинтересовался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:53 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки). Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса. Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:56 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
А DFT_QUERYOPT считается настройкой? Собрал статистику, переткнул DFT_QUERYOPT в 7. real 0m1.663s real 0m0.333s real 0m0.320s "Что это было?" :[ ] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:57 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaПотом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации. В том то и дело, что Вы заявили, "это явный косяк ASA с индексами при апдейте большого кол-ва записей". Пришлось качать тест и доказывать, что это неявный и тем более не косяк, так бы и заморачиваться не пришлось. Одно доброе дело - решился таки написать статью по чекпойнтам под ASA, не первый раз тема всплывает даже у наших, а момент как оказалось достаточно важный не только с точки зрения надежности хранения данных, но и скорости, так что Вам Олег большое спасибо за толчок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:57 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Так посимпатишнее: Victor Metelitsa начало Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 15:58 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
>Привожу кусок лога (второго прогона). Прошу проверить, потому что не верю >собственным глазам и думаю, что где-то глюканул: Я думаю что глюканул именно Express. Так как этот запрос действительно выбивается из всех остальных. Что там за проблемы я не разбирался, т.к. такой задачи не ставил. Как я уже и сказал - будут оптимальные настройки для Express - будет повторный прогон теста. P.S. Может ты с данными прошибся - не тот объём влил. Потом есть одно но, у тебя другой набор сгенерированных данных :-), я же использовал один и тот же для всех серверов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:01 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaНа news://news.gmane.org/gmane.comp.db.firebird.russian я увидел любопытную тему "Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)". Попытка написать туда не удалась - я получил письмо от Gmane Autoauthorizer, ответил на него, но на этом всё заглохло. На работе у меня интернет ограничен, и более подробные исследования я не могу сейчас произвести. На всякий случай (если еще актуально) эту конференцию можно читать/писать через веб или мыло: http://groups.google.com/group/ru-firebird ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:04 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Источники таковы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:07 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
И результат (не весь, но несколько в начале и конце, первую колонку) я сравнивал с эталонным. Вроде совпадает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:09 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Я понял, в чём у меня был косяк-я использовал скрипты для создания индексов из архива tpcrFB20.zip, поскольку не был уверен, что они совпадают с TPC-H. Ну и в итоге не создал primary keys :) Сейчас для чистоты эксперимента опробую Express на виндах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:15 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa Я думаю что глюканул именно Express. Так как этот запрос действительно выбивается из всех остальных. Что там за проблемы я не разбирался, т.к. такой задачи не ставил. Как я уже и сказал - будут оптимальные настройки для Express - будет повторный прогон теста. Я абсолютно не верю, что Expess хоть чем-то хуже ESE на данной задаче в наших конфигурациях. Пока нет исходников реальных исполняемых скриптов, у меня возникают самые мрачные подозрения. На всякий случай обращу внимание, что длина имени индекса у DB2 ограничена всего 18-ю символами, и скрипт создания индексов у меня такой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Статистику собирал так (имя схемы здесь обязательно): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Сперва создавал базу и таблицы, затем грузил данные, затем создавал индексы, затем собирал статистику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:19 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу. Кстати, есть SORTHEAP у базы и есть SHEAPTHRES у СУБД. Совет, как я помню, был поставить SHEAPTHRES = буферному пулу, а SORTHEAP в 4 раза меньше. Но я это не проверял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:24 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Про 18 символов не напоминай, матерился их обрезая что есть мочи. Сount в таблицах выдай сюда. В приципе я могу повторно его прогнать - может и в правду что-то накосячил с параметрами БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:29 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей"[/quot] Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloa[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей" Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)[/quot] В BOL очень красиво и подробно расписан механизм чекпойнтов, действий сервера по восстановлению БД в случае аварийного завершения, но нет ни слова о том, как это коррелировано с производительностью (да и надежностью при сбоях тоже кстати). Так что будет чем заняться, когда свободное время появиться :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 16:39 |
|
||
|
Предварительные результаты по тесту 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 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Отключил кеширование ОС командой db2set DB2NTNOCACHE=ON и прогнал Configuration Adviser. 10 сек в первый раз, 0.4 во второй. Сейчас ещё данные перегенерю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:32 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Насчёт разных данных. Я генерирую их как dbgen -s 1 -v -F Сегодня сгенерировал ещё один набор файлов и сравнил со вчерашними. Они одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 12:49 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
HT выключил, результаты неизменны 100% загрузка проца и отсутствие нагрузки на диск. Танцы с бубном прекращаю, желающие могут сваять сами тестовую систему и натестировать DB2 vs ORA, у меня таких целей нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 14:10 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
2 olegloa сделайте такую фигню: db2admin stop и повторите тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 14:14 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
авторoptimize for n rows - говрит, что результирующий набор (результат работы курсора, или запроса) будет достраиваться динамически. Т.е. не сразу , а по мере прихода FETCH я извиняюсь, но для меня это абракадабра. Почему - изложил в тексте вопроса. То есть, результат так или иначе перед fetch уже должен быть в отсортированном виде. КАК это будет делать сервер - левой или правой рукой, меня абсолютно не волнует. Возможно, вся эта оптимизация состоит именно в том, чтобы не аллокировать сразу большой буфер под фетчи, или еще что, но на мой взгляд, я еще раз повторю - ХИНТ ОПТИМИЗАЦИИ уже сразу заложен в самом запросе - это и есть указание FIRST 100. Про optimize for n rows БЕЗ FIRST 100 я не спрашивал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 15:19 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
2 kdv Если стоит FETCH FIRST а по плану запроса перед тем как выдать первую сотню записей нужно перелопатить (пересортировать) всю таблицу, то не ждите мгновенного ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 15:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaDB2, если нет ни одного коннекта, освобождает память базы данных. Интересно... А зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 15:50 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Это было ещё минимум с v2.1 for OS/2, и до сих пор не знаю ;-). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 15:52 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenman2 olegloa сделайте такую фигню: db2admin stop и повторите тест. Ну так как? результат после остановки сервера администрирования? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 16:12 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
затем, что если есть какие изменения в распределении памяти, то после отсоединения последнего клиента они вступят в силу. Опять же - а зачем память держать, если она не нужна? А если не надо освобождать - то пжалста, укажите принудительно, то есть выбор есть, а выбор есть гууд все imho ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 16:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenman gardenman2 olegloa сделайте такую фигню: db2admin stop и повторите тест. Ну так как? результат после остановки сервера администрирования? А на что, по-вашему, это должно было повлиять? Памяти и так должно хватать, и вряд ли админский сервер ни с того ни с сего дожидается запроса #2 и начинает грузить процессор. Я бы подумал, что все нужные данные закешированы, но сервер почему-то не использует hash join и проводит fullscan. Отсюда отсутствие обращение к диску, 100%-я загрузка процессора и большое время выполнения. Но зачем ему это надо? И как этого можно было добиться? По умолчанию в v8 использование hash join включено (в отличие от v7? или v6? уже не помню, когда дефолт сменился, но в v8 точно включено, а DB2 Express C это v8, а точнее, v8.2fp3), на дефолтном уровне оптимизации hj должны использоваться. Рекомендуют держать пропорцию между sheapthres и sortheap (минимум 2:1), но Configuration Adviser должен был её соблюсть. Ещё можно было испортить схему разными типами данных у primary и foreign keys, но делать это надо было нарочно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 00:34 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
ggvзатем, что если есть какие изменения в распределении памяти, то после отсоединения последнего клиента они вступят в силу. Опять же - а зачем память держать, если она не нужна? А если не надо освобождать - то пжалста, укажите принудительно, то есть выбор есть, а выбор есть гууд все imho Но мой взгляд, всё это неубедительно, не имеет смысла и пользы, и в придачу дезориентирует новичков. База должна выгружаться, когда я СУБД сказал, а не когда СУБД сама решила. Но всё же это не такой большой минус, чтобы из-за него ломать копья. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 00:43 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Я чувствую себя в роли автомеханика-гинеколога из анекдота (который ремонтировал двигатели через выхлопную трубу). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 08:18 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
ну поскольку мне больше приходилось иметь дело с системами автоматической обработки данных, а не с пользователями, то с моей точки зрения это плюс, и я никогда не использовал activate. А вот по поводу новичков - неубедительно. Это какие такие новички, которые читать не любят? Дык им все фичи 'дезорганизирующие' IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 09:19 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
2 Victor Metelitsa Я много раз наблюдал, как DAS ни с того ни с сего вдруг начинает грузить процессор и ниче не шевелится. Все руки не доходят разобраться что к чему. поэтому я как правило устанавливаю DAS так, чтобы он запускался мануально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 11:09 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
у меня тоже пару раз DAS чудил. gardenman, надо бы как-то поймать момент, зафиксировать ошибку. Опишем, откроем PMR ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 11:16 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Виктор, пользоваться db2set DB2NTNOCHACHE не кошерно с версии 8.2 db2 alter tablespace userspace1 no file system caching ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 11:26 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Создание на DB2 базы с нуля 1. Машинка - Athlon 850, чипсет kt133a, 768RAM, новенький диск Samsung 250G 2. Поставил Windows 2003 SE 3. Поставил DB2 сервер с ftp://ftp.software.ibm.com/ps/products/db2/fixes2/english-us/db2winIA32v8/fixpak/FP11_WR21365/FP11_WR21365_ESE.exe при установке - Typical, Single Partition Environment, только English, в C:\SQLLIB\ (по старой привычке) do not prepare db2 tools catalog... 4. Создал каталог C:\DATA 5. В Control Center создал базу данных через adviser: 5.1 Закладка Name. Задал TPCR 5.2 Закладка User Tables. Выбрал High Performance. Нажал кнопку Add. Описал контейнер типа File, размер 5000, имя c:\data\userdata.dat 5.3 Теперь сразу в Summary. Кнопка Show Command показывает CREATE DATABASE tpcr ON 'C:' USING CODESET 1251 TERRITORY RU COLLATE USING SYSTEM USER TABLESPACE MANAGED BY DATABASE USING ( FILE 'C:\DATA\userdata.dat' 1280000 ) ; 6. База данных создалась за 40 секунд. Мне предложили запустить Configuration Adviser, я отказался (сперва загружу данные и соберу статистику). 7. Щёлкнул 4-ю круглую кнопку (Command Editor). Приконнектился к TPCR (target add). 8. Вклеил в окно и исполнил скрипт: Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. dbgen -s 1 -v -F в каталоге c:\tpc-r\db2 10. Выполнил скрипт загрузки Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 11. Выполнил скрипт создания индексов (минут 10). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 13. Запустил на базе Configuration Advisor, 80% память, под workload: Queries( Warehouse). Получил и выполнил скрипт: Код: 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. 35. 36. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:16 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Тест 1. Создал x.bat с содержимым Код: plaintext 1. 2. 3. 2. Создал 2-2-2.sql с три раза повторяющимся запросом Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Geom. mean 1,065 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:17 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Nikolay KulikovВиктор, пользоваться db2set DB2NTNOCHACHE не кошерно с версии 8.2 db2 alter tablespace userspace1 no file system caching Насколько я понимаю, DB2NTNOCHACHE всё-таки должно работать, хоть и obsolete. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:19 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaКак именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader? Нет, я попробовал только IB/FB ;) Просто тут есть свой хинт - мне по роду работы нужны тесты. загружающие железо по самое немогу, а этим тестом сколь-нибудь заметно нагрузить даже минимальные серверы (по входящему железу) не удалось. :( Тот же ТРС-С в приведенном мной Quest Benchmark Factory интересовал меня в плане нагрузки при 500-1000 коннектов - а при этом количестве BF попросту вылетала (дело было не в ограничении до 20 коннектов :) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Nikolay KulikovВиктор, пользоваться db2set DB2NTNOCHACHE не кошерно с версии 8.2 db2 alter tablespace userspace1 no file system caching Что-то я пропустил тот пост Виктора, такие интересные вещи выясняются :-) Значит в DB2 есть возможность работать через кеш файловой системы. А зачем??? Неужели в каких-то случаях это может дать положительный эффект? Особенно на винде. Пока в голову приходит только один ответ - чтобы хоть как-то работало, если засранец админ оставил дефолтный размер буферного пула... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:27 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Раньше SMS всегда кешировались, DMS нет. Потом появилась возможность управлять этим. Насколько я понимаю, SMS для крошечных базулек, где админ/юзер действительно не утруждает себя никакими настройками, а DMS для больших "серьёзных" баз. Кроме того, IBM советует держать в SMS LOB'ы - наверное, это древний workaround древней проблемы (ибо LOB'ы не кешируются буферным пулом). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:41 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaЯ чувствую себя в роли автомеханика-гинеколога из анекдота (который ремонтировал двигатели через выхлопную трубу). Проверили ещё одну машину, на этот раз Pentium4 3.2 гигагерца с гигом ОЗУ, и наконец на что-то "интересное" наткнулись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:46 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
авторЗначит в DB2 есть возможность работать через кеш файловой системы. А зачем??? гм. когда в Yaffil ввели в конфиг флажок отключения файлового кэша виндов, то сервер стал работать используя только свой собственный кэш. При этом, как оказалось (я делал тесты), производительность зависит 1. от размера страницы БД 2. от размера кластера файловой системы в итоге получилось, что нужна какая-то специальная софтина, которая бы перед вот таким отключением кэша ФС показала варианты производительности для разных размеров страниц. То есть, для работы как embedded и вообще как "сервер без администирования и настроек", это не годится. С другой стороны, у Firebird происходит конфликт между его кэшем и кэшем файловой системы, если для БД задан кэш на грани наличия свободной памяти - производительность ухудшается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 13:50 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Да, на Pentium 3.2 тормозить стало чудовищно. Но, похоже, что мы (с Антоном) уже знаем, что за проблемы с DB2 оказались у Олега. Предполагаем, что дело именно именно в HT. Это повлияло на параметр CPUSPEED, который DB2 вычислила неверно, и на этой основе стали генерироваться плохие планы. Предложение: 1. Выключить HT. 2. Выполнить UPDATE DBM CFG USING CPUSPEED -1 IMMEDIATE; 3. На всякий случай рестартовать DB2. db2stop force db2start На 2-й и 3-й раз результаты получились примерно те же, что и у Oracle 9 (0.157, 0.140), хотя первый результат 20 (приписываем медленному винчестеру). Короче, HT давить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 14:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Странно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 16:07 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
говорю вам - вся проблема в DAS. Не запускайте его - и все будет ОК. Во всяком случае в винде можно глянуть какой процесс жрет процессорные ресурсы, и это скорее всего db2dasrrm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 16:20 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
gardenmanговорю вам - вся проблема в DAS. Не запускайте его - и все будет ОК. Во всяком случае в винде можно глянуть какой процесс жрет процессорные ресурсы, и это скорее всего db2dasrrm Всегда запускал, и всегда было ОК. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 17:17 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Я думаю такое поведение DAS OS-specific. На WinXP - довольно частое явление. И, что интерсно DAS начинает тормозить процессы DB2, однако на другие процессы это действует не так сильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 17:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kmikeСтранно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста). Воспользуйтесь Configuration Adviser ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 17:41 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa kmikeСтранно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста). Воспользуйтесь Configuration Adviser ;-) А что будет? Всё накроется? Я в общем-то этими явовскими тулзами не пользуюсь-памяти они жрут слишком дофига, да ещё db2cc частенько требует наличия DAS, который у меня послу установки FP11 перестал запускаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 17:51 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Ну, запустите пункт 13, хотя бы. HT, может, и не причём. Сейчас на AMD64 сокет 754 2.4 гигагерц пробую. По дефолту cpuspeed = примерно 2.7e-07. На втором запросе получились такие: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Попробовал cpuspeed=5e-07. Примерно также. Попробовал cpuspeed=6e-07. Скачок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Как-то совсем не радует меня такая история... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 18:29 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaНу, запустите пункт 13, хотя бы. одного из моих предыдущих писем (результат моего Configuration Advisor). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 18:31 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Как я понял проблема в некорректном определении скорости процессора на определённых конфигурациях железо/софт? Это только у Express или вообще в реализации DB2 под Win32? Я так пологая что нужно ответственным товарищам за DB2 сделать соответствующую запись в FAQ иначе подобные грабли будут всплывать регулярно. P.S. Ссылка на первонаступившего на грабли обязательна :-):-):-):-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 21:14 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Интересно, на _каких_ конфигурациях скорость определяется неверно? У меня определилось 1.89e-07 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 22:15 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaКак я понял проблема в некорректном определении скорости процессора на определённых конфигурациях железо/софт? Это только у Express или вообще в реализации DB2 под Win32? У меня только ESE. Я проверил бы Express, хотя и не верю в какую-либо разницу, но: что моя контора, что я по ADSL, потребляем инет по ценам 24 р за 10 мег и, естественно, жлобимся. Для FAQ ещё рано хотя бы потому, что я проверил только 2-й запрос. Может, другим запросам от моего изменения CPUSPEED не получшеет, а даже похужеет. Я сегодня-завтра проверю несколько CPUSPEED на всех запросах. Надо ещё проследить, на каких запросах меняются планы. И что, если бы у меня процессор был в несколько раз быстрее? Неужто от этого тот нехороший план стал бы хорошим? Странно как. По документации, влияние параметра CPUSPEED на производительность является "low". В общем, это нехорошая история. На грабли, наверное, наступило уже множество народу, просто они об этом не догадываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2006, 14:48 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kmikeИнтересно, на _каких_ конфигурациях скорость определяется неверно? У меня определилось 1.89e-07 Я поторопился про "неверную". Сперва надо узнать, есть ли "верная". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2006, 14:50 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa, я проверял именно Express на виндах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2006, 18:26 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa И что, если бы у меня процессор был в несколько раз быстрее? Неужто от этого тот нехороший план стал бы хорошим? Именно. Оптимизатор бы предпочитал "процессороёмкие" планы планам с множеством I/O. Кстати, раз уж поставил на винду DB2, провёл небольшой эксперимент. Мне всегда было интересно, как сжатие файловой системы влияет на работу СУБД. Дык вот, стандартное NTёвое сжатие директорий даёт примерно 2-2.5 раза выигрыша по месту - я сжимал только SQLT0002.0 , т.е. USERSPACE1 (SMS). В общем, вполне ожидаемо, скорость загрузки в таблицу уменьшилась раза в два. Зато при запросах к большим таблицам с full scan'ами - наоборот, выигрыш в 2.5 раза. Т.е. наверное, для всяких систем с преобладанием чтения - имеет смысл, тем более, что при использовании SMS можно указывать сжатие для отдельных таблиц без всякого выноса в отдельное табличное пространство :) Очень удобно для лентяев :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2006, 18:37 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Configuration Advisor, для Warehouse с одним удалённым и одним локальеым пользователем, 80% на 2 гигах даёт: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:19 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Где CPUSPEED = -1, это 3,306410e-007. Попробовал CPUSPEED из 1E-003 1E-004 1E-005 1E-006 6E-007 5E-007 4E-007 -1. Отложил на завтра 3E-007 2E-007 1E-007. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:21 |
|
||
|
Предварительные результаты по тесту 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:22 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Я также генерировал планы, вырезая из них Estimated Cost. main.rex Код: 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. test.rex Код: 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. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:24 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Планы довольно часто разные, но результаты сходные. Видимых аномалий не так уж много... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:25 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2006, 23:32 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Резюме то какое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 13:13 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
А какое резюме вы ждёте? К тому же, я ещё для нескольких CPUSPEED прогон не сделал. Ожидаю, что если вы поставите CPUSPEED в значение вроде 6E-007, второму запросу должно сильно получшеть, а остальным - практически без разницы, по сравнению с вашими результатами. (Зато мои UPDATE CONFIGURATION повлияют на другие запросы, хотя они и сгенерированы Configuration Adviser'ом, а не подобраны вручную). В общем, DB2 выступила хуже, чем я думал. Но у FB она, мне кажется, всё же должна выиграть практически везде, если сменить правила игры (напр., разрешить любые индексы, расположить базу на 4-х дисках..., ибо именно для того у "тяжёлых" СУБД столько "ручек"). Вот DB2 vs Oracle беспокоит больше. Мне очень не нравятся, например, 8-й и 11-й запросы на первом прогоне. Надо попытаться понять, почему так получилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 14:05 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Да я и не собирался сравнивать Db2 с FB2, ясно что DB2 обладает большими возможностями и максимальной производительностью. А вот ORA/MS - есть смысл бодаться. Резюме я вижу в в виде заметки в факе и проблемах с CPUSPEED и способах решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 15:48 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa, а что не так с 11м запросом? ~8с первое выполнение, и примерно .8-1.2 -последующие. У оракла, вроде бы, не лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 16:22 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
Кстати, обратил внимание на разброс в 6-10 раз по времени выполнения на двух разных машинах с Ораклом. Запрос #20 - я считаю, вообще ни в какие ворота не лезет :) Наверное, на второй (с 2ГБ) всё просто в памяти сидит. Хотя там и первое выполнение в 5 раз быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 16:57 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
olegloaРезюме я вижу в в виде заметки в факе и проблемах с CPUSPEED и способах решения. На самом деле, мне ещё непонятно, что писать (не говоря о том, что непонятно даже, куда писать). Да, мы видим цифры, но максимум, что я могу, это предложить админу погонять приведённые ранее тесты и посмотреть, как выполняется запрос номер два. По-хорошему, эти результаты надо было бы обсудить с людьми из Торонто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:20 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kmikeVictor Metelitsa, а что не так с 11м запросом? ~8с первое выполнение, и примерно .8-1.2 -последующие. У оракла, вроде бы, не лучше. Вот что приводил я. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Чем ваш конфиг отличается от моего? А если ссылаетесь на результаты Олега, то, наверное, там SMS tablespace с включённым кешированием ОС, а я, как вы могли видеть, использовал DMS. Пока попробую поиграть с prefetch size - может, явное задание поменяет картину. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:24 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
kmikeКстати, обратил внимание на разброс в 6-10 раз по времени выполнения на двух разных машинах с Ораклом. Запрос #20 - я считаю, вообще ни в какие ворота не лезет :) Наверное, на второй (с 2ГБ) всё просто в памяти сидит. Хотя там и первое выполнение в 5 раз быстрее. Процессоры разные, диски разные, количество памяти разное. Если вы приглядитесь, то и у меня на одной и той же машине, одном и том же диске, хотя не на 100% совпадающими настройками, почему-то ускорился запрос #2 на первом проходе. Сперва я показал Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. При этом в первый раз CPUSPEED=5E-007 был плох, а во второй раз - хорош. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:32 |
|
||
|
Предварительные результаты по тесту 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 00:23 |
|
||
|
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
|
|||
|---|---|---|---|
|
#18+
vadiminfo Ну зачем Вы так говорите? 1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - вопрос времени. ... На днях был в одной конторе. Год назад обучал их админа делать бэкап/рестор для FireBird. Написал несложный bat - file и т.д. В общем, все получилось. Потом админ уволился, через какое-то время взяли нового. Который "ничего не трогал". Потом попытался рестор выполнить из бэкапа. Типа - вернуть данные на сутки назад. Ничего не изменилось. Оказалось, что база бэкапилась вовсе не рабочая, а та, что была рабочей полгода назад. Хорошо, что имена файлов у этой базы и у рабочей были разные, и данные не грохнулись.. Т.е. классно, конечно, что FireBird почти год крутился без присмотра и без проблем, но, с другой стороны, ничего хорошего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 20:00 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553502]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
157ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 477ms |

| 0 / 0 |
