В настоящее время у меня проблемы с сервером базы данных для БД с большим количеством мелких записей и несколькими по сравнению с большими чтениями. Производительность чтения более важна, потому что в нее вовлечены люди, а запись выполняется автоматическими клиентами. Эта база данных в настоящее время составляет 30 ГБ и будет увеличиваться до сотни или около того.
В настоящее время ужасная и уродливая установка, которая работает хуже,
Итак, из-за множества уродливых моментов (низкая производительность, отсутствие RAID, внешний USB-накопитель для резервного копирования) я планирую установить новый сервер базы данных.
Я думал о:
Итак, три вопроса:
Это лучшее сочетание цены и качества? Это перебор? Есть лучшая комбинация? Нужна дополнительная информация?
Знаете ли вы об одном компьютере по разумной цене, который может содержать 10 дисков, или мне нужно прямо сейчас использовать внешнее локально подключенное хранилище?
Какие-нибудь рекомендации, как получить что-то подобное по разумной цене / качеству?
Прежде чем я начал покупать оборудование, я бы провел некоторое исследование с помощью Performance Monitor, чтобы убедиться, что диски отстают. Если проблемы с производительностью вызваны блокировкой со стороны этих «автоматических клиентов», вы можете обнаружить, что производительность на новом сервере не сильно отличается от того, что у вас есть сейчас.
Изменить № 1: мне нравится смотреть на среднюю. Число секунд / передач диска. По сути, это показатель задержки диска. Раньше я использовал номера очереди, но вы должны были разделить их на количество шпинделей в массиве RAID. Вы не всегда знаете это число, особенно с хранилищем SAN, и Microsoft Ninjas посоветовали мне отказаться от чисел глубины очереди еще в 2002 году или около того.
(Обычно я наблюдаю за числами секунд / передач, числами чтения и записи за секунду (они дают хорошее представление о том, как работает диск), а также за логическими и физическими значениями чтения страниц (помогает определить, когда другие, не SQLServer использует диск, и когда SQL просто сканирует много данных из ОЗУ). Последнее значение находится под счетчиками SQL, а не под счетчиками диска. И, конечно же, использование старого простого процессора для каждого доступного ядра (а не "общее количество").
С средн. Disk sec / tranfer values, я просто ищу средние значения ниже 50 мс для дисков с данными и 20 мс для дисков с журналами. Обратите внимание, что ваша текущая установка имеет ОС и журналы на одних и тех же шпинделях, что означает, что они будут бороться за контроль над головками дисков, и это увеличит ваши задержки.
Обратите внимание, что высокая скорость чтения для баз данных может просто означать плохую индексацию. Довольно сложно справиться с проблемами индексации на веб-форуме. С таким большим объемом ОЗУ в новом корпусе вы можете хранить почти все данные в ОЗУ. Это снизит нагрузку на диски, но вы можете столкнуться с высокой загрузкой процессора, потому что SQL все равно необходимо сканировать все эти данные; это просто в ОЗУ, а не на диске. Хранение его в ОЗУ будет быстрее, чем на диске, но все равно будет медленнее, чем хорошо проиндексированная база данных.
Кроме того, я бы попытался сохранить свои данные и tempdb на разных наборах шпинделей, потому что, когда вы выполняете тяжелую запись в tempdb, это обычно означает, что вы выполняете тяжелое чтение из данных (что-то вроде select * into #report from huge_table, или, возможно, использование отдельных или групповых для больших наборов результатов). Если ваше приложение не слишком часто использует tempdb, это может не иметь большого значения.
Для хорошо настроенного SQL Server вам не нужно хранить всю базу данных в ОЗУ. У меня есть серверы с 12 ГБ оперативной памяти, которые хранят 100 ГБ данных.
Кроме того, вы, вероятно, могли бы немного сэкономить, выбрав для ОС диски со скоростью 10 тыс. Об / мин. Когда SQL запущен и запущен, он не должен сильно касаться загрузочного диска.
Если бы я был на вашем месте, меня больше всего беспокоило бы отсутствие избыточности RAID с вашей текущей настройкой, за которой следовало бы (вероятно) долгое время резервного копирования на этот USB-накопитель.
Если бы я на какое-то время застрял с этим USB-накопителем, я мог бы подумать о том, чтобы делать ПОЛНОЕ резервное копирование раз в неделю, а затем ДИФФЕРЕНЦИАЛЬНОЕ резервное копирование раз в день. В зависимости от того, какая часть ваших данных действительно меняется в любой день, это должно сократить объем данных, которые вы должны переместить на USB-накопитель.
Если у вас много дисков, например в той или иной форме SAN RAID10 является очевидным выбором, поскольку он сочетает в себе скорость и отказоустойчивость. Однако в большинстве случаев существует ограничение на количество дисков, которые могут быть установлены на сервере, и в этом случае вам необходимо рассмотреть вариант RAID5 в качестве альтернативы.
Ваши 4-х дисковые массивы RAID10 имеют примерно такую же скорость, что и 2-дисковые RAID0, или немного меньше, чем в два раза быстрее, чем у незащищенных дисков, поэтому они не будут такими быстрыми. Использование 4-х дискового RAID5 вместо этого даст массив с более высокой скоростью потокового чтения и записи, но немного меньшей скоростью записи с произвольным доступом (я тестировал это на контроллере Dell Perc5 / i, и я предполагаю, что это верно для других контроллеров).
Я бы подумал об использовании ваших 10 дисков в качестве 6-дискового RAID10 и 4-х дискового RAID5. Разделите RAID5 на небольшой раздел C: для ОС, а остальные как раздел D: для файлов журнала. Журналы, как правило, записываются последовательно, поэтому более низкая скорость произвольного доступа не является такой проблемой. Поместите данные на RAID10, где они получат выгоду от высокой скорости произвольного доступа, особенно высокой скорости произвольной записи.
NB Я не рекомендую вам организовывать диски как RAID10 и RAID5, однако я рекомендую вам протестировать использование дисков в этом формате и сравнить скорость с вашим предложением RAID1 + RAID10 + RAID10.
JR
32 ГБ ОЗУ - хорошее типичное круглое число для большинства серверных процессоров, но если вы смотрите на процессоры Xeon 5500 (Nehalem), то помните, что они оптимально настроены в банках по 3 модуля DIMM на процессор и в количестве, кратном 6 модулям DIMM для двухпроцессорных серверов, поэтому вы увидите лучшую производительность с 24/48 ГБ ОЗУ, а не с 32 ГБ.
Есть много серверов, на которых можно разместить 10 дисков, но я не могу сказать, считаете ли вы их разумными по цене или нет. Я сомневаюсь, что вы найдете любой 1U, такой как R300, который займет 10 дисков - HP 360 G6 может втиснуть 8 2,5-дюймовых дисков SFF в 1U по базовой цене чуть более 2 тысяч долларов. Dell R610 примерно эквивалентен (это также 1U система с двумя сокетами Xeon 5500), но имеет только 6 внутренних дисков.Даже если вы подключитесь к серверам класса DL380 \ R710 2U
Стоечные башни, такие как HP ML370 G6, стоят около 2,5 тысяч долларов, но могут вмещать до 24 дисков. У Dell T710 около 16.
Вышеуказанные цены являются минимальными прейскурантными ценами на шасси с 1 процессором, без дисков и практически без оперативной памяти. Настроенный HP ML370 с этими дисками, 24 ГБ оперативной памяти и двумя процессорами Xeon E5540 будет иметь прейскурантную цену около 10 тысяч долларов. Большая часть этого зависит от вашего выбора дисков - вы, вероятно, могли бы сэкономить около 1500-2000 долларов, выбрав вариант с одним сокетом, но предельная стоимость оперативной памяти может возрасти, поскольку модули DIMM DDR3 объемом 4 ГБ примерно на 50% дороже на ГБ, чем 2 ГБ модули.
Отредактировано, чтобы добавить некоторое представление о сравнении производительности.
Процессор Xeon 5540 2,53 ГГц будет примерно на 50% лучше по тактовой частоте по сравнению с вашим существующим процессором. Установка с двумя сокетами с SQL 2005 должна достаточно эффективно масштабироваться, поэтому с точки зрения чистого процессора система с двумя сокетами, подобная перечисленным выше, будет иметь примерно в 3 раза большую мощность процессора, чем ваш R300.
При настройке со сбалансированной оперативной памятью DDR3 @ 1066 МГц вы должны увидеть примерно в 3 раза большую пропускную способность памяти, возможно, больше, поскольку я подозреваю, что ваша текущая настройка R300 не оптимальна.
Что касается производительности диска, вы увеличиваете эффективную емкость произвольного ввода-вывода, по крайней мере, в 5 раз (очевидно, достаточно), но, добавив приличный усовершенствованный RAID-контроллер и правильно разделив функциональность, вы, вероятно, увидите значительно лучшие улучшения производительности сверх который.
Набор микросхем Tylersburg, используемый (почти) во всех текущих системах на базе Xeon 5500, также разделяет ввод-вывод памяти и остальное, что труднее измерить количественно, но неизменно принесет некоторую пользу.
Эти системы во много раз быстрее, чем ваша существующая установка, но действительно ли это приведет к повышению производительности для ваших пользователей, зависит от ваших текущих узких мест. Если это плохо спроектированное приложение или перегрузка сети, одно только наращивание сервера не приведет к такой явной выгоды.
Так много вопросов...
Это выделенный SQL-сервер? (так должно быть!) 32 ГБ ОЗУ в порядке, а процессор в порядке ...
На этом сервере размещается только эта единственная база данных или он используется многими приложениями с разными базами данных?
какова загруженность сервера? Сколько транзакций в секунду (чтение / запись)?
Насколько важны данные? Если это очень важно (т. Е. - не должно его потерять), то настройте сборку на избыточность. Если он должен быть доступен на 100% (без простоев), то сделайте ставку на отказоустойчивость (и получите больший бюджет). Если это ТОЛЬКО база данных производительности (то есть хранилище данных), вы можете оптимизировать производительность.
Вы должны посмотреть на счетчики производительности, чтобы определить текущее узкое место. Большой дисковый ввод-вывод и дисковые очереди? Высокий процессор? (часто вызвано ограниченным объемом оперативной памяти и мусором контекста)
Правильно ли написан код SQL? Я видел большие машины (и ваша довольно большая), поставленные на колени из-за плохого кода SQL, и крошечные машины (1 CPU, 1GB RAM), загружающие хорошо написанные и загруженные базы данных.
Как правило, держитесь подальше от RAID 5 (размер вашей базы данных достаточно мал, чтобы не требовать дополнительной емкости), лучше всего подходит RAID10.
Разделяйте DATA и TEMP на разных дисковых массивах.
Вам следует отказаться от двухдискового RAID 1 для LOGS, сдвоенного диска для TEMP (создать столько файлов данных TEMP, сколько ЦП на двух дисках), а затем ДАННЫЕ могут быть в большем массиве RAID10 от 4 до 6.