Сервер базы данных: маленькая быстрая или большая медленная?

33

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

Это наши варианты: 48 ГБ 1333 МГц или 96 ГБ 1066 МГц.

Я думаю, что ОЗУ должно быть достаточно для сервера баз данных (у нас много и много данных, а также очень большие запросы), а не настолько быстро, насколько это возможно. По-видимому, мы не можем получить 16 ГБ чипов на 1333 МГц, поэтому выбор выше.

Итак, мы должны получить много медленной оперативной памяти или менее быстрой оперативной памяти?

Дополнительная информация:

Количество доступных слотов DIMM: 6
Серверов: ЦП Dell Blades: 6 ядер (только один сокет из-за лицензии Oracle).

database oracle memory Джош Смитон
источник
12
ИМО, объем ОЗУ на 100% больше, чем на 20%.
Джо Интернет
3
Тем более, что это даже не 20%;)
TomTom
Спасибо всем. Я тоже был в этом уверен, но хотел подтверждения.
Джош Смитон

Ответы:

59

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

штурмовик типа "Скайхки"
источник
Конечно, это зависит от размера базы данных - основных деталей, но все же важно.
Морг.
Да, и Джош четко указал, что рассматриваемый сценарий включает в себя «много и много данных».
Skyhawk
Для некоторых людей миллион строк выглядит как «много-много данных». Вряд ли это причина, по которой не все в памяти;)
Морг.
16

Хорошо, это очень очень очень просто:

Ваша база данных помещается в 48 ГБ ОЗУ с ОС и все? если да, возьми это. Остальное возьми 96гб

Кроме того, подгонка базы данных в xyz ГБ ОЗУ означает, что она соответствует индексам, представлениям и тому подобное.

Комментарии SSD - полная чушь, и пропускная способность, и время доступа не находятся на одном уровне, и ни один SSD не может оправдать использование меньшего количества ОЗУ.

Морг.
источник
5
Это очень важная информация. Если база данных составляет всего 5 ГБ и не планируется увеличивать ее объем, вы можете использовать меньший объем более быстрой ОЗУ.
Кибби
13

База данных только? В зависимости от базы данных, я думаю, больший объем ОЗУ будет лучше. Разница в скорости оказалась в лучшем случае незначительной, но дополнительные 48 Гб будут / могут иметь огромное значение.

TomTom
источник
11

Определенно большой объем оперативной памяти, скорость будь проклята.

Доступ к случайным данным по технологии оперативной памяти с XX века 90-х годов ниже 100 нс. При этом используются практически древние чипы, которые даже физически не вписываются во что-либо граничащее с современным.

Доступ к случайным данным для самых современных жестких дисков со скоростью 15 к / мин измеряется в миллисекундах. 100 нс в 10 000 раз короче (нано-> микро-> милли), чем 1 мс. Текущая оперативная память быстрее, а HDD требуется несколько миллисекунд для доступа к данным. Меня не волнует, будет ли моя оперативная память на 50 000 быстрее или только в 30 000 раз быстрее, чем жесткий диск, если я смогу получить больше.

Павел Бродацкий
источник
5

Вы должны обратить ваше внимание на некоторые моменты:

  • Лантиси памяти памяти Скорость памяти зависит от двух факторов: скорости шины и задержки. Обычно чипы с большей плотностью приводят к более высокой задержке, что в конечном итоге означает меньшую скорость
  • Итоговые данные индекса Наиболее важная y для загрузки всех данных индекса в память. Индексные данные - это наиболее важные данные, которые вам нужны в памяти (более высокий штрафной эффект в производительности).
  • Скорость диска У вас есть данные БД, хранящиеся в SSD? Если ответ «да», позаботьтесь о задержке памяти.
Нефели
источник
2

ПАМЯТЬ ПАМЯТИ = / = СКОРОСТЬ!

Вероятно, наиболее важной частью недостающей информации является время памяти и тип CPU / FSB. уменьшите задержку загрузки памяти процессора на несколько циклов, и в некоторых вычислениях вы увеличите пропускную способность вдвое. Некоторые базы данных не используют огромное количество оперативной памяти из-за операционной системы и технических причин, какой сервер базы данных вы используете? Тип процессора? L [123] уровни кэша? тип запросов для запуска? размер базы данных?

Silverfire
источник
2
-1. Фактически неправильно в 99,9% случаев.
TomTom
Какую часть вы имеете в виду?
Silverfire
2
Любая база данных больше памяти замедляется немедленно. Циклы процессора - шутка по сравнению с - если это не очень особый случай OLAP - введенная задержка ввода-вывода. Большинство баз данных используют огромное количество оперативной памяти - самый маленький SERVER базы данных, который я видел, это не шутка для крошечной базы данных, которая во много раз больше использует оперативную память, чем средняя рабочая станция. Если вы не настаиваете на использовании крайне устаревшей технологии («системные ограничения ОС»). И ни скорость процессора, ни тип fsb не имеют значения - базы данных нуждаются в памяти.
TomTom
0

Прежде чем тратить слишком много денег на неправильное оборудование, я бы сделал несколько тестов и анализов, прежде чем покупать оборудование.

  • Прежде всего, подумайте о своем SLA.
  • какие-либо жесткие требования к производительности и времени отклика?

Ваш выбор должен зависеть от многих факторов:

  • Что является узким местом при различных нагрузках и использовании?
  • Процессор, память, память, сеть?
  • Может быть, важнее потратить больше денег на более быстрое хранение, чем больше памяти?

  • быстрее процессора, чем больше памяти? быстрее сети? незначительный редизайн на software / sql?

  • Ваш анализ также может иметь большое значение для разработчиков, архитектур баз данных и программного обеспечения, а также для разработчиков SQL-запросов .....

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

manmathan
источник
1
Я разработчик, и помогаю взвесить это решение. Нам не хватает настоящего системного администратора, поэтому мы все (6 из нас) принимаем участие в обсуждении. Наши текущие серверы являются 32-битными и не способны на многое из-за ограничения памяти на процесс. Наша сеть / хранилище на данный момент (должно быть) в порядке. Бэкэнд хранилища - это SAN. Наш процессор никогда не работает на максимуме. Большая часть затрат, связанных с нашими запросами, - это ввод-вывод, который должен быть уменьшен за счет возможности использовать больше оперативной памяти. Мы также повышаем до RAC. У нас есть четкое представление о том, что нам нужно. Это вопрос, который сомнителен.
Джош Смитон