Некоторое время я наблюдал за нашим SQL-сервером и заметил, что количество операций ввода-вывода с использованием диспетчера задач и Perfmon время от времени достигает 100%.
Обычно мне удавалось связать этот всплеск с ЗАПРЕЩЕННЫМИ процессами в SQL Server Management, когда я выполнял «exec sp_who2».
Контроллер RAID управляется LSI MegaRAID Storage Manager. У нас есть следующая настройка:
Сервер представляет собой 64-битную машину с более чем 50 ГБ оперативной памяти. 64-разрядная версия SQL 2005 работает под управлением 64-разрядной версии Windows 2003. К сожалению, приложение работает поверх jBoss, который в настоящее время является 32-битной версией (но мы подталкиваем поставщика программного обеспечения к установке 64-битной версии jBoss).
Это база данных, которая забивается днем, но довольно неактивна ночью. Размер БД в настоящее время составляет около 13 ГБ и используется примерно 200 (и растет) пользователями в день.
У меня есть пара идей, над которыми я работаю:
Что касается №2, мой вопрос таков: действительно ли мы увеличиваем производительность диска (IO), перемещая данные с RAID 10 на RAID 1? Очевидно, что RAID 10 имеет лучшую производительность, чем RAID 1. Кроме того, SQL должен записывать в журналы транзакций перед записью в базу данных.
Но с другой стороны, мы уменьшим как размер дисков, так и объем данных, записываемых в RAID 10, где находится вся «мясо», - тем самым увеличивая производительность этого RAID для запросов чтения.
Есть ли способ узнать, каков наш текущий ограничивающий фактор? (Диски против RAID-контроллера)? Если ограничивающим фактором являются диски, возможно, имеет смысл добавить дополнительный RAID 1. Но если ограничивающим фактором является сам Контроллер, то я думаю, что мы неправильно подходим к этому вопросу.
Наконец, мы просто зря теряем время? Должны ли мы вместо этого сосредоточить наши усилия на №1 (переиндексация таблиц, уменьшение задержки в сети, где это возможно, и т. Д.)?
Скорее всего, вам нужно исправить некоторые проблемы с индексацией на вашем SQL Server. База данных на 13 гигабайт с 200 пользователями не должна сильно нагружать диск, если только пользователи не выполняют очень сложные запросы и для системы нет ОЗУ.
Я бы не стал утруждать себя добавлением какого-либо оборудования (кроме, возможно, большего объема ОЗУ) в зависимости от того, какой у вас тип - x32 или x64, и какую версию и выпуск SQL и Windows вы используете.
Я думаю, что всегда есть преимущество в разделении файлов базы данных и файлов журнала на отдельные RAID-массивы. Ввод-вывод файла базы данных всегда случайный, в то время как ввод-вывод файла журнала всегда последовательный. Смешивание этих типов ввода-вывода в одном массиве RAID всегда будет приводить к снижению производительности (хотя это может не быть очевидным, если на массив очень малая нагрузка ввода-вывода). Я думаю, что ваш пункт № 2 хорошо посоветован, хотя, как заявил mrdenny, у вас, вероятно, есть проблемы с базой данных (индексы и т.д.), если вы видите дисковый ввод-вывод так же высоко, как и с базой данных такого размера и 200 пользователями.
Я использую один SQL Server (стандарт 2005) со в среднем 2000 подключениями к 125 базам данных без проблем с производительностью, которые вы наблюдаете. У нас есть один массив RAID1 для баз данных и еще один массив RAID1 для файлов журнала.
Кроме того, не упускайте из виду выравнивание разделов (томов) как возможную причину проблем с производительностью.
Также посмотрите эти статьи:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21949
http://technet.microsoft.com/en-us/library/cc966540.aspx
http://technet.microsoft.com/en-us/library/cc966534.aspx
http://technet.microsoft.com/en-us/library/cc966412.aspx#EEAA
Для файлов журнала они должны быть на разных шпинделях, что означает отдельные диски, массивы рейдов и тома. Причина этого в том, что запись журнала является последовательной и должна выполняться как можно быстрее в больших единицах распределения, без необходимости бороться с другим доступом к базе данных (либо записью в базу данных, либо запросами).
Ваши тома должны иметь размер единицы распределения 64 КБ, и, как упоминалось в joqwerty, вы, более чем вероятно, также страдаете от смещенных разделов, потому что разделы Windows смещены по умолчанию в Windows 2003. В некоторых случаях снижение производительности может быть значительным. от 30 до 40%. В следующей статье описывается, как воссоздать правильно выровненные разделы:
Рекомендации по выравниванию дисковых разделов для SQL Server
http://msdn.microsoft.com/en-us/library/dd758814%28v=sql.100%29.aspx
Я не совсем понимаю, что вы имеете в виду под «переиндексацией». Если он перестраивается или реорганизуется, это в любом случае должно быть частью ежедневного плана обслуживания. И если вы не знаете, насколько фрагментированы ваши индексы, то вам нужно собрать базовую информацию, прежде чем предпринимать какие-либо действия. Я бы не очень хотел создавать новые индексы, если у вас нет эмпирических данных, подтверждающих это. В частности, базы данных, которые часто обновляются (OLTP), должны иметь как можно меньше индексов, потому что каждый индекс снижает производительность обновления. Я видел, как люди приносят больше вреда, чем пользы, "ковровые бомбардировки" базы данных с индексами.
Наконец, вы можете убедиться, что на вашем RAID-контроллере включено кэширование записи. Я видел, как слишком много людей пропускают это. Иногда кэширование записи может быть отключено из-за необходимости замены батареи или из-за того, что они не знали, что им нужна батарея для включения кэширования.