cpu - work in progress, part II
Как вы наверное знаете по нашим тестам (большое спасибо всем кто прислал результаты !), даже не самый последний Xeon делает Power 7 как минимум в два раза . Однако Oracle c нами категорически не согласен! Берем тесты OEBS на сайте Oracle:
Легко видеть по ссылке выше, что 6 ядер Power 7 дают 213,523 попугаев, а 2 x 3.33 GHz Intel® Xeon™ Six-Core X5680 processors (12-cores) дают 185,643 попугаев.
Итого ядро Power7 в два раза производительнее Xeon 5680. Или я чего-то не догоняю ? -)
Я нашел два подвоха, мне интересно видите ли вы их -) Потратьте 15 минут на просмотр статистики (отчеты и AWR), это даже полезно чтобы получить представление о том, как следует оформлять результаты тестов.
Я обновлю пост через какое-то время на основе того, что найдут читатели.
PS. Обратите внимание на времена ответа массивов. Из AWR репорта P710 можно извлечь что log file parallel write/db file parallel write ~1 ms, log file sync ~ 4 ms, db file sequential read ~ 3 ms, db file scattered read ~ 7. В тесте использовался DS5000 который вообще-то дает до 700,000 IOPS. DS5000 это mid-range.
Легко видеть по ссылке выше, что 6 ядер Power 7 дают 213,523 попугаев, а 2 x 3.33 GHz Intel® Xeon™ Six-Core X5680 processors (12-cores) дают 185,643 попугаев.
Итого ядро Power7 в два раза производительнее Xeon 5680. Или я чего-то не догоняю ? -)
Я нашел два подвоха, мне интересно видите ли вы их -) Потратьте 15 минут на просмотр статистики (отчеты и AWR), это даже полезно чтобы получить представление о том, как следует оформлять результаты тестов.
Я обновлю пост через какое-то время на основе того, что найдут читатели.
PS. Обратите внимание на времена ответа массивов. Из AWR репорта P710 можно извлечь что log file parallel write/db file parallel write ~1 ms, log file sync ~ 4 ms, db file sequential read ~ 3 ms, db file scattered read ~ 7. В тесте использовался DS5000 который вообще-то дает до 700,000 IOPS. DS5000 это mid-range.
что первым бросается,
ОтветитьУдалитьэто графики загрузки процессоров не совпадают.
Возможно, все объясняется тем,
что патчи OEBS разные. Может и результаты в попугаях поэтому отличаются :)
>Может и результаты в попугаях поэтому отличаются
ОтветитьУдалитьДумаю что результаты разные по другой причине. Процессорная мощность вроде как есть, но не используется..
Я не уверен, что результаты тестов можно сравнивать, т.к. тестируются разные базы. К примеру, SQL id cd9mbmqyf4qhp, Executions - 1,689,188, Gets per Exec- 12.65 на Xeon и Executions - 939,444, Gets per Exec-30.30 на Power. Или SQL id 72yyswsqkzkrm, Executions - 14, Gets per Exec 15,328,178.64 - Xeon, Executions - 14 Gets per Exec 8,674,325.36 - Power. Т.е. одни и те же запросы потребляют разное кол-во LIO.
ОтветитьУдалить>DS5000 который вообще-то дает до 700,000 IOPS.
ОтветитьУдалитьСправедливости ради, в SPC-1 он смог дать всего 62к iops, 700k это, наверное, совсем благоприятные условия в течение очень короткого времени.
>Обратите внимание на времена ответа массивов.
не сказал бы, что времена ответа плохи: 1мс на log file parallel write (непосредственно запись в массив) очень неплохо. вот log file sync при этом = 4мс как-то многовато и может говорить, что лограйтеру не хватает циклов CPU.
>Процессорная мощность вроде как есть, но не используется..
судя по табличкам в полных отчетах, 710 периодически был неплохо так занят работой. на участке "inventory" idle всего 8%, да и LA по всему тесту 58% что больше чем у xeon ровно в 2 раза (сюрприз да? учитывая, что Xeon-ядер тоже в два раза больше =) )
Странно конечно что память у экземпляра в двух случаях распределена очень по-разному: pga на power в 2.5 раза больше + выделен огромный в половину sga keep_pool, а у Xeon стоит sga_target.
Чего я совсем не понял: почему в секции "top 5 events" не собирается 100%?
Сам тест похоже заточен не для того, что бы подвести машину к 100% а для того, что бы пройти N транзакций (или батчей, что там в OEBS?) за определенное время и посмотреть на метрики производительности.
>> патчи OEBS разные
ОтветитьУдалитьпоэтому и запросы изменились?
и т.д.
>Справедливости ради, в SPC-1 он смог дать всего 62к iops
ОтветитьУдалитьЭто точно ближе к тому что я ожидал. Буду благодарен за ссылку. Одна из идей - что цифра с сайта это на SSD дисках.
>Сам тест похоже заточен не для того, что бы подвести машину к 100% а для того, что бы пройти N транзакций
Это бы все объяснило...Ищу подтверждения..
>патчи OEBS разные. Может и результаты в попугаях поэтому отличаются
>Я не уверен, что результаты тестов можно сравнивать, т.к. тестируются разные базы
Не то что бы я не понимал ваших аргументов ..но тогда зачем бы все это лежало в одном списке как application benchmark ?
Вряд ли у них есть тестовый набор данных, скорее каждый генерит его и то что мы видим разницу это результат
- разных настроек ОС и СУБД
- генерации данных
Но...что-то мне подсказывает что перед публикацией пробуют разные настройки и все таки публикуют лучшие.
Так что конечно это никакой не тест CPU - это application test. Бизнесу кстати на CPU плевать - ему транзакции подавай а из-за чего кто-то лучше/хуже ( OS/диски/патчи/версия СУБД) - все равно.
Так что мое мнение - сравнение попугаев - честное, несмотря на.
Но утверждать что причиной разницы в попугаях являлась какая-то одна компонента (скажем CPU) - на это недостаточно данных.
>> Вряд ли у них есть тестовый набор данных
ОтветитьУдалитьони на VISION тесты эти гоняли.
VISION - это как бы демо OEBS и "тестовых" данных в нем на 200GB
>Это точно ближе к тому что я ожидал. Буду благодарен за ссылку. Одна из идей - что цифра с сайта это на SSD дисках.
ОтветитьУдалитьсобственно: http://www.storageperformance.org/home/
Там есть несколько тестов: SPC-1 некий OLTP, основная метрика -- время отклика массива, SPC-2 -- пропускная способность.
Результаты DS5300 там имеются дважды: здесь -> http://www.storageperformance.org/results/a00070_IBM_DS5300_SPC1_executive-summary.pdf
и здесь -> http://www.storageperformance.org/benchmark_results_files/SPC-1/IBM/A00080_IBM_DS5300-FDE/a00080_IBM_DS5300-FDE_SPC1_executive-summary-r1.pdf