Оптимизация производительности ЦП SQL Server

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

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

Два пути, ведущие в одно место

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

Разработка
гиперпоточности

На технологии гиперпоточности стоит тормознуть из-за того, как
она оказывает влияние на SQL Server. Разработка гиперпоточности практически
предоставляет операционной системе для 1-го физического микропроцессора
два логических микропроцессора. На самом деле, разработка гиперпоточности
арендует время физических микропроцессоров для полного использования
способностей каждого микропроцессора. На веб-узле Intel (intel.com/technology/platform-technology/hyper-threading/index.htm)
представлено еще более подробное описание работы технологии
гиперпоточности.

В системах SQL Server DBMS практически обрабатывает собственные
очень действенные очереди и потоки для операционной системы,
потому в системах с уже имеющейся высочайшей загрузкой микропроцессоров
разработка гиперпоточности только еще более перегружает физические
ЦП. Когда SQL Server производит постановку в очередь нескольких
запросов для работы с несколькими планировщиками, операционной
системе приходится переключать контекст потоков команд для
обеспечения соответствия выполняемым запросам, даже если два
логических микропроцессора принадлежат одному физическому микропроцессору.
Если показатель «Контекстных переключений/сек» превосходит 5000 для
1-го физического микропроцессора, следует серьезно разглядеть вопрос
об выключении гиперпоточности в системе и повторном тестировании
производительности.

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

Главные
моменты

Производительность массивного двухъядерного
микропроцессора всегда будет превосходить производительность ОЗУ
компьютера, скорость которого в свою очередь будет больше скорости
присоединенного запоминающего устройства. Пропускная способность
неплохого микропроцессора примерно в 6 раз превосходит
пропускную способность наилучшей современной памяти DDR2 и
примерно вдвое превосходит пропускную способность наилучшей
памяти DDR3. Пропускная способность обыкновенной памяти более чем в 10
раз превосходит пропускную способность самых стремительных оптоволоконных
приводов. В свою очередь, жесткие диски могут делать только
ограниченное число операций ввода/вывода за секунду (IOPS), это
значение всецело находится в зависимости от количества операций поиска за секунду,
которое может делать привод. Справедливости ради нужно сказать,
что для ублажения всех потребностей в хранении систем баз
данных компаний обычно употребляется несколько устройств хранения.
Сейчас в большинстве установок употребляются сети хранилищ данных
(SAN) на серверах баз данных компаний либо группы RAID большего
размера, которые могут минимизировать либо убрать делему
микропроцессора дискового ввода-вывода. Принципиально держать в голове, что независимо от
особенностей установки системы узенькие места со стороны дисков и
памяти могут воздействовать на производительность микропроцессоров.

Из-за различий в скорости ввода-вывода получение
данных с диска намного дороже, чем получение данных из памяти.
Размер странички данных в SQL Server – 8 КБ. Блок в SQL Server
состоит из восьми страничек размером 8 КБ любая и соответственно
имеет размер 64 КБ. Это принципиально осознавать, так как когда SQL Server
запрашивает определенную страничку данных с диска, производится
получение всего блока, в который заходит страничка данных, а не только лишь
этой определенной странички. Существует ряд обстоятельств, делающих это
более действенным для SQL Server, но в данной статье я не будут
рассматривать этот вопрос тщательно. Получение странички данных, уже
кэшированной из буферного пула, с наибольшей производительностью
произво