Books and articles about SQL Rambler's Top100 Сменить язык на: Русский 22 September 2019 22:20:25


www.sql-ex.ru
Skip Navigation Links  

 

Print  Версия для печати

На главную страницу

Контрольный список вопросов оценки производительности аппаратных средств SQL Server

Brad M. McGehee (оригинал: SQL Server Hardware Performance Checklist )
Перевод Моисеенко С.И.

Список контрольных вопросов аудита производительности

Характеристики аппаратных средств SQL Server Запишите сюда
Число центральных процессоров  
Частота центрального процессора (МГц)  
Размер кэша L2 центрального процессора  
Объем физической оперативной памяти  
Общий объем свободного места на дисках сервера  
Общее число физических дисков в каждом массиве  
RAID уровень массива, используемого для баз данных на SQL Server  
Уровень фрагментации дисков  
Местоположение операционной системы  
Местоположение исполняемых модулей SQL Server  
Местоположение файла подкачки  
Местоположение базы данных tempdb  
Местоположение системных баз данных  
Местоположение пользовательских баз данных  
Местоположение журналов  
Число контроллеров дисков на сервере  
Тип контроллеров дисков на сервере  
Размер кэша в контроллерах диска на сервере  
Включен ли на контроллере диска кэш обратной записи?  
Скорость дисководов  
Сколько сетевых карт установлено на сервере?  
Какова скорость сетевых карт на сервере?  
Являются ли сетевые карты жестко закодированы на скорость/дуплекс?  
Сетевые карты оснащены переключателем?  
Обновлены ли драйверы аппаратных средств до последних версий?  
Специализирован ли физический сервер под SQL Server?  

Введите ваши показатели в таблицу выше.

* Центральный процессор
* Память
* Пространство на диске
* Сетевые подключения
* Прочее

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

Центральный процессор

Число центральных процессоров

Этот первый пункт очевиден; чем больше центральных процессоров, которыми располагает ваш SQL Server, тем быстрее он может работать. Стандартная редакция SQL Server 2000 (Standard Edition) поддерживает до 4 центральных процессоров. Редакция масштаба предприятия (Enterprise Edition) поддерживает до 32 центральных процессоров в зависимости от используемой ОС. Несколько центральных процессоров могут эффективно использоваться SQL Server, повышая общую производительность.

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

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

* Покупайте сервер с максимальным числом центральных процессоров, какое Вы можете себе позволить.

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

Вот некоторые потенциальные сценарии:

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

* SQL Server будет использоваться для выполнения специализированного приложения, разработанного на фирме. Приложение включает не только OLTP, но и поддерживает формирование довольно тяжелых отчетов. Ожидается, что параллельно работать с приложением будет не более 25 пользователей. В этом случае, можно рассмотреть вариант приобретения сервера с двумя центральными процессорами, но с возможностью увеличить их количество до 4 в случае необходимости. Трудно предсказать, что означают слова "довольно тяжелые отчеты". Я встречал несколько довольно простых, но плохо написанных отчетов, которые тормозили все центральные процессоры сервера.

* SQL Server будет выполнять ERP-пакеты, которые, которые поддерживают 100 - 150 одновременно работающих пользователей. Для таких "тяжелых" приложений, попросите вашего поставщика дать рекомендацию аппаратным средствам, поскольку они должны уже иметь хорошее представление относительно возможностей центрального процессора их продукта.

Я могу привести много других примеров, но суть моего объяснения сведется к тому, что очень трудно предсказать точно, в каком количестве центральных процессоров будет нуждаться конкретное приложение на базе SQL Server, и что Вы вообще должны покупать систему более мощную, чем ту, которая, как Вы думаете, Вам нужна. Это обусловлено тем, что во многих случаях требования к использованию приложении часто недооцениваются. В конечном счете более дешево обойдется покупка мощного сервер сейчас (с большим числом центральных процессоров), чем замена всего сервера через 6-12 месяцев из-за заниженной оценки.

Скорость центрального процессора

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

Кэш L2 центрального процессора

Один из самых часто задаваемых мне вопросов: "Купить ли менее дорогой центральный процессор с небольшим кэшем L2, или предпочесть дорогой центральный процессор XEON с большим кэшем L2?" Усложняет решение тот факт, что Вы можете купить при меньшем кэше L2 более быстрые чипы, чем чипы, которые имеют большой кэш L2. Мое эмпирическое правило таково:

* Если Вы будете использовать только 1 или 2 центральных процессора, приобретайте с самые быстрые центральные процессоры, которые Вам доступны, рассматривая вопрос о размере кэша L2 как вторичный. Если у вас есть возможность выбора размера кэша L2, всегда приобретайте максимально возможный.

* Но если Вы будете использовать 4 или более центральных процессора, тогда первичным является вопрос наибольшего кэша L2, даже при том, что скорость таких процессоров, возможно, не столь высока. Причина такого решения состоит в том, что для оптимальной работы SQL Server на серверах с четырьмя и более центральными процессорами, кэш L2 должен быть намного большим, в противном случае Вы будете тратить впустую большую часть мощности дополнительных центральных процессоров.

Контрольный список вопросов аудита центрального процессора

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

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

* Уменьшите нагрузку на ваш сервер. Этого можно достичь уменьшением числа пользователей, оптимизацией запросов, настройкой индексов, а также удалением любых необязательных приложений, выполняющихся на данном сервере. Один из вариантов заключается в перемещении приложений, занимающихся генерацией отчетов, с вашего промышленного сервера на SQL Server, выделенный исключительно под отчеты.

* Добавьте памяти, т.к. проблемы центрального процессора могут быть вызваны нехваткой памяти на сервере, что обычно имеет место.

* Поставьте дополнительные центральные процессоры, если Ваш сервер это позволяет.

* Установите более быстрые центральные процессоры на вашем сервере, если это возможно.

* Купите новый сервер с большим числом процессоров, а также и более быстрых.

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

Память

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

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

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

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

Самый быстрый способ узнать, имеет ли ваш SQL Server адекватное количество оперативной памяти, состоит в том, чтобы проверить счетчик SQL Server: Buffer Cache Hit Ratio (коэффициент удачного обращения в кэш буфера), который обсуждался в предыдущей статье. Если этот счетчик показывает 99 % или выше, то наиболее вероятно, что Вы имеете достаточно физической оперативной памяти на вашем SQL Server. Если показания этого счетчика находятся в интервале между 90 % и 99 %, и если Вы удовлетворены производительностью вашего SQL Server, то Вы вероятно имеете достаточно физической оперативной памяти на вашем SQL Server. Но если Вас не устраивает производительность сервера, тогда следует добавить оперативной памяти.

Если счетчик показывает меньше 90 %, это показатель того, что производительность вашего SQL Server является неприемлемой (если Вы выполняете OLAP-приложения, то менее 90 % это вообще-то в порядке вещей), и Вам следует добавить оперативной памяти на сервер.

Идеально, количество физической оперативной памяти в SQL Server должно превышать размер наибольшей базы данных из имеющихся на сервере. Это не всегда возможно, так как зачастую базы данных являются очень большими. Если Вы размещаете новый SQL Server и полагаете, что ваш бюджет является достаточно большим, попробуйте заказать такой SQL Server, который бы имел в своем распоряжении такой объем RAM, чтобы в ней могла разместиться вся проектируемая база данных. Если ваша база данных не превышает 4Гб, это обычно не вызывает проблем. Но если ваша база данных больше (или ожидается, что она станет больше 4Гб), тогда Вам, возможно, не удастся легко получить более 4Гб оперативной памяти. В то время как SQL Server 2000 Enterprise Edition поддерживает до 64Гб оперативной памяти, не слишком много имеется доступных серверов, которые поддерживают такой объем RAM.

Даже если вся ваша база данных не может вписаться в кэш буфера SQL Server, то SQL Server может все еще быть очень быстрым, когда наступает время извлекать данные. При 99%-ом отношении удачного обращения в кэш буфера в 99 % времени данные, которые необходимы SQL Server, уже находятся в кэше, и производительность будет очень высока. Например, я управляю одной базой данных, которая имеет размер 30Гб, но сервер при этом имеет только 4Гб оперативной памяти. Отношение удачного обращения в кэш буфера для этого сервера всегда более, чем 99.6 %. Это означает, что в большинстве случаев пользователи обращаются не ко всем данным в базе данных в одно и то же время, а только к некоторой их части, в результате чего SQL Server имеет возможность сохранять наиболее часто используемые данные в кэше постоянно. В этом специфическом случае, 99 % всех запросов выполняются быстро, даже при том, что сервер имеет намного меньше физической оперативной памяти чем объем данных в базе данных.

Что из этого следует? Если в вашем случае отношение удачных обращений в кэш буфера менее 90 %, то следует серьезно отнестись к увеличению количества оперативной памяти.

Емкость диска

После памяти, емкость диска часто оказывается самым важным фактором, влияющим на производительность SQL Server. Это также довольно сложная область. В этом разделе, я остановлюсь на "самых легких" моментах, в которых может проявиться производительность дисковой подсистемы.

Общий объем свободного пространства на дисках сервера

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

Исследуйте каждый из физических дисков на вашем SQL Server, выясняя, имеется ли на нем, по крайней мере, 20 % свободного пространства. Если такого объема нет, то рассмотрите следующие варианты:

* Удаление любых не являющихся необходимыми данных с дисков (освободите корзину, удалите временные файлы, удалите файлы установки, и т.д.),

* Перемещение некоторых данных на диски с большим объемом свободного пространства

* Добавление дисков.

Общее число физических дисков в каждом массиве

Дисковым массивом обычно называют два или более физических дисковода, работающих вместе как единое устройство. Например, массив RAID 5 может включать 4 физических дисковода. Почему же важно знать, сколько физических дисков находится в одном или большем количестве массивов на вашем SQL Server?

За исключением зеркальных массивов (которые представляют собой два физических дисковода, работающих вместе), чем больше физических дисководов имеется в массиве, тем быстрее происходит чтение и запись в этот массив.

Например, я хочу купить новый SQL Server с массивом RAID 5 и мне необходимо, по крайней мере, 100 Гб доступного пространства. Предположим также, что продавец предлагает две различных конфигурации массива:

* 4 36-Гбайтных диска (108Гб доступного пространства)

* 7 18-Гбайтных дисков (108Гб доступного пространства)

Оба эти варианта отвечают нашим критериям и обеспечивают, по крайней мере, 100 Гб дискового пространства RAID 5. Но какой массив обеспечит лучшую производительность по чтению и записи? Ответ - второй вариант, 7 18-Гбайтных дисков. Почему?

Вообще говоря, чем больше дисков в массиве, тем больше имеется головок чтения/записи. Диски SCSI, например, имеют способность выполнять чтение и запись данных одновременно. Поэтому чем больше физических дисководов имеется в массиве, тем более быстро выполняется чтение или запись данных в массив. Каждый дисковод в массиве принимает часть рабочей нагрузки, и чем она больше, тем лучше. Имеются некоторые границы, которые зависят от контроллера диска, но в большинстве случаев это правило выполняется.

Что это может означать для нас? После того, как Вы выяснили число массивов, которые Вы имеете в вашем SQL Server, а также числе дисков в каждом массиве, уместно рассмотреть вопрос о том, стоит ли реконфигурировать ваши текущие массивы, чтобы достичь преимущества, руководствуясь принципом, чем больше, тем лучше?

Пусть, например, ваш текущий сервер имеет два дисковых массива, используемых для хранения пользовательских баз данных. Каждый массив представляет собой RAID 5 с 3-мя 18Гб накопителями в каждом. В этом случае, возможно лучшим решением было бы реконфигурировать эти два массива в единственный массив с 6-ю 18Гбайтными дисками. Мало того, что это обеспечило бы более быстрый ввод/вывод, это также увеличит на 18Гбайт дисковое пространство.

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

RAID уровень массива, используемого для баз данных на SQL Server

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

RAID 1

* В идеале, операционная система и исполняемые модули SQL Server, включая файл подкачки операционной системы, должны быть расположены в массиве RAID 1. Некоторые люди размещают файл подкачки на его собственном RAID 1 массиве, но я сомневаюсь, что это действительно дает увеличение производительности, поскольку обмен страницами на хорошо сконфигурированном сервере не самая большая проблема.

* Если ваша база (ы) данных на SQL Server является очень маленькой, и все базы данных могут разместиться на единственном дисководе, рассмотрите вариант RAID 1 для хранения всех ваших файлов данных SQL Server.

* Идеально, если каждый отдельный журнал транзакций расположен на его собственном массиве RAID 1. Причиной такого решения является то, что запись и чтение из журналов транзакций выполняются последовательно, и, изолируя их на собственном массиве, последовательный ввод/вывод на диск не будет смешиваться с более медленным случайным дисковым вводом/выводом, что увеличит производительность.

RAID 5

* Хотя это самый популярный тип RAID-хранилища, он также не является лучшим вариантом обеспечения оптимальной производительности ввода/вывода SQL Server. Если больше 10 % всей деятельности базы данных составляет запись, что делает большинство баз данных OLTP, производительность операций записи пострадает, снижая общую производительность ввода/вывода SQL Server. RAID 5 лучше всего подходит для баз данных, используемых, главным образом, только для чтения или по большей части только для чтения. Испытание в Microsoft показало, что RAID 5 может оказаться на 50 % медленнее по сравнению с использованием RAID 10.

RAID 10

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

* Массивы RAID 10 являются также хорошим выбором для журналов транзакций, при условии, что они ориентированы на единственный журнал транзакций.

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

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

Соотношение аппаратных и программных средств RAID

RAID может быть реализован посредством аппаратных или же программных средств (с помощью операционной системы). Нет никаких дебатов по этой теме, никогда не используйте программый RAID, поскольку это очень медленно. Всегда используйте аппаратный RAID.

Уровень фрагментации диска

Если Вы создаете новую базу данных на совершенно новом дисковом массиве, то созданный файл базы данных и файл журнала транзакций будут одним непрерывным файлом. Но если размеры вашей базы данных или журнала транзакций растут (а какие базы данных и журналы транзакций этого не делают), то вполне вероятно, что файлы станут фрагментированным спустя какое-то время. Фрагментация файла, которая раскидывает части ваших файлов по всему дисковому массиву, заставляет его работать более интенсивно при чтении или записи данных, ухудшая производительность дискового ввода-вывода.

Как часть аудита производительности, Вам надлежит выяснить, насколько фрагментированы ваша база данных SQL Server и журналы транзакций. Если у Вас стоит Windows 2000 или 2003, Вы можете использовать для анализа встроенную утилиту дефрагментации, которая покажет вам, насколько фрагментированы ваши файлы. Если Вы используете сервер Windows NT 4.0, то Вам следует использовать утилиту стороннего производителя, например, Diskeeper от Executive Software, чтобы выполнять анализ.

Если в результате анализа вы получаете рекомендацию выполнить дефрагментацию, следует это сделать. К сожалению, дефрагментация базы данных файлов журнала транзакций SQL Server - не всегда простая задача. Открытые файлы, такие как база данных и журнал транзакций, обнаруженные на работающем SQL Server, не всегда могут быть дефрагментированы. Например, встроенная утилита дефрагментации не может выполнить дефрагментацию файлов MDF LDF SQL Server, а вот Diskeeper 8.0 во многих случаях может, но не во всех. Это означает, что в этих некоторых случаях Вам, вероятно, придется перевести SQL Server на автономную работу, чтобы выполнить дефрагментацию MDF и LDF файлов. В зависимости от того, насколько фрагментированы файлы и каков их размер, вам может потребоваться на это несколько часов.

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

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

Местоположение операционной системы

Для лучшей производительности файлы операционной системы должны находиться на дисковом массиве, на котором не находятся файлы данных SQL Server (MDB или LDF). Кроме того, они должны быть расположены на дисковом массиве, который поддерживает один из RAID - 1, 5, или 10.

В большинстве случаев я (как и большинство других людей) устанавливаю операционную систему на диске C: сервера. Я обычно конфигурирую диск C: как зеркальный диск RAID 1 для отказоустойчивости, а также для улучшения общей производительности.

В большинстве случаев, пока Вы не размещаете операционную систему на одном массиве с файлами данных SQL Server, Вы имеете большую свободу в размещении файлов операционной системы на вашем сервере.

Местоположение исполняемых модулей SQL Server

Местоположение исполняемых модулей SQL Server (бинарных файлов), как и местоположение файлов операционной системы, не является критическим, если они не расположены на одном массиве с файлами данных SQL Server. Как и в случае с файлами операционной системы, я обычно размещаю исполняемые модули SQL Server на диске C:, который в большинстве случаев конфигурируется как зеркальный диск RAID 1.

Если Вы строите кластер на SQL Server 7.0, то исполняемые модули SQL Server не могут быть расположены на диске C:, вместо их следует поместить на общедоступный (shared) массиве. К сожалению, зачастую это тот же самый массив, где Вы храните файлы данных SQL Server, если Вы не имеете достаточно денег, которые можете потратить на приобретение отдельного массива, используемого исключительно для исполняемых модулей. Хотя размещение исполняемых модулей на одном общедоступном массиве вместе с файлами данных SQL Server несколько отрицательно сказывается на производительности, это не слишком плохой компромисс, учитывая отказоустойчивость, которую Вы получаете взамен. С другой стороны, это серьезное основание для перехода на кластеризацию SQL Server 2000. Если Вы строите кластер на базе SQL Server 2000, то его исполняемые модули должны быть расположены на локальных дисках, а не на общедоступном массиве, что не вызывает проблем с производительностью.

Местоположение файла подкачки

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

Обычно я размещаю файл подкачки в одном массиве с операционной системой и исполняемыми модулями SQL Server, который, как я указал ранее, является дисковым массивом, который поддерживает RAID 1, RAID 5 или RAID 10. Как правило, это диск C:. Такое размещение значительно упрощает администрирование.

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

Местоположение базы данных tempdb

Если ваша база данных tempdb используется очень интенсивно, рассмотрите возможность перемещения этой базы на собственный массив, либо RAID 1, либо RAID 10, чтобы увеличить производительность дискового ввода-вывода. Избегите использования массивов RAID 5, поскольку они могут быть медленными при операциях записи данных, что является обычным побочным эффектом использования tempdb. Если Вы не можете перенести tempdb на отдельный массив, и если Вы хотите избежать размещения ее на одном массиве с файлами базы данных, рассмотрите возможность расположения этой базы на одном диске с операционной системой. Это поможет уменьшить общую конкуренцию за ввод-вывод и повысить производительность.

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

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

Местоположение системных баз данных

Системные базы данных (master, msdb, model) не подвергаются интенсивным операциям чтения и записи, поэтому размещение их на одном массиве с файлами данных SQL Server, как правило, не вызывает проблем с производительностью. Единственным исключением могут оказаться очень большие базы данных с сотнями или тысячами пользователей. В этом случае размещение их на отдельном массиве может несколько увеличить общую производительность системы ввода-вывода.

Местоположение пользовательских баз данных

Для лучшей производительности файлы пользовательских баз данных (MDB) должны быть расположены на их собственном массиве (RAID 1, 5 или 10), не содержащем всех других файлов данных, включая файлы журналов. Если Вы имеете много больших баз данных на одном SQL Server, рассмотрите возможность размещения каждого отдельного файла (файлов) базы данных на его собственном массиве для уменьшения конкуренции за ввод-вывод.

Местоположение журналов

В идеальном случае каждый журнал должен постоянно находиться на собственном отдельном массиве (RAID 1 или 10, RAID 5 будет замедлять запись в журнал транзакций больше, чем Вам этого хотелось бы). Причиной этого является тот факт, что большую часть времени в журналы транзакций выполняется последовательная запись и, если массив может писать данные последовательно (без необходимости прерываться, чтобы выполнять другие операции чтения и записи), то эта последовательная запись будет очень быстрой. Однако если массив не может писать последовательно, поскольку он должен выполнять случайный доступ для других операций чтения и записи, то производительность падает.

Конечно, наличие отдельного массива для каждого журнала обходится недешево, и часто может не оправдать себя. Тогда, по крайней мере, разместите все файлы журналов на массиве (RAID 1 или RAID 10), который не используется для файлов базы данных. Хотя производительность последовательной записи не будет столь хороша, какой могла бы быть при размещении каждого журнала на отдельный массив, это все же намного лучше, чем конкуренция за дисковый ввод-вывод с файлами данных.

Число контроллеров диска на сервере

Единственный контроллер диска, является ли он SCSI или оптоволоконным (fibre), имеет предел максимальный пропускной способности. По этой причине Вам захочется, чтобы число контроллеров диска соответствовало пропускной способности, которую Вы ожидаете. Поскольку один контроллер отличается от другого, я не могу рекомендовать Вам конкретные решения, разве что сказать, что по минимуму Вы захотите иметь два контроллера диска. Один контроллер должен использоваться не для привода жесткого диска, например, CD-ROM, устройств резервного копирования и так далее. Другой контроллер использовался бы для жесткого диска. Цель состоит в том, чтобы не сажать медленные и быстрые устройства на один и тот же контроллер.

Весьма часто Вы увидите следующий сценарий, который вполне хорош. Один контроллер не для привода жесткого диска, еще один контроллер используется для локального жесткого диска RAID 1, и третий (а иногда и больше) используется для массивов, которые содержат файлы базы данных и файлы журнала SQL Server. Убедитесь в том, что Вы не сажаете больше дисков на контроллер, чем он может обслужить. Хотя это и будет работать, производительность пострадает.

Тип контроллеров диска на сервере

Всегда покупайте самый быстрый контроллер дисков, который Вы можете себе позволить при условии, что Вы намереваетесь получить максимальную производительность SQL Server. Как вы, вероятно, знаете, различные контроллеры диска имеют различные характеристики производительности. Например, есть различные типы SCSI, а именно, Wide SCSI, Narrow SCSI, Ultra SCSI и так далее. То же самое можно сказать, хотя и в меньшей степени, о волоконных подключениях.

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

Размер кэша в контроллерах диска на сервере

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

Включен ли на контроллере диска кэш обратной записи?

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

Хотя существуют контроллеры, которые имеют батареи резервного питания для предотвращения подобных проблем, они не всегда работают так, как ожидается. Лично, я предпочитаю неповрежденные данные (записанные более медленно), чем поврежденные данные (который были записаны намного быстрее). Другими словами, я рекомендую выключать кэширование обратной записи на вашем контроллере дисков даже несмотря на то, что Вы немного потеряете в производительности.

Скорость дисководов

Дисководы, которые входят в ваши массивы, могут часто иметь различные скорости. Как и следует ожидать, для лучшей производительности, лучше всегда покупать самые быстрые диски. Обычно они имеют 15 000 оборотов в минуту и выше. Кроме того, не следует смешивать диски с различными скоростями в одном массиве. Производительность пострадает, если вы сделаете это.

Сколько сетевых карт находится на вашем сервере?

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

Какова скорость сетевых карт на сервере?

По минимуму, ваш сервер должен иметь 100Mbs сетевые карты. Карты на десять мегабит не обеспечат вас необходимой пропускной способностью. Если одна или более 100MBs карт не дают достаточной пропускной способности, то рассмотрите вопрос приобретения гигабитных карт. В этом случаи Вы могли бы вообще отказаться от использования 100MBs карт и использовать вместо них только гигабитные карты. Использование более быстрой сетевой карты не ускоряет сетевой трафик, это лишь позволяет пропускать трафик большего объема, что, в свою очередь, позволяет вашему серверу работать с оптимальной производительностью.

Жестко ли установлены на сетевой карте скорость/дуплекс?

Если Вы имеете двойную 10/100 или 10/100/1000 карту на SQL Server, который должен автоматически определять скорость сети и устанавливать соответствующие настройки, не следует доверять тому, что это будет работать правильно. Довольно обычным для сетевой карты является то, что автоопределение работает неправильно, устанавливая скорость меньше оптимальной или полудуплексную установку, которая может значительно понизить производительность сети. То, что Вы должны сделать, это вручную установить скорость платы и полнодуплексную (full-duplex) установку. В этом случае Вы будете знать наверняка, что все будет работать правильно.

Используется ли в сети коммутатор?

Это должно быть очевидным в большом центре данных, но для небольших организаций, концентратор все еще может использоваться для подключения к серверу. Если это так, серьезно отнеситесь к замене концентратора на соответствующим коммутатор (switch), и конфигурируйте его для соединения с максимально возможной производительностью, например, 100MBs и полный дуплекс. Переход от концентратора на коммутатор может серьезно изменить производительность сети в лучшую сторону.

Обновлены ли драйверы аппаратных средств до последних версий?

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

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

Специализирован ли физический сервер под SQL Server?

Я уже упоминал это прежде, и не могу повторять это слишком часто. SQL Server должен исполняться на специализированном физическом сервере, не деля его с другим прикладным программным обеспечением. Когда Вы совместно используете SQL Server с другим программным обеспечением, Вы вынуждаете SQL Server бороться за физические ресурсы, в результате чего Вам будет более трудно настроить ваш сервер на оптимальную производительность. Снова и снова, когда я получаю вопросы о низкой производительности SQL Server, я выясняю, что ответственным за это является другое приложение, выполняющееся на том же самом сервере. Вам следует только научиться говорить НЕТ.

Что теперь?

Мы много уже прошли, но нам много еще остается. Когда я первоначально оцениваю производительность SQL Server и выполняю аудит производительности, я делаю подробные заметки обо всех моментах, обсуждаемых выше. Затем я выполняю сравнение конфигурирования сервера с идеальной конфигурацией, а потом ищу простые способы приближения к этой идеальной конфигурации. Иногда это просто (очевидно, что легко исправлять сделанные ошибки), а иногда не так много можно и сделать. Но Вы не будете этого знать, если не выполните аудит.

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

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

На главную страницу

Print  Версия для печати


Usage of any materials of this site is possible
only under condition of mandatory allocation of the direct link to a site
http://www.sqlbooks.ru
on each page where used materials are placed.

 Main   Articles    Books 
Рейтинг@Mail.ru Rambler's Top100 Alt Упражнения по SQL: обучение, тестирование, сертификация по языку SQL Copyright c 2002-2006. All rights reserved.