Рекомендации по конфигурации оборудования SQL Server
Мы находимся в процессе создания нового сервера SQL и хотели бы получить некоторые рекомендации по аппаратному обеспечению. В настоящее время мы строим все системы в доме. С информацией ниже, что вы бы порекомендовали для дисков и внешней корзины SAS. Кроме того, насколько полезен SAS в этой рабочей нагрузке по сравнению с SATA2?
Основные характеристики на данный момент:
- Процессор AMD Phenom II X4 955
- 8 ГБ ОЗУ
- 2 ТБ RAID6 хранилища (на 450 ГБ дисков Seagate Cheetah 15K.6)
- 1 ТБ хранилища RAID1 (почему ниже) (1 ТБ Seagate Barracuda ES.2)
- Контроллер 3ware 9690SA SAS
Программного обеспечения:
- Сервер Windows 2003 или 2008 (еще не решил)
- SQL Server 2005 или 2008 (будет зависеть от совместимости приложений)
Нагрузка:
Этот сервер достаточно тяжел для чтения / записи для большинства приложений (около 1 ТБ) (финансовые, внутренние приложения и т. Д.). У нас также есть ГИС-данные на сервере, который используется ArcGIS. Наш план состоит в том, чтобы наши векторные данные находились в основном массиве RAID6, а растровые данные (около 750 ГБ) - в массиве RAID1 (поскольку их использование не так часто).
3 ответа
Я бы предложил RAID10 для работы с тяжелой базой данных, которая в основном не предназначена только для чтения, а не RAID5 или 6. В массиве RAID6 с 4 дисками каждая запись блока (или частичная запись блока) может быть превращена в чтение (для получения других данных). блок), за которой следуют три записи (одна для начальной записи, две для двух блоков четности), что может оказать существенное влияние на производительность записи. С RAID10 каждая (частичная) блочная запись - это всего лишь две записи на диск.
Если доступ к вашей базе данных включал очень мало записей, тогда RAID6 может быть предпочтительным для резервирования, так как массив RAID6 может выжить при любых двух дисках, выходящих из строя, где-как массив RAID10 из четырех дисков выживет только 4 из 6 возможных комбинаций двух неисправных дисков, но вы заявляете, что ожидаете интенсивного чтения и записи (и у вас есть хорошие планы резервного копирования и аварийного восстановления, верно?).
Очевидно, что вы должны использовать 64-разрядную версию Windows и SQL Server, иначе вы не сможете использовать всю эту оперативную память без снижения производительности, такой как PAE. Пока мы находимся в памяти: я бы предложил больше, если вы можете. В наши дни оперативная память не дорогая, даже хорошая ОЗУ с поддержкой ECC известного бренда, поэтому повышение с 8 до "сколько угодно, сколько угодно" - неплохая идея. Для большинства приложений на сервере SQL (с достаточно большими базами данных) вы заметите преимущество при любой значительной нагрузке, поскольку это значительно сократит операции ввода-вывода для запросов на чтение, поскольку больший рабочий набор может храниться в памяти. Из вашего описания звучит так, как будто у вас есть размер данных и шаблон активности, которые выиграют от того, сколько ОЗУ вы практически сможете использовать. Многие новые серверы поддерживают 16 ГБ ОЗУ в наши дни, и 32 ГБ не редкость (и все чаще не поддерживается 64 ГБ, хотя это выходит на "специализированный" рынок, поэтому вам, возможно, придется доплатить за дополнительную плату).
Если ваша база данных вообще интенсивно пишет, используйте RAID 10, а не RAID 6. С очень быстрыми, действительно отличными дисками SAS.
Купите шасси большего размера, чем вам нужно, чтобы вы могли расти в нем. Я недавно добавил четырехъядерный процессор к своему производственному серверу баз данных - и я могу вам сказать, что раз в своей карьере я был очень рад, что купил материнскую плату с двумя сокетами, хотя для запуска мне понадобилось всего четыре ядра. Увеличение загрузки ЦП в среднем с 60% при длительных пиках в среднем от 100 до 30% при очень редких пиках в 100% оказало огромное влияние на нашу производительность. Не нужно было полностью переходить с одной машины на другую, чтобы получить это, было действительно здорово - вытаскивание другого чипа в дополнительный сокет заняло около 20 минут. Что касается оперативной памяти; положить столько, сколько машина может взять.
Как примечание, наша производственная система использует SAS, наша система разработки использует SATA. Мы можем определенно почувствовать и оценить разницу; запросы, которые могут потребовать 1,5 секунды на нашей загруженной рабочей машине, могут занять 3 секунды на нашем незагруженном сервере разработки. Это определенно анекдотично, конечно, и есть другие различия; но мы заметили, что IO определенно убийца. 1,5 секунды не имеет большого значения, верно? За исключением производства, разница составляет 1,5 секунды * x пользователей * y запросов в час.
Еще одна мысль о IO: мы старались настроить наши самые часто используемые таблицы, чтобы они находились в файловых группах с несколькими файлами в них. Одним из улучшений производительности является то, что SQL будет направлять запросы к каждому файлу в файловой группе - поэтому, если BigOverUsedTable находится в FileGroup1, а FileGroup1 содержит четыре файла, а ваша БД имеет 8 ядер, он фактически будет использовать четыре ядра для выбора. большое число хрустит грязный запрос от BigOverUsedTable" - тогда как в противном случае он будет использовать только один процессор. Мы получили эту идею из этой статьи MSDN:
http://msdn.microsoft.com/en-us/library/ms944351.aspx
Из ТФА:
"Файловые группы используют параллельные потоки для улучшения доступа к данным. Когда к таблице обращаются последовательно, система создает отдельный поток для каждого файла параллельно. Когда система выполняет сканирование таблицы для таблицы в файловой группе с четырьмя файлами, она использует четыре отдельных Потоки для параллельного чтения данных. Как правило, использование нескольких файлов на отдельных дисках повышает производительность. Слишком большое количество файлов в файловой группе может вызвать слишком большое количество параллельных потоков и создать узкие места ".
Благодаря этому совету у нас есть четыре файла в нашей файловой группе на 8-ядерном компьютере. Это хорошо работает.
SAS является огромным преимуществом по сравнению с SATA2 для операций произвольного доступа. Я бы избегал SATA любой ценой. Вы упомянули строительство в доме, вы смотрели на стеллажные системы, подобные этой?
http://www.newegg.com/Product/Product.aspx?Item=N82E16811219021
Это даст вам 20 отсеков для дисков SAS в одном стоечном устройстве. Добавьте вашу материнскую плату и контроллеры SAS на ваш выбор.