T34

Update 1. 26 сентября Larry все объяснит про Super Cluster и T4-4 !

Несмотря на отсутствие официального анонса (наверное будет на OpenWorld) в интернете вовсю уже обсуждается новый процессор Sparc T4, который является следующим поколением за T3. Помимо прочих улучшений Oracle похоже сделал вложения в производительность одного потока (single thread performance) и добился существенных улучшений на этом поприще, по крайне мере в 2 раза. Второй интересный факт - уменьшение кол-ва ядер (с 16 до 8) одновременно с поднятием частоты до ~3GHz. Это интересная тенденция - например Intel   увеличив кол-во ядер, одновременно  понизил частоту в своих процессорах серии E7.  Т.е. в некотором смысле компании идут встречным курсом -)  Одна из самых интересных фич T4 называется critical thread API - возможность распознавания важных потоков  в приложении и выделении этому потоку целого ядра.  Напомню в чем была проблема с T2/T3 - потоков было очень много, но если нужно было запустить OLTP  задачку то производительность была относительно невысокой, поскольку потоку не давали всей мощности ядра. Особенно плохо конечно прихоИнформации  пока очень мало, и как работает эта магия пока не понятно. Конечно же с выходом нового процессора   Oracle получает возможность управления этим механизмом, чтобы сделать Oracle Database  на T4 более производительней. На  T3, по моему мнению,  ставить Oracle было не вполне удачной идей, хотя Oracle думал иначе -). Кстати, цитата, "we expect that many customers in our large SPARC Solaris installed base will be upgrading to SPARC Superclusters".

IBM AIX  on Power 7 обладает где-то схожей технологией, которую называют intelligent threads, которая помещает потоки на незанятые ядра, достигая максимально возможной производительности. Я создал логический раздел с 4 ядрами в режиме SMT=4. Операционная система видит 16 логических процессоров. Далее я запустил 4 потока, каждый из которых загружает до 100% процессор.  Из картинки справа видно, что AIX увидев, что потоков у нас мало,  перешел в режим SMT=1 и поместил каждую из моих задача на свое физическое ядро (CPU 0-3 ядро 1, CPU 4-7 ядро 2, CPU 8-11 ядро 3, CPU 12-15 ядро 4). Вы можете попробовать этот тест на своей операционной системе -)

Ну все было бы хорошо и с выходом T4 не имело бы никакого смысла покупать СУБД Oracle на Power 7 ...но Oracle поднял цены на лицензии на T4 в два раза (processor core factor =0,5)  по сравнению с T3. Спасибо Ларри !   У меня все еще есть работа -)

4 комментария:

  1. Анонимный22/9/11 1:34 PM

    Добрый день.
    Если все правильно по считать а не бросаться фразами "поднял цены на лицензии на T4 в два раза" то получается все логично.
    В таблице core factors http://www.oracle.com/us/solutions/midsize/processor-core-factor-table-070634.pdf видно, что T2+ имели коэффициент 0.5 а T3 0.25. Я использую и тот и другой процессор что по лицензиям получается
    T3 = 64 core x 0.25= 16 лицензий
    T2 = 32 core x 0.5 = 16 лицензий
    T4 = 32 core x 0.5 = 16 лицензий
    В общем, ни чего не меняется.
    На IBM минимальный коэффициент 0.75, что гораздо дороже при таком же количестве ядер.
    Да и еще, я обещал поделиться впечатлениями об T3-4. Могу сказать, что видно сервер сильно переработан по сравнению с 5440, при той же нагрузке CPU Load снизилась с ~30% до 13, значительно улучшились показатели производительности одного потока, ввод/вывод стал менее затратным что привело к снижению очередей и по деньгам всего за 30 тыщь зелёных плюс пара FC дополнительных - это довольно выгодное вложение.... :)
    Удачи...
    Сергей.

    ОтветитьУдалить
  2. >а не бросаться фразами
    Я не хотел вас обидеть

    > На IBM минимальный коэффициент
    уже смело можно говорить что 1. Системы на основе Power 5 уже не поставляются

    Если сравнивать по кол-ву ядер IBM совершенно бесполезная вещь. Некоторых правда интересует производительность ядер и их возможности, но настоящим парням эти подробности ни к чему -)

    ОтветитьУдалить
  3. Анонимный22/9/11 3:30 PM

    Добрый день...
    Дя я и не обиделся, просто звучит немного пафосно про цену, прям как какой-то продажник "выдаёт на гора".
    Ну честно, не очень понятно, что дают "мощные" процессоры при малом их количестве. Я, конечно, не работал в Oracle и у меня не настолько глубокие знания "внутренностей" Oracle DB. Но насколько я помню, количество бакетов рассчитывается из количества процессоров а не из мощности, т.е. если при одинаковой нагрузке в 2500-3500 tps и одинаковом размере БД, точней количества используемых блоков, распределение по латчам при cpu_count 512 и 64 будет настолько разительным, что позволит большему количеству сессий делать одно и тоже. В итоге получается пропускная способность выше за счет большего распараллеливания. Кстати, с этим эффектом я сам столкнулся при переход от SPARC IV+ на Т2+. На IV+ при высокой нагрузке БД могла свалиться на каких-то латчах(конечно идет речь про db cache chains ).
    Да, есть, наверно, задачи требовательные к процессору, но в моей ситуации, OLTP Database, количество их более значимо чем мощность.
    Ну надеюсь, это изречение не спровоцирует flame и все останутся при своих мнениях. :)
    Удачи....
    Сергей.

    ОтветитьУдалить
  4. Сергей,

    У большого количества процессоров есть одна неприятная особенность - с их ростом увеличиваются накладные расходы на поддержание блокировок (латчи).

    На тему латчей очень хороший обзор написал Андрей Николаев http://andreynikolaev.wordpress.com/2009/10/04/general-spin-lock/ , там же есть ссылка на оригинальную статью Thomas E. Anderson.

    Конечно, тема весьма неоднозна.

    1. Зависимость накладных расходов от количества процессоров нелинейная

    2. Латчей далеко не 1. В XE 11g2 я насчитал 551 штуку. Это только parent. Естественно, многие из них обычными процессами не используются, но все равно - конкуренция возникает не всегда.

    3. Нагрузка на БД непостоянна. Иногда очень важно, чтобы именно в "пики" все было хорошо.

    Тем не менее, общая закономерность: с увеличением количества процессоров растут накладные расходы, справедлива. И в этой связи мне кажется правильной вот какая мысль - при прочих равных (одинаковой CPU Utilization в пики) лучше ставить более быстрые процессоры. Тогда в остальные моменты времени запросы будут выполнятся быстрее.

    ОтветитьУдалить