В настоящее время я изучаю создание новой инфраструктуры для моего хостингового проекта. В основном это будет управляемый хостинг с упором на приложения на основе Django. Конечно, все будет на базе Linux с PostgreSQL в качестве БД и либо nginx, либо Apache в качестве веб-сервера вместе с GUnicorn и т. Д.
Сейчас я изучаю рынок серверных систем в аренду, и мне сложно найти вещи, которые соответствуют бюджету и всем критериям. Поэтому я хотел бы спросить совета по следующему.
Все хорошие предложения, которые я мог найти, используют либо одиночный high-end XEON E3-12xx (Quads @> = 3,2 ГГц), либо многоядерные Opteron (6000 или более ранние версии с 8 ядрами или более @ 2,00 - 2,40 ГГц). Из точки ввода-вывода у обоих обычно есть HW-RAID10 с батареей, достаточно оперативной памяти для удовлетворения моих потребностей (24-32 ГиБ ECC-RAM) и восходящий канал 1 Гбит / с. Одно предложение, которое я нашел, также довольно хорошее, но оно основано на двух E5620 XEON, которые, по моему мнению, довольно устарели, и эта система предлагается по той же цене, что и другие.
Теперь я разрываюсь. XEON превосходят Opteron во всех синтетических тестах, которые я видел, с упором на синтетические. Но я твердо убежден, что многие ядра действительно предлагают большие преимущества, когда дело доходит до работы сервера, где гораздо больше нужно делать параллельно (например, также менее затратное переключение контекста). Но с разницей в 1 ГГц или более на ядро я больше не уверен в этом, потому что в моем случае я сравниваю разные микроархитектуры (XEON и Opteron), а также разные поколения.
Поэтому я хотел бы спросить сообщество: больше ядер при более низкой скорости или меньше ядер при более высокой скорости для веб-сервера, ориентированного на приложения, который также должен обрабатывать нагрузку на БД?
Почтовая система - отдельная история. В идеале я хотел бы иметь почту, БД и Интернет на трех разных серверах. Но сейчас этого нет в бюджете. Итак, в зависимости от того, какую систему я получу для веб-сервера, вполне возможно, что почтовая система тоже может оказаться в этой системе ... что, я знаю, было бы неоптимальным. Меня беспокоит, насколько все мелкие записи из почтовой системы повлияют на производительность БД и Web. Например, при 32 ГиБ ОЗУ БД полностью поместится в ОЗУ в ближайшем будущем, пока объем услуг не вырастет значительно (если вообще когда-либо).
Один возможный (более или менее оптимальный) сценарий: Web и DB на 8-ядерном Opteron 62xx @ 2 Ghz box (все остальное, как указано выше) и почтовая система, например, на E3-1230 меньшего размера. Но меня снова очень беспокоит производительность Opteron. :(
Трудное решение. Опять же, я был бы признателен за любой совет / помощь, которую мог бы получить.
Заранее большое спасибо...
ОБНОВЛЕНИЕ (11.08.11 в 1518 по Гринвичу): В основном я сравниваю Sandy Bridge E3-12x0 XEON с Magny-Cours / Zurich / Interlagos Opterons. К сожалению, я не могу достать выделенный сервер на базе Ivy Bridge. Судя по тестам apache и результатам cpubenchmark.net, E3-1270v1 кажется настоящей рабочей лошадкой, которая превосходит даже двойной E5620 и большинство оптеронов, которые на него бросают, что отчасти невероятно. Естественно, что большинство этих тестов все еще синтетические, и есть другие узкие места, которые следует учитывать. Но на этом этапе я хочу заложить прочный фундамент на будущее, чтобы не зависеть от процессора.
Моя интуиция всегда заключалась в большем количестве ядер и / или процессоров для сервера web / db вместо более высокой тактовой частоты за счет количества ядер / процессоров. Так что, например, смотреть на установку 4C с E3-1270 кажется неправильным.
Кстати, хостинг - это продукт, который я предлагаю своим клиентам, так что это не единственный продукт, который я могу протестировать. По сути, это почти всегда будут приложения на основе Django, в основном системы CMS с настраиваемыми функциями или настраиваемые проекты.
Сейчас я действительно рассматриваю хорошую систему E3-1270 как комбинированный Web- и DB-сервер и E3-1220 как почтовую систему. И с быстрыми RAID, и с большим количеством оперативной памяти, естественно. Я все еще довольно обеспокоен тем, что настоящая 4C вскоре создаст проблемы в производственной среде. :( Но если я получу систему на базе Opteron 6274, мне придется запустить почтовую систему на этой системе, что не очень хорошо. И кроме того, согласно cpubenchmark.net, это не намного быстрее ... но снова: синтетический тест. :(
В основном то, что я спрашиваю: будет ли, например, Opteron 6274 или 2x 6128 превзойдут E3-1270 в реальных условиях, или E3-1270 все равно победит? Верное ли решение для прочного фундамента?
Опять же, если у кого-то есть хорошие предложения и / или советы для меня, я буду очень признателен, потому что сейчас я застрял в петле обратной связи в моем мозгу. :)
ОБНОВЛЕНИЕ (12.08.11 в 1835 по Гринвичу) Спасибо всем за помощь. Прямо сейчас я исследую совершенно другой подход: размещаю проекты моего клиента и тому подобное на Heroku или Google AppEngine и, таким образом, заранее избегаю большинства этих проблем. ;) Для почтовой системы вполне достаточно E3-12x0, так что я бы избавил себя от всей головной боли с комбинированным сервером web / app / db, который, в конце концов, не будет очень масштабируемым. Мне нужно будет провести дальнейшее расследование, если это возможно без каких-либо серьезных ограничений ... но я надеюсь. :)
Это сложная тема, но не забывайте здесь еще об одном элементе - вы также сравниваете оборудование разных поколений. Это не ТОЛЬКО чистое сравнение GHZ, вы можете очень хорошо сравнить устаревшие оптероны (только 8 ядер? - это 2x4, это ОЧЕНЬ медленное ядро по сравнению с сегодняшними) с Xeon уровня Sandy Bridge / Ivy Bridge. Я бы выбрал Xeon, просто из-за проблем поколений.
(И да, у меня то же самое - 1 четырехъядерный современный xeon И двойной оптерон с 2 сокетами по 4 ядра, а общая производительность xeon убивает большую машину, которая скоро будет перепрофилирована только как система SAN.
В вашем вопросе гораздо больше, чем просто ядра и производительность.
Вы можете быть слишком обеспокоены, если не ожидаете слишком большого трафика. Если вы хотите разместить все свои приложения на одном сервере, вы рискуете полностью выйти из строя из-за проблем с оборудованием. Посмотрите, сможете ли вы использовать машины в 2 раза ниже и распределить нагрузку. Для повышения производительности вы можете выделить ядра для процесса PostgreSQL с помощью набора задач, чтобы производительность БД была управляемой.
Если вы хорошо управляете своими дисками, вы также можете получить лучшую производительность. Например, установите 2 диска в RAID 1 для pg_xlog.
Длинный ответ: протестируйте свое приложение и подумайте об избыточности, если вы не можете позволить себе простой. Также сравните затраты с облачными решениями, которые помогут, если ваше приложение сможет масштабироваться.
Больше ядер позволит вам обрабатывать большее количество клиентов с меньшим количеством переключений контекста, что теоретически может компенсировать разницу в тактовой частоте. Обратной стороной является то, что в периоды низкой загрузки система работает менее эффективно.
Не увеличивайте, масштабируйте!
Как я понимаю из вашего вопроса, вы ожидаете большой нагрузки, например. попадает на ваш веб-сервер. Поскольку у вас может не быть подробной информации о том, что на самом деле размещено, статический или динамический контент, а если динамический, какая технология используется, java, C #, Python или G * запретите PHP, в данный момент невозможно придумать решение, кроме этого, оно должно масштабироваться.
Мое предложение? используйте LB-кластер с относительно дешевым оборудованием, которое можно при необходимости расширить. Не помещайте все на одну машину, если масштабирование слишком велико (дорого) или недостаточно (снижение производительности). Но позвольте себе начать с малого и расти по мере роста трафика.
Итак, на самом деле балансировка нагрузки - это ответ, который вы ищете.