какая то разводка ...

Извините, но слов из песни (в данном случае Шнура) не выкинешь. Сейчас поясню на конкретном примере. Когда приходят к заказчику и говорят - смотри какая у нас зверюшка, да мы тебе еще и скидку на лицензии дадим - если кто против, то я только за ( (С) Шнур опять таки). Но заказчик пошел очень умный. И говорит  - а вот если без вашей зверюшки,  сколько мне понадобится ядер ?  И вот тут начинается какая то разводка  сплошная техническая ошибка.

Конкретный пример - документ,  написанный для очень уважаемого заказчика очень уважаемым партнером. Уважаемый партнер берет Exadata Half Rack  в котором как мы знаем стоит 48 Intel Cores и ..немедленно к ним добавляет  еще ядра на ячейках - и говорит заказчику - смотри, сколько нам нужно ядер без Exadata !  Я когда документ  увидел, сразу вспомнил что с такой логикой уже где то встречался. А вот где:

">Во-первых в Exadata Half Rack не 48, а 132 ядра. (84 на ячейках)"  см комментарии к этому посту.

Я тогда подумал, что это шутка такая, складывать ядра в storage с ядрами для СУБД, чтобы унять так сказать сотрудника IBM -), но увидев это в документе для заказчика, понял, что в это действительно кто-то верит.

Правда заключается в том, что ядра в ячейках не обрабатывают sql запросы, не умеют их разбирать. Ядра в ячейках занимаются вводом-выводом, иногда компрессией-декомпрессией - но не sql запросами.

Наверно не все знают, что в современных дисковых массивах не гнушаются ставить те же самые Intel процессоры.  См например картинку слева - это контроллер дискового массива Storwise (производства IBM). Там установлен процессор Intel Jasper Forest. Кому нибудь приходило в голову складывать его Intel ядра при сайзинге ? Пока, к счастью нет. Предчувствую  радостные крики, что благодаря sql offload и компрессии меньше приходится работать центральным процессорам. Вполне вероятно, вопрос в том насколько нам это поможет -)



Возмем, для определенности, банковскую систему. Пик ее работы по CPU (а значит и запас на который нам нужно рассчитать ядра) приходится на день, когда все операционисты заняты вводом  платежей. Кэш базы данных максимально разогрет, все данные там, работаю только процессоры работающие на стороне СУБД. Процент ожидания ввода-вывода минимален.  По большому счету мне все равно что у меня на storage - у меня не хватает CPU на парсинг, логические чтения, блокировки.   Я привел график загрузки CPU одного из заказчиков - вы можете легко увидеть, что пик загрузки совпадает с минимум ожиданий по I/O.  Увы - ядра в storage, каим бы он не бы умным,  ничем не помогают в пике работы реального приложения. Возможно повторю всем известную истину, что расчет по CPU для любой системы делается для ее пиковой нагрузки, в прочее время нагрузка на CPU никого не интересует, в конце концов уплачено, и пусть они работают.


Вы думаете, это все что я хотел сказать ?  Нет - не дождетесь. Коллеги, которые так рьяно складывают ядра из разных частей своей системы совершенно упустили из виду,  что в Exadata стоит RAC.   Мелочь какая. В рассматриваемой нами Exadata Half Rack 4 узла кластера. Те кто ходил на семинары RAC Deep Dive for Developers знают, что масштабирование в кластере зависит от числа узлов. Для двух узлов коэффициент от 1.3 до 1.7, для 4- х узлов - в районе 3. В среднем по больнице.  Это значит, чтобы достичь такой же производительности как в single instance на 36 Cores в RAC  в 4-х узлах нужно взять 48.   Известное мне исключение из этого правила  - это SAP, приложение которое масштабируется практически линейно.  К сожалению это еще не все. 48 Cores нельзя в 4-х узловом кластере держать в загрузке 100% - во первых потому что кластер будет перегружаться, во вторых если один из узлов выйдет из строя, кто-то должен взять на себя его нагрузку. Итого, эффективная загрузка 48 Cores может быть только 75%.  Итого, пересчитываем, учитывая потери на RAC и максимальную возможную нагрузку - получаем 27 эффективных Cores для монолитной системы.  Или 54 потока.  Если вы вспомните я оценил коэффициент масштабирования в x3, возможно вам повезет и он будет выше, но оценка понятна.


Машина IBM Power 740  имеет 16 Cores на борту и 64 потока, а поэтому справится с пиковой нагрузкой так же эффективно как  Exadata Half Rack. Стоимости различаются на порядок.  Как же быть со storage ? В следующем посте я покажу вам storage c 800K IOPS подключенный к к Power 740 бесплатным бонусом вам пойдет виртуализация, которой просто нет в Exadata.

Exadata плохая ? Вовсе нет, в конце дня на ней можно будет очень быстро закрыть день, быстрее чем на обычном storage (за одним исключением).  Дорогое удовольствие правда получается, проще процедуру переписать если не устраивает.   RAC плохой ? Нет конечно, изначальная идея его была что его собирают на железе, которой ничего не стоит и тогда он оказывается выгоднее, чем один большой ящик.  Просто на основе отличных технологий сейчас занимаются какими то разводками -) 

14 комментариев:

  1. Анонимный8/5/12 3:17 AM

    ein:

    > Кэш базы данных максимально разогрет, все
    > данные там, работаю только процессоры
    > работающие на стороне СУБД.

    zwei:
    > Процент ожидания ввода-вывода минимален.

    визирую взаимоисключающие параграфы.

    > По большому счету мне все равно что у меня на
    > storage - у меня не хватает CPU на парсинг,
    > логические чтения, блокировки.

    третий взаимоисключающий [оба предыдущих] параграф так же завизирован, спасибо.

    не хватает на парсинг/logical reads/locking (latching?!!!) - оптимизация кода просится?

    > Если вы вспомните я оценил коэффициент
    > масштабирования в x3, возможно вам повезет и
    > он будет выше, но оценка понятна.

    оценка "хз" - ага, да, она вам, может, и понятна, а вот всем остальным...;-)

    ranger.

    ОтветитьУдалить
    Ответы
    1. Анонимный10/5/12 6:37 AM

      Ranger как обычно написал какую-то херню.

      Спасибо.

      Удалить
    2. Анонимный11/5/12 12:29 AM

      толсто, товарищ, очень толсто :) тоньше надо быть :)

      ranger.

      Удалить
  2. >визирую взаимоисключающие параграфы.

    Посмотри на график - там все нарисовано.

    >оценка "хз" - ага, да, она вам, может, и понятна, а вот всем остальным...;-)

    -)) xз = умножить на 3 в данном случае -))) = x 3

    ОтветитьУдалить
  3. Анонимный9/5/12 6:26 PM

    Dmitry,
    а можно получить такой же замечательный анализ,
    но взяв для примера не опер.день в период OLTP
    а чего-нить типа DWH в период отчетности ? ;)

    ОтветитьУдалить
  4. >а можно получить такой же замечательный анализ, ... а чего-нить типа DWH в период отчетности ?

    Так и сделайте, я с удовольствием поставлю ссылку. Проблема то в том, что мы говорим про машину баз данных, а не машину DWH. Баз данных. Вот я и взял базу данных. И даже заказчик есть который использует эту машину баз данных в банковской системе. Вот и посмотрим что скажет этот заказчик, прочитав данный анализ.

    >опер.день в период OLTP
    Вы считаете что по ночам у банков период OLTP ? операционистки набивают платежки, который не успели набить днем ? У меня врде бы график за сутки приведен.

    ОтветитьУдалить
  5. Анонимный10/5/12 6:43 AM

    Тут, ИМХО, следует заметить, что для DWH количество ядер на ячейках и серверах БД все же складывать нужно, т.к. там CPU стореджей задействованы активно, нагрузка очевидно перераспределяется.

    Что до OLTP - вполне согласен, попытка продавать Exadata для них - не более чем разводилово доверчивых клиентов на бабало, Exadata там как зайцу стоп-сигнал.

    ОтветитьУдалить
  6. >следует заметить, что для DWH количество ядер на ячейках и серверах БД все же складывать нужно, т.к. там CPU стореджей задействованы активно, нагрузка очевидно перераспределяется.

    Это кажущийся очевидным факт ...очень тяжело увидеть на практике. Это долгая дисскусия, но если коротко - да, действительно нагрузка уходит в cell, но в это время центральный процессоры database node стоят. Те из факта что нагрузка перемещается нельзя сделать вывод что мощности надо складывать. В пиковой нагрузки большинства систем идет одинаковая нагрузка, пусть например отчеты. Пусть они все ушли на cell. Идеальный случай. Но, тогда процессорам на стороне БД нечего делать, они жду завершения работы cell. Конвейерная обработка. Те даже для DWH нельзя складывать, но можно взять max (числа процессоров на cell, числа процессоров на database node). 84 лучше чем 48, это я согласен.

    Я знаю что последнее утверждение очень сложное, но это так. Опровергнуть можно только показав график загрузки за сутки где все процессоры (database node и cell node) загружены одинаково под 100%. Я опубликую его, пожалуйста.

    ОтветитьУдалить
  7. Дим, SQL offload умеют делать FPGA в Netezza. Это я так понимаю её фирменный соус

    ОтветитьУдалить
  8. Анонимный10/5/12 7:43 PM

    >но в это время центральный процессоры database node стоят.

    Ну почему же? Если создать достаточную нагрузку, то им тоже будет чем заняться. Они могут, например, обслуживать "короткие" запросы от других пользователей, не требующих ввода\вывода, а значит и обращения к cell. По сути, Exadata - это та же Netezza, идея та же самая: умный сторедж, берущий на себя часть нагрузки.
    Другое дело, что это все теории, на практике я такого не видел, подтвердить слова правда доказательствами не могу.
    Может местный горлопан ranger перейдет от слов к делам и продемонстрирует что-то практическое, кроме хамства и оскорблений?

    ОтветитьУдалить
    Ответы
    1. Анонимный11/5/12 12:44 AM

      > Может местный горлопан ranger перейдет от слов к делам и продемонстрирует что-то практическое,
      > кроме хамства и оскорблений?

      ололо, хотя тоже толстовато.

      я ничего не демонстрирую - я "решаю проблемы" (с). профиль деятельности у меня такой.

      фразы волкова про "но если коротко - да, действительно нагрузка уходит в cell, но в это время центральный процессоры database node стоят" и "Пусть они все ушли на cell. Идеальный случай. Но, тогда процессорам на стороне БД нечего делать, они жду завершения работы cell. Конвейерная обработка." - это, конечно же, совершеннейший бред, вызванный недостатком знаний в организме, и его я комментировать не буду - желающие гуглят по слову IPC и "oracle architecture" (кто умеет - изучает трейсы), а так же изучают ASH для упомянутого "идеального случая" чтобы увидеть, чем занимаются процессы. совсем упоротые могут скачать HP OVPA (так же известен как measureware, 30 дней бесплатно) для линукса, собрать нужные метрики, экспортнуть в текстовый формат, форматнуть вывод в формал sqlldr, грузануть в базу и заматчить его с ASH - откроется великая тайна :D

      ranger.

      ps. думать надо меньше, а соображать больше (с) брат2

      Удалить
    2. >Может местный горлопан ranger перейдет от слов к делам и продемонстрирует что-то практическое,
      > откроется великая тайна
      Жду чтобы ты проделал сам все что написал тут выше и выложил результат. В противно случае твои комментарии буду считать бессмысленными и более ненужными.

      Удалить
    3. Анонимный11/5/12 11:32 AM

      >> Может местный горлопан ranger перейдет от слов к делам и продемонстрирует что-то
      >> практическое, откроется великая тайна
      > Жду чтобы ты проделал сам все что написал тут выше и выложил результат. В противно случае
      > твои комментарии буду считать бессмысленными и более ненужными.

      нет, я этого делать не буду - по нескольким причинам:
      1) у меня хватает работы по поддержке заказчика (oracle+aix, кстати :))
      2) я не пресейл, и что-то кому-то доказывать - мне ни разу не интересно. хватит того, что я тебе методику подсказал - дальше разберешься чокаг.
      3) лично я ответ и так знаю, причем давно.

      ranger.

      Удалить
    4. >хватит того, что я тебе методику подсказал
      До свидания, ranger. Ничего личного, но болтовня с ссылками на дикую занятость уже достала. Я ни разу не видел от тебя ни одного графика, ни одного awr. Пришлешь результат работы своей методики на Exadata - welcome back.

      Удалить