Извините, но слов из песни (в данном случае Шнура) не выкинешь. Сейчас поясню на конкретном примере. Когда приходят к заказчику и говорят - смотри какая у
, да мы тебе еще и скидку на лицензии дадим - если кто против, то я только за ( (С) Шнур опять таки). Но заказчик пошел очень умный. И говорит - а вот если без вашей зверюшки, сколько мне понадобится ядер ? И вот тут начинается
сплошная техническая ошибка.
Конкретный пример - документ, написанный для очень уважаемого заказчика очень уважаемым партнером. Уважаемый партнер берет 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 плохой ? Нет конечно, изначальная идея его была что его собирают на железе, которой ничего не стоит и тогда он оказывается выгоднее, чем один большой ящик. Просто на основе отличных технологий сейчас занимаются какими то разводками -)
Сообщения
