Во-первых, пока я не хотел бы советоваться; Мне также интересно, есть ли какие-нибудь хорошие способы измерения / сбора данных заранее, которые я мог бы использовать, чтобы определить, каким «практическим правилам» следовать, а какие пропустить.
Я не могу существенно изменить схему для приложения, и хотя у меня есть подозрения, что разработчики остались довольны индексированием; Я пока не хочу вынимать их индексы и заменять их.
У меня есть база данных приличного размера для телефонного приложения, около 60 ГБ или около того. Данные разбиваются в основном на:
Сейчас я нахожусь на одноядерной машине с 3 Гб, выделенным для SQL Server, и дисковым кешем в SQL Server 2005. База данных msdb и ОС находятся на жестком диске 15 КБ, RAID 1. Файлы журнала и резервный диск находятся на 15 КБ. жесткий диск, RAID 1. Телефонная БД размещена на 2 жестких дисках по 15 КБ, RAID 10. (Всего восемь дисков).
Я сильно модернизирую оборудование. Будет SQL Server 2008 R2, 12 ядер, 32 ГБ ОЗУ на Server 2008 R2 x64. У него будет четыре внутренних жестких диска, вероятно, для ОС и резервного копирования, но самое большое изменение - это подключенное хранилище - 12 дисков по 15 КБ на внешнем интерфейсе SAS.
Мы немного ограничены процессором / вводом / выводом на текущем сервере, но недостаточно, чтобы сильно беспокоиться - эти новые серверы собираются исцелить множество грехов - но на этот раз я все же предпочел бы сделать это «правильно».
Я мог бы создать массивный RAID 10 из 6 дисков и перекинуть на него всю БД, но я подумывал о разделении TRAFFIC и его индексных файлов на отдельные разделы, а также, возможно, БИЛЛИНГА. Кроме того, все остальное может хорошо работать в собственном файле.
Тогда, конечно, всегда есть RAID 10, RAID 5/6 или RAID 50/60.
Мне бы хотелось получить советы о том, как подойти к этому решению и как определить, стоит ли разбивать диски, чтобы разделить TRAFFIC / BILLING - и подойдет ли мне две файловые группы (PRIMARY и USERDEFINED), или если я нужно больше.
Кстати, sizeof (TRAFFIC) = sizeof (BILLING) * 2 >> sizeof (ВСЕ ДРУГОЕ)
Спасибо,
это должно помочь также google dmv all stars!
http://technet.microsoft.com/en-us/library/cc966540.aspx
также
записи Windchill охватывают почти все области настройки производительности для серверов sql
Я собираюсь дать ссылку на технический документ, в котором рассказывается, как ответить на этот точный вопрос. Хотя все мы можем дать общие рекомендации, на самом деле все сводится к тому, насколько реально используется ввод-вывод, чтобы ответить на вопрос. В следующем техническом документе рассказывается о том, как это измерить и как соответствующим образом спланировать дисковую подсистему (и протестировать новое оборудование, чтобы убедиться, что оно исправно). Кроме того, в конце есть много дополнительных ссылок, чтобы по-настоящему углубиться в эту область:
Начнем сверху.
У меня есть большая база данных для приложения телефонии, около 60 ГБ или около того
Перефразируйте это: у меня довольно маленькая база данных. А если серьезно, то время, когда было 60 гигов, было лет 10 назад. Сравните это с: у меня есть окончательная база данных, которая имеет 800 ГБ и продолжает расти, 95% данных в одной таблице;)
У него будет четыре внутренних жестких диска, вероятно, для ОС и резервного копирования, но самое большое изменение - это подключенное хранилище - 12 дисков по 15 КБ на внешнем интерфейсе SAS.
Вот что бы я сделал:
Зеркально отразите следующие 2 диска для файлов журнала. Если они запускаются на IO - замените их на SSD. Учитывая небольшое количество изменений, которые у вас есть ... небольшого SSD на 80 ГБ должно быть достаточно.
Остальные (12 дисков) поставили массивный RAID 10.
Более важно, чтобы вы перенастроили наш сервер для использования:
Тогда, конечно, всегда есть RAID 10, RAID 5/6 или RAID 50/60.
На что следует обратить внимание, учитывая ОГРОМНУЮ разницу в производительности между Raid 10 и другими, которые выкидывают воду из Raid 5/6/50/60 для всего, что требует высокого ввода-вывода. RAID 5/6 имеет смысл только при установке SSD-накопителей - тогда значительные потери ввода-вывода будут полностью съедены. На самом деле, с учетом вашего тривиального размера базы данных, даже использовать диски SAS 2x15 может быть финансово идиотским. Получите 2 диска REALSSD по 200 Гбайт, и у вас будет примерно в 100 раз больше производительности ввода-вывода, если RAID 10 на 30 ваших дисках. Учитывая значительную стоимость инфраструктуры, вы можете сэкономить МНОГО денег в пути.
На самом деле, самым разумным было бы не заказывать всю штуку с SAS - у вас есть 4 слота для дисков, поместите ОС на два диска, используйте SSD на 200 ГБ в зеркале на другом. Законченный. И НАМНОГО быстрее, чем ваш SAS;) Радость иметь тривиальный размер базы данных. Проверьте http://www.fastestssd.com для текущего состояния. Современный твердотельный накопитель в такой конфигурации будет иметь стабильную скорость 200 Мбайт, даже если он не лучший. Это серьезно затерет поток из-за посредственного ввода-вывода, который вы получаете от своей настройки SAS.
Или: 30 дисков SAS могут быть 4800 IOPS. RealSSD достигает 50 000 - на одном диске, со «слабым временем» около 36 000 IOPS. Это означает, что ONE SDD примерно в 7,5 раз быстрее - в медленные моменты - по сравнению с настройкой из 12 дисков. В хорошие времена примерно в 10 раз быстрее. Ой.
Будьте осторожны, чтобы правильно выровнять разделы и правильно отформатировать файловую систему (подсказка: не используйте стандартный размер узла 4 КБ - глупо для SQL Server).
Я мог бы создать массивный RAID 10 из 6 дисков и перекинуть на него всю БД, но я подумывал о разделении TRAFFIC и его индексных файлов на отдельные разделы, а также, возможно, БИЛЛИНГА. Кроме того, все остальное может хорошо работать в собственном файле.
Это было бы глупым злоупотреблением SQL Server. Даже если он выполняет балансировку нагрузки между файлами и хочет / запрашивает несколько файлов на группу (по одному на логический процессор), он ничего не получит - наоборот. Разделение файлов и индексов НИЧЕГО не дает, если они все равно попадают на одни и те же диски. В вашем случае вам лучше с одной файловой группой, 12 файлов. Если вам нужна более поздняя масштабируемость, вы можете для начала использовать 48 файлов данных - это дает вам место до 48 ядер процессора.
Возможно, вы захотите использовать две файловые группы, чтобы отделить данные биллинга от менее изменчивой - / запрошенной, но не для прямой скорости, а для возможности перенести их полностью позже без реорганизации - это то, что я сделал со своими финансовыми база данных.
Последние слова: тот, кто купил сервер, принял плохое решение с аппаратной точки зрения. Нет смысла иметь внешний лоток SAS для чего-то такого маленького. Мой сервер базы данных от SuperMicro и имеет 24 слота для дисков на высоте 2 стойки. То есть без внешней клетки. Я не очень хочу здесь сравнивать цифры, но держу пари, что это было потрачено впустую много денег.