Миф: как IBM победил БЭСМ

[Dmitry67]

Фигня (подливая коньяк в кофе). Я вот недавно на production делал truncate table ) чтобы место почистить )

[tengiz]

У меня в молодости, когда я был DBA (ужас - 20 лет назад!) тоже такое бывало - самое кавалерийское что я сделал, это когда в банке балансы по счетам съехали из-за ошибки в триггере, который изменили тем утром, я ad-hoc update-ом перевычислил балансы и накатил их наживую (в самый разгар операционного дня, когда кассиры и операционисты вовсю лупили новые данные и обслуживали клиентов), после исправления триггера, причем с первого раза правильно :) ! Хорошо, схема была сделана так (сам делал, как считал нужным) что можно было все сделать коротко и ясно. На всякий случай сохранил этот update в процедуре на случай, если еще раз похожее случится. Но больше не случалось.

[zVlad]

Парадоксом это выглядело лишь до тех пор пока не стало известно об индексах. А началось прояснение с того что я начал смотреть в ДБ2 есть ли индексы на колонках в предикатах. Их не оказалось и стало ясно что на MS SQL лучший результат мог быть только если там есть индексы. Индексы там оказались. Теперь дело за повторением этого на МФ с индексами.

Теперь понятно. Для такого запроса если оптимизатор выберет hash anti-join вместо nested loop/merge anti-join самым главным ресурсом для скорости может оказаться память, а не индексы.

Я сейчас создаю индексы, их никто не промялся создавать оказывается. Там посмотрим.

А у вас что, можно просто взять и _создать индекс_? А по рукам не дают??

Создание индекса - это изменение. Изменение должно быть записано в виде скрипта, протестировано, желательно чтобы еще ДБА глянул, а потом только _скрипт_ выполнен в продакшене, с аппрувелом изменения. А прросто _ДБА пошел и создал_ вообще говоря - так и базу убить можно. Индексы то, они что-то ускоряют а что-то замедляют, и по уму если индекс не _просто потеряли_ - нужно перфоменс тесты прогонять.

Все нормально, StrangeR, я не на Production это делал - на так называемом Migration. E'to BD где девелоперы тестируют скорую загрузку данных с Oracle BD. Строго говоря это БД с данными из Production плюс что еще.
Я добавлю позже об этом - сейчас нет времени, хочу по утру еще пару тестов прогнать и убить те индексы что создал вчера вечером

[Dmitry67]

Фигня (подливая коньяк в кофе). Я вот недавно на production делал truncate table ) чтобы место почистить )

Справедливости скажу, чтобы не шокировать публику, что это технические таблички лога аппликации, которые иногда раздуваются изза всякого бреда, и у меня есть давно письмо от главного менеджера саппорта с разрешением чистить эти таблицы всегда и везде. Кроме того, у нас ведь adhoc по всем серверам пишется в аудит

[iDesperado]

Короче дружбан мой появился, но говорит Клиент2 ушел с нашего сопровозгдения вот уже год как.

ну да, ну да ...
так может все таки подберете время и покажете нагрузку серьезней, чем у меня на ноутбуке с вашего МФ как я понимаю вы там и буфера уже увеличили, мы за одно и оценим, не занят ли ваш МФ демонстрацией невероятного I/O на данных, которые запросто в памяти ноутбука помещаются.

[zVlad]

Короче дружбан мой появился, но говорит Клиент2 ушел с нашего сопровозгдения вот уже год как.

ну да, ну да ...
так может все таки подберете время и покажете нагрузку серьезней, чем у меня на ноутбуке с вашего МФ как я понимаю вы там и буфера уже увеличили, мы за одно и оценим, не занят ли ваш МФ демонстрацией невероятного I/O на данных, которые запросто в памяти ноутбука помещаются.

Я не знаю что Вы имеете в виду говоря: " нагрузку серьезней, чем у меня на ноутбуке". Вы никаких данных о Вашей нагрузке не приводите. В то же время я привожу данные. Если Вам интересно Вы можете сами сравнить мои данные с Вашими. Если Вы хотите чтобы я это сделал - приведите Ваши данные. Все просто и не надо нукать.

[iDesperado]

Я не знаю что Вы имеете в виду говоря: " нагрузку серьезней, чем у меня на ноутбуке". Вы никаких данных о Вашей нагрузке не приводите. В то же время я привожу данные. Если Вам интересно Вы можете сами сравнить мои данные с Вашими. Если Вы хотите чтобы я это сделал - приведите Ваши данные. Все просто и не надо нукать.

то, что вы показали это момент когда в базу ничего по сути не пишется, при этом чтение идет только лишь потому, что буферный пул просто крошечный, 3.3гб. я уже писал об этом

ну давайте вы подберете момент с хоть какой-то нагрузкой. то, что вы показали не нагрузка в мире PC. если проссумировать ваши BPs выйдет всего 843500
страниц по 4к, т.е. 3.3Gb. при столь крошечных даже по меркам моего ноутбука буферах у вас не самое плохое попадание в них, как минимум у BP1
BP Hit % - Random = 86.7%
BP Hit % - Sequential = 66.6%

т.е. по этим данным выглядит, что у вас приложение работает с крошечным объемом активных данных 66-86% которых уместились в 3.3Gb, а остальные терабайты лежат никому ненужным архивом.

или это нормальная нагрузка для МФ ?

что касается цифр, могу показать такое с дев сервера

Code: Select all

# sar -d 1 100
02:11:31 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:11:32 PM    dev8-1    267.68    937.37   3701.01     17.33      0.57      2.07      1.18     31.52
02:11:32 PM   dev8-12    236.36    533.33   3903.03     18.77      0.48      2.03      1.18     27.88
02:11:32 PM   dev8-22    248.48    581.82   3894.95     18.02      0.49      1.97      1.24     30.71
02:11:32 PM   dev8-38    237.37    355.56   3967.68     18.21      0.45      1.91      1.16     27.47
02:11:32 PM  dev212-0   2053.54   2408.08  15466.67      8.70      3.46      1.67      0.49    100.81
02:11:32 PM  dev212-1   2053.54   2408.08  15466.67      8.70      3.46      1.68      0.49    100.91

но я не знаю есть ли смысл сравнивать, одно дело последовательное чтение full scan таблички, другое рандомное чтение OLTP сотен других юзеров.
например у нас как я понимаю есть SSD кеш, куда перемещаются горячие блоки. но не каждый день везет оказаться на SSD ...

[zVlad]

....что касается цифр, могу показать такое с дев сервера

Code: Select all

# sar -d 1 100
02:11:31 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:11:32 PM    dev8-1    267.68    937.37   3701.01     17.33      0.57      2.07      1.18     31.52
02:11:32 PM   dev8-12    236.36    533.33   3903.03     18.77      0.48      2.03      1.18     27.88
02:11:32 PM   dev8-22    248.48    581.82   3894.95     18.02      0.49      1.97      1.24     30.71
02:11:32 PM   dev8-38    237.37    355.56   3967.68     18.21      0.45      1.91      1.16     27.47
02:11:32 PM  dev212-0   2053.54   2408.08  15466.67      8.70      3.46      1.67      0.49    100.81
02:11:32 PM  dev212-1   2053.54   2408.08  15466.67      8.70      3.46      1.68      0.49    100.91

но я не знаю есть ли смысл сравнивать, одно дело последовательное чтение full scan таблички, другое рандомное чтение OLTP сотен других юзеров.
например у нас как я понимаю есть SSD кеш, куда перемещаются горячие блоки. но не каждый день везет оказаться на SSD ...

Нет смысла сравнивать хотя бы потому что я дал Вам (и другим) не системные числа, а числа одного лишь DB2 (не единственной БД на одном МФ и не единственного класса приложений в нем выполняющихся), в терминах RDBMS, понятном каждому кто работает с RDBMS.

Я даже вникать в Ваши числа не вижу смтсла потому что... непонимаю зачем они приведены. Вот если бы я привел аналогичную статистику, а потом Вы бы свою, то это имело бы смысл. Или наоборот. Но Вы сами произвольно решили сравнивать статистику одного лишь приложение на МФ со всей активностью на устройствах вашего сервера. Ради бога сравнивайте, но имейте в виду перечисленные обстоятельства.

[Dmitry67]

А зачем вы первый привели статистику, кстати?

P.S.
Было бы интересно ту кверь запустить на MS SQL, удалив индексы, которых не было в DB2. Уверен, было бы быстрее (скорее всего были бы scans->hash joins, никак не 20 часов)

[iDesperado]

Я не знаю что Вы имеете в виду говоря: " нагрузку серьезней, чем у меня на ноутбуке". Вы никаких данных о Вашей нагрузке не приводите. В то же время я привожу данные. Если Вам интересно Вы можете сами сравнить мои данные с Вашими. Если Вы хотите чтобы я это сделал - приведите Ваши данные. Все просто и не надо нукать.

Я даже вникать в Ваши числа не вижу смтсла потому что... непонимаю зачем они приведены.

Я не знаю. Я вся такая внезапная, такая противоречивая вся. (С)

[zVlad]

А зачем вы первый привели статистику, кстати?

P.S.
Было бы интересно ту кверь запустить на MS SQL, удалив индексы, которых не было в DB2. Уверен, было бы быстрее (скорее всего были бы scans->hash joins, никак не 20 часов)

Уже точно не для того чтобы сравнивать ее с температурой воздуха в Африке. Привел чтобы от словесной шелухи перейти к языку цифр. Это всегда у нас поддерживалось не мне Вам говорить.

Сейчас как раз смотрели активность на MS SQL servere который есть реплика нашей БД и который используется для ad-hoc репортов. Это кстати один из четырех таких серверов причем один из них - Oracle. Прикинули сколько DML на нем выполняется. Поличилось не больше 100000 за 5 минут (это я с хорошим запасом в сторону увеличения говорю, на самом деле пришлось запускать trace и DBA дал только 2 минуты, сказав щас эта trace все завалит. Сравните с тем что у меня в DB2 trace включена постоянно и я могу в любой момент смотреть History об этом и многом другом). за две минуты мы оттрассировали где-то 17000 DMLs. Я сказал 100000 за 5 минут (часть из них - это репликационные DML), сравните с 2 000 000 DMLs на DB2, которые я показал вчера.

Никто конечно удалять индексы на MS SQL, увы, не будет чтобы протестировать Вашу идею. Можно лишь гадать.

[zVlad]

Я не знаю что Вы имеете в виду говоря: " нагрузку серьезней, чем у меня на ноутбуке". Вы никаких данных о Вашей нагрузке не приводите. В то же время я привожу данные. Если Вам интересно Вы можете сами сравнить мои данные с Вашими. Если Вы хотите чтобы я это сделал - приведите Ваши данные. Все просто и не надо нукать.

Я даже вникать в Ваши числа не вижу смтсла потому что... непонимаю зачем они приведены.

Я не знаю. Я вся такая внезапная, такая противоречивая вся. (С)

Идите в жопу, iDesperado.

[irigor]

Не джентельмен

[Dmitry67]

Кстати хорошая картинка с моего компа которая показывает что Windows "aware" что половина lcpu - hyperthreaded
Они загружаются в последнюю очередь

[Vladimir1440]

Кстати хорошая картинка с моего компа которая показывает что Windows "aware" что половина lcpu - hyperthreaded
Они загружаются в последнюю очередь

Это Вы так компом xвастаетесь (4 коре 8 тред 16гб памяти")? Так у вас 92 процесса запущенно одновременно. Шучу, шучу: у случайныx людей 16 гигабайт не попадается - раз есть, значит надо.

А подметили вы совершенно правильно. Самое прикольное - запустить какую-нибудь нагрузку подвешивающую комп на 100% ютилизейшн и посмотреть (в окошке левее графиков: "CPU usage"). Потом ребутнуться, отменить hyperthread в CMOS, запустить нагрузку, и посмотреть. В первом случае будет ЛОЖНАЯ цифра (нагрузка 50% якобы - потому что коре ранаются на 100% а треды - логическиe процессоры - ничего не делают: 0%), во втором - правдивая (100% утилизации). И если засечь время (сколько одно и то же делается , подвешивая машину - здоровая виртуалка стартует, например) то будет с точностью до секунды в обеиx случаяx (поскольку тред производительности не добавил, а число железныx коре делавшиx всю работу - в обеиx случаяx одинаково же).

Короче, иx (hyperthread) выгода - только когда редкие "всплески" нагрузки на машине в основном стоЯщей. Когда же "машина пашет" (процессор вечно занят) - процессору не до тредов: перемолачивает всё честными железными корами, не занимаясь сортировкой что можно пере-поручить логическим процессорам (и без этого дел по горло, типа).

Да и по вашему скриншоту видно что "CPU usage" - это среднее арифметическое по всем графикам (совершенно без учёта: где - реальный железный процессор, а где - выделенный на нём логический процессор).