Соображения при выборе процессоров AMD вместо Intel


13

Я работаю в компании с большим количеством устаревших веб-приложений LAMP, где мы пытаемся обновить наше оборудование с ~ 250 физических серверов до ~ 40 новых серверов с виртуализацией. Мы получили две цитаты от поставщиков: одна предлагает процессоры Intel, другая AMD.

Одна вещь, которая мне нравится в связи с большим количеством ядер в AMD, заключается в том, что мы сможем выделять ядра для виртуальных машин, что означает, что у нас меньше шансов на то, что приложения будут взаимодействовать друг с другом из-за скачков, которые в определенной степени больше Для меня важнее, чем пиковая производительность.

Другие соображения, которые я имею в виду:

  • Потребляемая мощность может быть разной (в нашем случае это не проблема).
  • Инструкции CPU, такие как CRC32 (SSE 4.2), не поддерживаются (Редактирование: MySQL 5.6, кажется, поддерживает SSE4.2. Не уверен насчет Apache)
  • MySQL не масштабируется идеально после ~ 16 / ~ 32 ядер (я готов принять этот компромисс).

Какие еще соображения мне не хватает?

(Примечание для модераторов: мне известна эта тема - я считаю вопрос немного другим.)


Изменить: Предположим, что задачи являются исключительно параллельными (веб-серверы), и что меня не волнует, что серверы баз данных не являются такими параллельными.


Вы можете найти это интересным: it20.info/2007/10/intel-amd-vmware-and-aircrafts
ToastMan

Если ваше приложение может разделить запросы на чтение / запись для разных пулов серверов, вы можете обойти некоторые проблемы с производительностью MySQL, запустив второй экземпляр для ведомого чтения. Я не знаю достаточно о вашей архитектуре или рабочей нагрузке, чтобы понять, является ли это работоспособной идеей или это просто добавит массу ненужных накладных расходов и сложности, но это вариант, который стоит рассмотреть.
jgoldschrafe

Я знаком с тем, как работает разделение чтения / записи. Это не подходит для увеличения производительности в этом случае.
Морган Токер

Ответы:


10

Было много прессы о новейшем предложении процессоров AMD под названием Bulldozer. «Серверная» версия этой части еще не выпущена, но предложение для настольных компьютеров - отличный обзор некоторых потенциальных проблем новинки.

Что касается текущего поколения серверной части, то в целом рекомендации довольно хороши на общем уровне. Веб-обслуживание и (большая часть) работа с базами данных в основном основаны на целочисленных значениях, а процессоры AMD хорошо справляются с вычислениями на целочисленных значениях. Кроме того, веб-обслуживание (как правило) является проблемой, которая может быть сильно распараллелена. AMD уделяет особое внимание тому, что «многие ядра обеспечивают более быструю работу», и LAMP (опять же, в общем) имеет тенденцию хорошо реагировать на это.

Одна область, на которую вы действительно должны обратить внимание - это однопоточные зависимости в ваших приложениях. Части AMD масштабируются не так сильно по часовой стрелке, как детали Intel, поэтому процессы, которые по своей сути являются однопоточными, могут затормозить всю систему в целом намного быстрее, чем на более быстрых частях ЦП. Только вы знаете, относится ли это к вам или нет. Определенные операции с базами данных могут лучше обслуживаться более быстрыми процессорами Intel с меньшим числом ядер, так что эти несколько толстых потоков могут действительно кричать.

Код приложения здесь тоже имеет значение. Некоторые длительно работающие процессы веб-сервера могут потреблять много однопотокового времени, а также требуют более быстрых часов. Это может быть решено путем переписывания необходимости в этом длительном процессе, но до этого было бы неплохо использовать более быстрые часы.

Но в целом, для рабочих нагрузок в стиле lot-o-webserver-vm эти 12-ядерные компоненты могут масштабироваться довольно далеко. Если вы столкнетесь с какими-то однопоточными проблемами, переход на 8-ядерные компоненты с более высокой тактовой частотой будет приемлемым компромиссом.


Спасибо, к сожалению, система AMD не будет бульдозером. Это AMD Opteron 6140 (или аналогичный).
Морган Токер

@MorganTocker Как оказалось, я знаком с этим классом процессоров, и для этого я написал свой пост. У бульдозера есть некоторые специфические проблемы, с которыми я не сталкивался.
sysadmin1138

4

По большей части вы обнаружите, что оба процессора очень сопоставимы. Процессоры AMD имеют небольшое преимущество в скорости ОЗУ (обычно) из-за 4-го канала. Процессоры Intel обычно имеют более низкий CPI (возможно, в большей степени это касается HT , хотя это очень сильно зависит от рабочей нагрузки). AMD, как правило, дешевле.

Большинство из этих факторов даст преимущество одному или другому, в зависимости от вашей рабочей нагрузки. Ни один из них не будет значительно хуже, чем другие (при условии нормальных конфигураций и примерно равных капитальных затрат).


2

Вы должны учитывать различия в производительности, которые может принести отличающаяся архитектура ОЗУ, и является ли это решающим фактором для вашей организации.

Также в качестве небольшого примечания, хотя вы можете не беспокоиться о пиковой производительности, если ваша виртуальная машина не будет иметь несколько ядер каждое и / или конкретные задачи внутри являются однопоточными, существует значительное преимущество в производительности для целых чисел. ядро, чем AMD, даже если общее количество ядер меньше.


Предположим, что наши приложения являются подходящими многопоточными (веб-серверы; готовы признать, что MySQL не полностью).
Морган Токер

2

Основное отличие заключается в подходе; В среднем диапазоне AMD уделяет небольшое внимание ядрам в части, которая стоит примерно столько же, сколько аналогичная часть Intel. У части Intel будет меньше тактовых частот выше.

Таким образом, для виртуализированных рабочих нагрузок веб-приложений вы, вероятно, предпочтете системы AMD.

Если не будет большой разницы в цене, я не буду беспокоиться о долларах. Я бы посмотрел больше на подсистему ввода-вывода. Кроме того, общая стоимость владения на 40 серверах будет зависеть от поддержки, лицензирования программного обеспечения, если таковое имеется, и от персонала, вероятно, не от самих серверов.

Как минимум, вам нужно сделать себе одолжение, привлечь обоих поставщиков и запустить свои системы на их оборудовании, прежде чем выделять 40 серверов с одного из них. Только вы можете ответить на вопрос правильно для вашей конкретной рабочей нагрузки.


Спасибо за ваш ответ! У нас нет одной рабочей нагрузки - у нас есть несколько. Таким образом, чтобы привлечь поставщика, нам нужно полностью перенастроить, а затем снова перенастроить, чтобы попробовать оба варианта. Я понимаю, что это оптимально, это просто не практично в нашем случае. Мы можем выбрать меньшее количество ролей для перемещения и проецирования, но для этого нам нужно знать, что мы должны измерять / отслеживать; отсюда мой вопрос;)
Морган Токер

Под рабочей нагрузкой я имею в виду одну ОБЩУЮ рабочую нагрузку, состоящую из (предположительно) множества разных серверов, выполняющих разные задачи. В настоящее время вы сможете довольно легко преобразовать подмножество ключевых серверов в виртуальные образы (с помощью программного обеспечения, которое может помочь в этом), которое можно загрузить на серверы, которые вы собираетесь приобрести. Не пренебрежимая задача, но единственный способ убедиться, что не только процессор, но и подсистема ввода-вывода и все остальное работает в вашу пользу. В противном случае, все отказываются от рук и догадываются. :)
alphadogg

1

Еще одна вещь, о которой стоит упомянуть, будьте осторожны, если вы используете виртуализацию любого типа, при которой перенос гостей с Intel на AMD может быть реальной проблемой, а кластеризация по брендам вообще не включена в карты. Придерживайтесь одной платформы для каждого кластера и признайте, что трудно перепрыгнуть с одной на другую.


Живая миграция между архитектурами с KVM появляется в значительной степени будет не проблема на 64-битном: linux-kvm.org/page/...
Ophidian

Пользователь сказал "устаревшая ЛАМПА"; это пахнет, как будто для меня могут быть 32-битные гости. Тем не менее, приятно знать, что KVM справляется с этой проблемой! Спасибо за примечание.
Марк

Да, некоторые гости 32-битные, но мы планируем переехать и все 64-битные.
Морган Токер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.