Главная » Microsoft SQL Server, Базы данных » Ключевой индикатор производительности базы данных

0

Ключевой индикатор производительности (далее KPI) базы данных является единственным полноценным показателем, способным оценить общую производительность базы на уровне управления в течение времени.

Единообразие является критичным фактором в оценке любого KPI. Определение базового уровня, а затем постоянное повторение абсолютно того же измерения является единственным способом выявления тенденций и оценки результатов оптимизации. При этом тесты должны повторяться через регулярные промежутки времени.

Ключевой индикатор производительности должен сравнивать данные, полученные в “чистой” тестовой среде, а также фактические данные, принимая во внимание эффект масштабирования системы. Чтобы получить реальный индикатор KPI, команда разработчиков должна предъявить особые требования к тестам и методам вычисления. Я рекомендую масштабировать результаты трех последовательных тестов, чтобы получить в результате каждого одну треть и чтобы их сумма, т.е. изначальная полноценная метрика, составляла единицу, как показано на рабочем листе и диаграмме рис. 49.7.

Puc. 49.7. Ключевой индикатор производительности вычисляется на основе трех тестов в программе Excel

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

Периодическое тестирование производительности

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

Если архитектура использует уровень абстракции данных, то все вызовы тестов должны выполняться именно к нему. Если же база данных использует более необычный подход с помощью модели “клиент/сервер”, то при тестировании придется смешивать различные запросы. Если база данных использует архитектуру, ориентированную на Web-службы, естественно, потребуются запросы именно к этим службам. Для балансировки операций извлечения и обновления данных для таблиц потребуется создать достаточно представительную выборку, учитывающую особенности клиентских приложений и пакетных процессов.

Изначальное выполнение повторяющегося теста производительности устанавливает базовую линию измерения. При каждом последующем выполнении теста исходная база данных восстанавливается и запускается исходный сценарий. Повторяющийся тест производительности наиболее полезен для оценки результатов оптимизации в “чистой” среде — т.е. неподверженной другим процессам, недоступной другим пользователям и изменениям данных.

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

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

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

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

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

Измеряя реальное время отклика хранимых процедур уровня абстракции данных, тест производительности в производственной среде собирает информацию о деятельности пользователей.

Данные о производительности в производственной среде можно собирать несколькими способами.

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

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

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

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

Тестирование влияния масштабирования на производительность

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

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

СУБД SQL Server оптимизирована для интеллектуального кэширования данных

На заметку в памяти, что влияет на последующие тесты. Память может быть пополнена с помощью остановки и перезапуска сервера, а также с помощью команд dbcc DropCleanBuffersИ DBCC FreeProcCache.

В пакет обновлений SP1 были добавлены новые динамические представления Внимание! управления, выполняющие мониторинг выделения памяти для запросов, —

sys.dm_exec_query_memory_grants и sys.dm_exec_query_resource_ semaphores.

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

Резюме

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

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

Анализ запросов и настройка индексов

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

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

Индексам теория оптимизации отводит средний уровень. Они зависят от качества проектирования нормализованной схемы и запросов. Без этих двух составляющих сложно ожидать от индексации хороших результатов.

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

Анализ запросов и настройка индексов являются областью, в которой СУБД SQL Server 2005 преуспела. Сервер предоставляет обширную информацию о плане выполнения запроса, его индексы быстры, строятся по алгоритму сбалансированного дерева, их легко настраивать, и даже без всякой настройки они прекрасно работают.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии