Comments 24
Спасибо за статью.
А не замеряли нагрузку на CPU? Возможно ваши тесты ресурсоёмкие и упираются в процессор который и не дает нормально разогнаться IM
А не замеряли нагрузку на CPU? Возможно ваши тесты ресурсоёмкие и упираются в процессор который и не дает нормально разогнаться IM
Нагрузку на сервер анализировал, используя Oracle AWR отчёт. И в обоих случаях узким местом был процессор, т.к. оперативной памяти было достаточно для кеширования всего объёма данных. Цель была — оценить, какой прирост производительности можно получить за счёт IM Option. И в этом смысле оба теста имели равные условия.
А можете выложить какой-нибудь из AWR?
На мой взгляд в таком тесте, когда только 4 ядра и все в памяти не желательно иметь более 2-3-х работающих сессий к БД.
Иначе, получается, что большая часть ожиданий будет не cpu, а wait for cpu — повылазят различные mutex, cursor pin и т.п.
Отсюда может быть и небольшая разница в результатах, так как основное время ушло на не связанные с логикой обработки запросов ожидания.
Иначе, получается, что большая часть ожиданий будет не cpu, а wait for cpu — повылазят различные mutex, cursor pin и т.п.
Отсюда может быть и небольшая разница в результатах, так как основное время ушло на не связанные с логикой обработки запросов ожидания.
AWR отчёты могу на почту выслать.
Момент с количеством параллельных сессий учитывался. Для сравнения вариант с 2-мя сессиями и 12-ю запусками (те же 528 итоговых запуска):
1) 14 мин 13 сек. без IM
2) 13 мин 07 сек. с IM
Разница менее 10%.
Момент с количеством параллельных сессий учитывался. Для сравнения вариант с 2-мя сессиями и 12-ю запусками (те же 528 итоговых запуска):
1) 14 мин 13 сек. без IM
2) 13 мин 07 сек. с IM
Разница менее 10%.
Пропустил сообщение выше. Можно и мне на почту AWRы?
mkrupenin, подозрительно хорошие у вас результаты для noinmemory. Можно AWR и этого теста? А в идеале ashdump обоих тестов. Я прямо сейчас решил повторить ваш тест с помощью Benchmark factory (15-и дневная trial версия), с вашей же нагрузкой, так у меня noinmemory адско затыкается на direct path reads, и inmemory в несколько раз быстрее.
Да, отличная статья.
Что за запросы выполнялись поделитесь хотя бы?
Где был bottleneck?
То же самое на сжатых данных на диске пробовали?
Тесты на холодную базу запускали?
Что за запросы выполнялись поделитесь хотя бы?
Где был bottleneck?
То же самое на сжатых данных на диске пробовали?
Тесты на холодную базу запускали?
Поделюсь и запросами и ddl скриптами. Кому интересно, могу дать ссылку и на примерные планы выполнения запросов со статистикой.
Bottleneck — CPU.
Пробовал много дополнительных вариантов: несколько видов partitioning, без partitioning, c parallel и без, с компрессией вариант. При этом отдельные запросы специально не оптимизировались (индексами, хинтами,...). Делал это для того, чтобы показать ещё 1-2 быстрых способа оптимизации (например, parallel и/или db_big_table_cache_percent_target). Но на этом тесте и моём CPU интересных результатов не получилось и ограничился только IM Option.
> Тесты на холодную базу запускали?
Да, но так как каждый запрос выполнялся по 24 раза, это особой роли не играло. И 1-е выполнение не в разы было медленнее (диск SSD).
Bottleneck — CPU.
Пробовал много дополнительных вариантов: несколько видов partitioning, без partitioning, c parallel и без, с компрессией вариант. При этом отдельные запросы специально не оптимизировались (индексами, хинтами,...). Делал это для того, чтобы показать ещё 1-2 быстрых способа оптимизации (например, parallel и/или db_big_table_cache_percent_target). Но на этом тесте и моём CPU интересных результатов не получилось и ограничился только IM Option.
> Тесты на холодную базу запускали?
Да, но так как каждый запрос выполнялся по 24 раза, это особой роли не играло. И 1-е выполнение не в разы было медленнее (диск SSD).
Не имея структуры БД и 12-ого оракла перед глазами сложно сказать, но есть предположение, что в тесте большая часть запросов построена таким образом, чтобы данные извлекались по индексам/ключам. Но т.к. индексы не помещаются в память, то и выигрыша получено не было. Разница должна быть в таком тесте, где большая часть запросов построена на аналитических индексах — после их удаления и перемещения данных in-memory не будет необходимости в обращении к индексным сегментам.
Я не совсем понял комментарий. Какие индексы в память не помещаются? Относительно чего не было выигрыша? И что понимаете под аналитическими индексами?
Выше ссылки на ddl таблиц и запросы, просьба уточнить комментарий.
Выше ссылки на ddl таблиц и запросы, просьба уточнить комментарий.
Какие индексы в память не помещаются?
Никакие. Т.е. full-scan по столбцам/таблицам в памяти может быть производительней доступа по индексу (например, если это низкоселективный многоколоночный индекс). Поэтому ускорение будет в первую очередь в запросах с долгим full / range / skip scan. Конечно, оптимизатор с большой долей вероятности сам определит, что нужно сканировать, а что нет, но минимальный анализ данных/структур проводить нужно — просто запихать всё в память и ждать космических скоростей не приходится, особенно если на вашем железе можно упереться в CPU. Смысл ведь IM в том чтобы разгрузить IO за счет памяти/CPU — если у вас второго не хватает, откуда тогда будет выигрыш в скорости?
И что понимаете под аналитическими индексами?
Индексы, созданные для оптимизации запросов, а не для обеспечения контроля целостности (pk/unique index) БД. Например для OLAP систем объём таких индексов может быть сравним с объёмом самих данных — в этом случае IM может давать огромный выигрыш — ведь не нужно сначала сканировать сегмент индексов и потом обращаться к таблице с данными — всё есть сразу в памяти. Плюс без таких индексов значительно сокращается время загрузки данных/обновления мат.представлений, сбор статистики.
В бенчмарке TCP-H 22 запроса различной сложности как раз для DSS/OLAP систем. Ваши выводы будут интересны на конкретном примере.
Первое, что я лично ожидал увидеть от Oracle IM на своих кейсах — это значительное ускорение аналитических запросов за счёт compressed column store. Допустим, есть fact таблица из 30 полей и XXX млн. строк, выбираю XX млн. строк и 3 поля. К примеру, СУБД Vertica ускоряет такие запросы минимум на порядок с 1 нодой.
Первое, что я лично ожидал увидеть от Oracle IM на своих кейсах — это значительное ускорение аналитических запросов за счёт compressed column store. Допустим, есть fact таблица из 30 полей и XXX млн. строк, выбираю XX млн. строк и 3 поля. К примеру, СУБД Vertica ускоряет такие запросы минимум на порядок с 1 нодой.
Насчет индексов непонятно.
Если таблица все целиком лежит в памяти, почему на индексы места не хватает? Понятно, что это дополнительное место. Но обычный кейс с индексами — они меньше таблиц.
И если мы часть храним в памяти, часть на диске, очевидно преимущества от использования памяти нивелируются. И вместо прироста производительности на порядки, получаем на проценты.
Если таблица все целиком лежит в памяти, почему на индексы места не хватает? Понятно, что это дополнительное место. Но обычный кейс с индексами — они меньше таблиц.
И если мы часть храним в памяти, часть на диске, очевидно преимущества от использования памяти нивелируются. И вместо прироста производительности на порядки, получаем на проценты.
Я не писал, что индексам места в памяти не хватало. Я для column store в In-Memory индексов нет в принципе.
И с этой стороны тоже непонятно.
Поколоночное хранение обычно используют для DWH, а DWH обычно предполагает, что объем таков, что ни в какую память не поместиться. Соответственно, остается поколоночное хранение для обычных баз. С дисками поколоночное хранение для обычных баз не используют из-за дороговизны модификации данных. С памятью наверно это перестает быть узким местом. Но это предположение.
Поколоночное хранение обычно используют для DWH, а DWH обычно предполагает, что объем таков, что ни в какую память не поместиться. Соответственно, остается поколоночное хранение для обычных баз. С дисками поколоночное хранение для обычных баз не используют из-за дороговизны модификации данных. С памятью наверно это перестает быть узким местом. Но это предположение.
Есть ещё в планах выполнение аналогичного теста на полюбившихся мною СУБД Vertica и Exasol.
Тоже гонял TPC-H (SF=50, таблица LINEITEM на 300M строк) на предмет сравнения отдельных запросов из буффер-кэша vs. инмемори-кэша. Из IMC получалось в среднем в 3 раза быстрее. Можете показать результат Q1 для обоих случаем с использованием /* parallel(4) */?
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»
50 Гб конечно интереснее. На какой конфигурации сервера тестировали? Как в буферный кэш все данные отправляли? У меня разница в разы получалась только тогда, когда памяти на кэш не хватало.
Результаты для Q1:
no IM no parallel — 6.62 сек.
no IM parallel(4) — 5.88 сек.
IM no parallel — 6.47 сек.
IM no parallel(4) — 3.15 сек
Планы и статистика по ссылке.
Но по сумме всех запросов IM+parallel мне не давал выигрыш в 2 раза.
Результаты для Q1:
no IM no parallel — 6.62 сек.
no IM parallel(4) — 5.88 сек.
IM no parallel — 6.47 сек.
IM no parallel(4) — 3.15 сек
Планы и статистика по ссылке.
Но по сумме всех запросов IM+parallel мне не давал выигрыш в 2 раза.
Ясно. Спасибо.
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
>можно только удалить индексы, которые не нужны для таблиц IM
Если не секрет, откуда у вас такая уверенность, так в доке написано?
Просто индексы нужны не только для фул скана, а для того чтобы быстро по дереву в 4-5 шагов найти одну строчку с достаточно уникальными атрибутами среди триллиона строк. Пример думаю не сложно представить.
Честное тестирование это конечно очень хорошо, особенно из первых рук.
Хотелось бы увидеть тот же тест на Вертике, хотя это совсем другой класс продктов, но под ваши тяжелые запросы думаю самое-то.
Хотелось бы конечно и на Сап Ханне, но это нужно к вендору или у кого она случайно завалялась.
Я наверное попробую сделать этот же тест на MS SQL 2016
Если не секрет, откуда у вас такая уверенность, так в доке написано?
Просто индексы нужны не только для фул скана, а для того чтобы быстро по дереву в 4-5 шагов найти одну строчку с достаточно уникальными атрибутами среди триллиона строк. Пример думаю не сложно представить.
Честное тестирование это конечно очень хорошо, особенно из первых рук.
Хотелось бы увидеть тот же тест на Вертике, хотя это совсем другой класс продктов, но под ваши тяжелые запросы думаю самое-то.
Хотелось бы конечно и на Сап Ханне, но это нужно к вендору или у кого она случайно завалялась.
Я наверное попробую сделать этот же тест на MS SQL 2016
Про индексы. Конечно же каждый кейс (таблица, конкретный индекс, характерные запросы,...) нужно рассматривать индивидуально. Если после включения IM необходимость в индексе пропадает, то удаляем, нет — оставляем. Например, в случае факт таблицы для аналитики актуальность большинства индексов скорее пропадёт.
Аналогичный тест на Vertica есть в планах. SAP HANA в ближайшее время вряд ли.
Результаты теста на MS SQL будет интересно почитать, особенно в части IM и column store.
Аналогичный тест на Vertica есть в планах. SAP HANA в ближайшее время вряд ли.
Результаты теста на MS SQL будет интересно почитать, особенно в части IM и column store.
А отчет AWR есть? У меня сильное подозрение, что у вас слишком много ушло тупо ожидая процессора (CPU queue length смотрели?), т.к. ноут у вас 4-х ядерный, а нагрузку гнали в 8 пользователей, и помимо оракла еще и сам бенчмарк работал, да и еще что-нибудь, наверное. Попробуйте в 2-3 пользователя
Sign up to leave a comment.
Тестирование производительности Oracle In-Memory Option c использованием TPC-H Benchmark