Опубликован: 11.12.2006 | Доступ: свободный | Студентов: 5820 / 381 | Оценка: 4.42 / 3.86 | Длительность: 57:15:00

Лекция 5: Конфигурирование и планирование подсистемы ввода-вывода

Задержки ввода-вывода и SQL Server

SQL Server очень чувствительна к задержкам ввода-вывода, потому что транзакции обрабатываются алгоритмом SQL Server одновременно. При обычной работе база данных SQL Server взаимодействует с десятками и сотнями приложений. Чтобы поддерживать эту одновременную работу, SQL Server имеет сложную систему блокировок (замков) строк, страниц, экстентов и таблиц, с которой вы познакомитесь в нашей книге. При блокировке каких-либо данных или ресурсов SQL Server, другие процессы должны ждать, пока эти данные или ресурсы не будут разблокированы.

Если длительность выполнения операций ввода-вывода слишком велика, то эти ресурсы будут блокированы недопустимо долго, еще сильнее замедляя работу системы. Кроме того, это повышает вероятность тупиковых ситуаций (взаимоблокировок). Чем дольше выполняются операции ввода-вывода, тем дольше длятся и блокировки и тем серьезнее становятся эти проблемы. И в результате отдельные задержки могут сложиться, вызвать "эффект снежного кома" и испортить работу системы.

Кроме того, обработка запросов станет очень медленной. Например, если на вашей системе выполняется сканирование больших таблиц, то для выполнения таких задач часто требуется чтение сотен, тысяч и даже миллионов строк в базах данных. Для миллиона операций ввода-вывода даже небольшие изменения производительности становятся очень важными. Выполнение одного миллиона операций по 10 мс займет около 2,8 часа. А если ваша подсистема ввода-вывода оказалась перегружена и каждая операция ввода-вывода требует 40 мс, то выполнение такого же запроса займет уже более 11 часов.

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

Планирование размещения дисков SQL Server

Из материала данной лекции ясно, что вы должны правильно спланировать свою систему ввода-вывода, чтобы не допускать ее перегрузки. Перегрузка подсистемы ввода-вывода повлечет увеличение задержек ввода-вывода и падение производительности SQL Server. В данном разделе вы изучите, как построить систему SQL Server, способную работать в рамках ограничений вашей подсистемы. Сначала вы научитесь определять требования вашей системы к вводу-выводу. Затем вы изучите планирование системы, а последним этапом будет само создание вашей системы.

Определяем требования к вводу-выводу

Определение требований к вводу-выводу системы, существующей еще только в виде концепции, может оказаться хоть и сложным, но вполне возможным делом. Однако если у вас нет конкретных данных, на основе которых можно определить требования к вводу-выводу, то вы должны смочь собрать достаточно данных, чтобы можно было сделать обоснованное предположение. В любой ситуации, создание подсистемы ввода-вывода, неспособной к росту, будет ошибкой. Всегда предусматривайте резервы для необходимого роста мощности и производительности, рано или поздно они вам понадобятся. Вы должны спроектировать систему так, чтобы она удовлетворяла бы минимальным требованиям к объему дисковой памяти, необходимой для хранения данных, и к необходимому для вас уровню производительности. В следующем разделе вы узнаете, как определить какое количество дисков потребуется для удовлетворения этим условиям.

Объем дисковой памяти

Определить, сколько места на дисках потребуется для ваших данных, достаточно просто. Объем необходимого места равен сумме следующих величин:

  • Дисковой памяти, необходимой для данных.
  • Дисковой памяти, необходимой для индексов.
  • Дисковой памяти, необходимой для временных данных.
  • Дисковой памяти, необходимой для журнала транзакций.

Дисковая память, отводимая для данных, должна иметь достаточно места для хранения данных, которые будут добавлены в вашу базу данных. Рост базы данных в значительной степени определяется вашим бизнесом и вашими клиентами. Чтобы оценить рост вашей системы, можно проводить регулярные проверки существующей базы данных и подсчитывать, как изменился объем дисковой памяти, занимаемой базой данных. Темп роста базы данных должен измеряться несколько месяцев, чтобы можно было определить его закономерности. Рост базы данных может оказаться таким, что удивит вас.

Для новой системы, не имеющей истории, при оценке роста, среди прочих критериев, вы можете воспользоваться количеством заказов на продукцию, умноженным на размер строки. Взяв эти показатели для нескольких периодов времени (например, месяцев или лет), вы получите грубую оценку о скорости роста файлов с данными. Это не даст вам информации о росте индексов. Объем дисковой памяти, необходимой для индексов в расчете на одну строку данных, зависит от конструкции индексов и от объема данных. Для сложного индекса требуется больше места в расчете на одну строку данных, чем для простого индекса. И решение о том, сколько времени система должна существовать в условиях роста – два года, пять лет или дольше, – принимаете вы. Вот так производится оценка, с каким объемом дисковой памяти должна быть сконфигурирована ваша подсистема ввода-вывода.

Определившись с объемом данных, объемом индексов, объемом временной базы данных и с темпом роста, вы можете определить, сколько места на дисках вам потребуется. Затем вы должны учесть место, необходимое для обеспечения отказоустойчивости в массивах RAID. Помните, что в массивах RAID 1 и RAID 10 (с зеркальным дублированием данных) для обеспечения отказоустойчивости тратится половина физического места на дисках. В массивах RAID 5 для обеспечения отказоустойчивости тратится один дисковый накопитель, входящий в состав массива. Также помните, что объем дисков, указываемый изготовителями, обозначает емкость неотформатированного диска. Неотформатированный дисковый накопитель, маркированный, как имеющий емкость 9,1 Гб, после форматирования будет вмещать на самом деле 8,6 Гб.

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

Производительность

Недостаточно просто сконфигурировать систему так, чтобы она отвечала требованиям к объему необходимой дисковой памяти. Как вы уже знаете из материала данной лекции, конфигурация подсистемы ввода-вывода может серьезно ухудшить или значительно улучшить производительность вашей системы. Однако оценка требований к производительности совсем не так проста, как оценка требований к объему дисковой памяти.

Наилучшим способом оценки производительности является изучение аналогичных приложений или систем. Эти данные могут стать отправной точкой для оценки будущих требований. Дополнительную информацию об этом вы получите в "Планирование мощности системы" . Предположим, что вы нашли похожую систему. Тогда для определения необходимого количества дисков вы можете воспользоваться данными, собранными при исследовании этой системы, и информацией, которую вы знаете из данной лекции. Не забудьте учесть влияние уровня RAID, применяемого в той подсистеме ввода-вывода. Следующим этапом станет планирование размещения дисков SQL Server, а после этого можно будет осуществить реализацию вашего решения.