Вот сценарий, по которому я хотел бы получить ваш экспертный совет:
Сейчас у меня около 2 ГБ базы данных, может быть, вдвое больше за год. Мне нужна оптимальная производительность для выделенного сервера БД, который я собираюсь заказать, который будет использоваться в качестве бэкэнда для сайта с довольно интенсивным трафиком, на котором работают WordPress, форум и mediawiki. Большая часть трафика базы данных должна быть доступна только для чтения.
Итак, вопрос в том, действительно ли мне нужно более 4 ГБ оперативной памяти? И я должен выбрать 8 ядер или только 4? Один важнее другого?
[править] Как продолжение, в итоге мы получили хорошую сделку на 8-ядерном сервере с 8 ГБ ОЗУ, так что пошли с этим. Рад знать, что у меня будет много возможностей для роста.
Как утверждает nikb, важно понимать ваше приложение, но вместо этого я бы предложил следующее практическое правило.
Если только часть вашей БД не читается или не записывается в обычном порядке, то никакое количество дополнительных ядер не будет соответствовать преимуществам производительности от наличия всех ваших БД и вспомогательных данных (индексов и т. Д.) В памяти. Дополнительные ядра пригодятся, если у вас есть лоты одновременных клиентов, обращающихся к вам, или вы выполняете много фоновой работы, такой как отчетность или индексация.
Если бы я был на вашем месте, я бы выбрал сравнительно недавний двухпроцессорный сервер на базе Intel серии 55xx и просто купил бы один 4-ядерный гиперпотоковый процессор с 3 модулями памяти DDR по 4 ГБ (не позволяйте никому продавать вам 2/4 / 8 и т. Д., Использование 55xx 3,6,9 и т. Д. Нормально). Таким образом, вы не только сможете очень быстро и легко добавить второй идентичный процессор в будущем, но и поскольку эти чипы совместимы с будущими 8-ядерными чипами, вы всегда сможете просто заменить тот, который у вас изначально есть.
Надеюсь, это поможет.
интересный вопрос. Пожалуйста, сначала попробуйте определить узкое место вашего текущего приложения. Из вашего описания и некоторых практических знаний я могу предположить, что у вас есть четыре возможных узких места:
Теперь ram не будет проблемой, потому что, поскольку ваш db составляет всего 2G, вы можете буферизовать не только все ключи и индайсы, но фактически весь db в ram, имеющий 2G, если вы соответственно измените размер (MyISAM-) key_buffer и / или innodb_buffer_pool_cache ! Возможно, вам будет хорошо даже с ram <dbsize, потому что обычно не все части db используются одновременно (ymmv).
Конечно, ram также используется для таблиц памяти, сортировки и упорядочивания, а также для некоторых операций соединения, поэтому вам следует посмотреть на сложность запросов, которые делает ваша база данных, и на то, возвращает ли она очень большие наборы результатов. Я не знаю, но я считаю, что ни wordpress, ни mediawiki не выполняют здесь действительно сложных операций. Так что просто возьмите умеренное количество барана.
HD - обычное узкое место для любой большой базы данных, но ваша в любом случае может быть кэширована в оперативной памяти, и вы говорите, что в основном выполняете операции чтения, поэтому я бы сказал: для обычной большой базы данных практическое правило будет: пропускная способность hd является основным узким местом, поэтому: 1. покупайте жесткие диски и 2. не обязательно покупать самые быстрые, но покупайте их много. В вашем случае я бы сказал: все равно все кешируется.
Что касается ядер: MySQL действительно может использовать преимущества многих ядер, но в основном они нужны ему для сложных вычислений, процедурных программ и операций сортировки и слияния. Однократные запросы, такие как «Выбрать * из таблицы» или даже «Выбрать * из таблицы, где ...», не принесут особой выгоды от большего количества ядер. Многие соединения получат незначительную выгоду. Я предполагаю, что вам следует предпочесть более быстрый процессор большому количеству ядер.
Я считаю, что вы должны проверить ник как основное узкое место и подумать о втором (третьем, четвертом ...) нике, в зависимости от объема трафика на вашем основном интерфейсе.
Итак, чтобы подвести итог, я бы потратил свои деньги (в таком порядке): - более чем на один ник (если это действительно узкое место) - быстрый процессор - 2-4 ядра - 2-4 ГБ оперативной памяти с возможность подключить 8G позже (в любом случае дешевле, чем ядра) - лучшая возможная дисковая подсистема (сейчас вам не нужно много, но это поможет вам расширить позже)
Ура, Ник.
Предложение Никба звучит. Еще одна область для рассмотрения:
Какой объем оперативной памяти (или ядер ЦП, или дисковых систем) может получить доступ к экземпляру вашего приложения / архитектуры приложения?
Я видел ситуацию, когда приложение на четырехъядерном сервере с 14 ГБ ОЗУ выполнялось очень медленно, несмотря на то, что загрузка ЦП была менее 25%, а использование ОЗУ было низким. Оказалось, что движок приложения может получить доступ только к 1,5 ГБ ОЗУ. Экземпляр приложения был исчерпан, хотя машина была затронута незначительно.