Сеть - и сервер БД: Высокая тактовая частота и меньше ядер по сравнению с меньшей тактовой частотой и много ядер
В вашем вопросе гораздо больше, чем просто количество ядер и производительность.
- Сколько одновременных пользователей должен поддерживать ваш сервер?
- У вас один сервер и нет резервирования? Каково допустимое время простоя для вашего приложения?
- Выполняли ли вы какой-либо тест производительности вашей машины для разработки для этого приложения, чтобы в какой-то мере экстраполировать производительность?
Вы можете быть слишком обеспокоены, если не ожидаете слишком большого трафика. Если вы хотите разместить все свои приложения на одном сервере, вы рискуете полностью выйти из строя из-за проблем с оборудованием. Посмотрите, сможете ли вы использовать машины в 2 раза ниже и распределить нагрузку. Для повышения производительности вы можете выделить ядра для процесса PostgreSQL с помощью набора задач, чтобы производительность БД была управляемой.
Если вы хорошо управляете своими дисками, вы также можете получить лучшую производительность. Например, установите 2 диска в RAID 1 для pg_xlog.
Длинный ответ: протестируйте свое приложение и подумайте о избыточности, если вы не можете позволить себе простой. Также сравните затраты с облачными решениями, которые помогут, если ваше приложение сможет масштабироваться.
Это сложная тема, но не забывайте здесь еще об одном элементе - вы также сравниваете оборудование разных поколений. Это не ТОЛЬКО чистое сравнение GHZ, вы можете очень хорошо сравнить устаревшие оптероны (только 8 ядер? - это 2x4, это ОЧЕНЬ медленное ядро по сравнению с сегодняшними) с Xeon уровня Sandy Bridge / Ivy Bridge. Я бы выбрал Xeon, просто из соображений поколений.
(И да, у меня то же самое - 1 четырехъядерный современный xeon И двойной оптерон с 2 сокетами по 4 ядра, а общая производительность xeon убивает большую машина, которая скоро будет перепрофилирована только как система SAN.
Больше ядер позволит вам обрабатывать большее количество клиентов с меньшим количеством переключений контекста, что теоретически может компенсировать разницу в тактовой частоте. Обратной стороной является то, что в периоды низкой загрузки система работает менее эффективно.
Не масштабируйте, а масштабируйте!
Из вашего вопроса я понял, что вы ожидаете большой нагрузки, например, попаданий на ваш веб-сервер. Поскольку у вас может не быть подробной информации о том, что на самом деле размещено, статический или динамический контент, а если динамический, какая технология используется, java, C #, Python или G * запретите PHP, в данный момент невозможно придумать решение, кроме этого, оно должно масштабироваться.
Мое предложение? используйте LB-кластер с относительно дешевым оборудованием, которое можно при необходимости расширить. Не помещайте все на одну машину, если масштабирование слишком велико (дорого) или недостаточно масштабировано (снижение производительности). Но позвольте себе начать с малого и расти по мере роста трафика.
Итак, на самом деле, балансировка нагрузки - это ответ, который вы ищете.