Соответствует ли производительность процессора серверу баз данных?


33

Это чисто теоретический вопрос. Допустим, у меня есть приложение, развернутое на нескольких серверах.

  1. Балансировщик нагрузки,
  2. Несколько / масштабируемые серверы приложений
  3. (Один) сервер базы данных (на данный момент)

В двух первых частях я знаю, что искать. Но как насчет сервера базы данных? Какое оборудование я должен искать?

  • Соответствует ли частота процессора серверу баз данных?
  • Актуальны ли многоядерные процессоры?
  • ОЗУ важнее ЦП?

PS: Предположим, выбранная база данных - MySQL или PostgreSQL.


Ну, он должен быть.
ConcernedOfTunbridgeWells

Ответы:


29

Для PostgreSQL мощность процессора может быть очень важной, особенно если довольно большой процент активного рабочего набора ваших данных помещается в ОЗУ. Большинство баз данных, с которыми я работал, большую часть времени работали с центральным процессором. (Я только что проверил vmstat на сервере, на котором размещаются веб-сайты с миллионами посещений в день, на которых размещается более 5 ТБ пространства базы данных, и я никогда не видел более 2% времени ожидания на диске, но видел пик 12% времени ЦП пользователя.)

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

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

Для получения более подробной информации по этой теме, касающейся PostgreSQL, я не думаю, что есть лучший источник, чем PostgreSQL 9.0 High Performance от Грега Смита . (Полное раскрытие, я был техническим рецензентом для книги, но не получил никакой финансовой выгоды от продаж.)


Привет, у меня есть книга. Есть ли какая-то конкретная страница, раздел или глава, на которую вы ссылаетесь ??? (BTW +1 для перспективы PostgreSQL)
RolandoMySQLDBA

Спасибо за информацию о PostgreSQL. Я проверю книгу. ;)
Zenklys

1
Хорошие вещи со страниц 21-23
RolandoMySQLDBA

Я вижу мудрость вашего второго абзаца по сравнению со страницами 21-23.
RolandoMySQLDBA

23

Строго говоря, с точки зрения MySQL, это очень загруженный вопрос

Частота процессора актуальна для сервера базы данных?

В то время как более быстрый процессор и материнская плата хороши, другие узкие места могут помешать. К таким узким местам относятся:

  • Дисковый ввод / вывод
  • Максимум подключения
  • Сетевая задержка
  • Производительность запроса на соединение

Каждое небольшое преимущество помогает, но я должен сказать « нет», потому что скорость процессора сама по себе не улучшается в вышеупомянутых узких местах. В конце концов, что хорошего может сделать гоночный автомобиль Формулы-1 в открытом парашюте или с гориллой за 800 фунтов за рулем?

Актуальны ли многоядерные процессоры?

Это полностью зависит от того, какую версию MySQL вы используете. MySQL 5.1 InnoDB Plugin, MySQL 5.5 и XtraDB Percona Server - все имеют настройки, которые вы ДОЛЖНЫ НАСТРОИТЬ, чтобы InnoDB получил доступ ко всем ядрам. Настоящим стимулом для этого является тот факт, что некоторые старые версии MySQL LEFT UNCONFIGURED работают быстрее, чем более новые версии, как я обсуждал в своих прошлых статьях:

Поэтому, если вы не хотите настраивать InnoDB для доступа ко всем процессорам, наличие нескольких ядер абсолютно ничего не покупает .

ОЗУ важнее ЦП?

О да, действительно. Конфигурация памяти для MySQL влечет за собой настройку

Запрос слишком мало или слишком много любой комбинации этих вещей и MySQL возвращаются, чтобы укусить вас. Более быстрый процессор с неправильно настроенной для оперативной памяти MySQL просто заставляет MySQL кусать вас быстрее.


2
Отличный ответ. Я собираюсь проверить все эти ссылки, спасибо.
Zenklys

6
  • нет
  • нет
  • да

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

Выбор 4 или 6 ядер или 2,5 ГГц против 3 ГГц не очень актуален (я полагаю, вам не нужно выбирать между P3-450 с 32 ГБ ОЗУ или последней Xeon с 1 ГБ ОЗУ).

Если вы связаны с процессором, у вас есть другие проблемы (плохой дизайн, плохие индексы, перестановка, невыделенный сервер и т. Д.)


Спасибо за ответ. SSD - хороший выбор тогда? Из-за мощности процессора?
Zenklys

@Zenklys: сложно сказать. Какой размер базы данных у вас есть? Написать объем? Читать нагрузку? OLTP или OLAP? и т.д
gbn

Максимум 20-30 гб. Отношение чтения / записи 10 к 1, только небольшие данные, OLTP.
Zenklys

2
@Zenklys: В этом случае это не имеет значения. Просто купите ОЗУ специально для MySQL, чтобы кэшировать как можно больше данных
gbn

3
Не уверен, почему это принятый ответ. Это упрощенно, поскольку не учитывает приложение, рабочую нагрузку или размер набора данных. @kgrittn дал лучший ответ, основанный на реальном опыте, и лучшее понимание теории работы для Postgres.
dbenhur
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.