1. Первое, что необходимо проверить, это наличие свободного места на дисках. Начать можно с использования Проводника Windows:
Проверка свободного места на диске
Также можно проанализировать объем, занимаемый папкой, в которой размещена БД.
Более детальный анализ можно провести с помощью Microsoft SQL Management Studio — выбрав БД "Первой Формы", можно проанализировать ее свойства ("Properties" – "Files"). Для удобства список таблиц БД можно упорядочить по размеру и проанализировать несколько самых крупных. Следует принимать во внимание не только текущий размер таблицы, то так же и темп ее прироста, а также как часто проводится удаление лишних записей и насколько такая чистка уменьшает размер таблицы. Исходя из этих данных можно рассчитать объем БД на некоторый срок вперед (например, на год) и спланировать масштабирование сервера БД.
Анализ БД с помощью SQL Management Studio
2. Затем надо проверить загрузку процессора и отдельно каждого ядра (состояние ОП можно не анализировать, поскольку SQL Server потребляет всю доступную память). Для этого удобно использовать Диспетчер задач. На высоконагруженном сервере загрузка процессора не должна постоянно находиться на уровне свыше 30-40% (речь идет именно о постоянной загрузке, а не о пиках).
Поскольку в "Первой Форме" практически не используется распараллеливание запросов, в многоядерных системах в свойствах SQL Server рекомендуется установить значение параметра Max Degree of Parallelism равным 1 (один запрос выполняется на одном ядре). Поэтому если в Диспетчере задач загрузка одного из ядер длительное время остается близка к 100%, то скорее всего это свидетельствует о "зависании" какого-то запроса.
3. Большую часть работ по анализу производительности SQL Server удобно проводить в Activity Monitor (входит в состав SQL Server Management Studio).
Переход в Activity Monitor
3.1. На панели Active User Tasks целесообразно отслеживать: активные (запущенные) запросы и потребляемое ими процессорное время; запросы, ожидающие выполнения; операции ввода-вывода; количество запросов к БД в секунду.
Список активных запросов можно сортировать по их текущему состоянию (Task State): выполняемые задания (Running) свидетельствуют о нормальной работе сервера БД. Состояние "Приостановлен" (Suspended) означает, что-то в настоящий момент запрос не может быть выполнен из-за нехватки ресурсов. Само по себе наличие приостановленных запросов не доказывает наличие проблемы, но заслуживает отдельного внимания: при нормальном состоянии сервера БД такие запросы должны достаточно быстро переходить в статус "Выполняется". Если же один и то же запрос длительное время находится в статусе "Приостановлен", это должно стать поводом для детального анализа причин.
3.2. О возможном наличии проблем говорит и большое количество операций ввода\вывода на панели Data File I/O:
Панель Data File I/O
а также большое (свыше 1000) количество фоновых заданий (Batch Requests) на панели Overview:
Панель Overview
3.3. На панели Recent Expensive Queries отображаются наиболее ресурсоемкие запросы за последние 30 сек. Их удобно сортировать по среднему времени выполнения (Average Duration) — оно не должно превышать 1 сек., или по числу запусков запроса за одну минуту (Executions/min) — даже если запрос выполняется быстро, но слишком часто, он все равно отнимает много ресурсов.
Панель Recent Expensive Queries
3.4. На панели Resource Waits собраны данные о запросах, которые находятся или недавно находились в состоянии ожидания освобождения каких-либо серверных ресурсов. Если совокупное время ожидания (Wait Time) какого-либо ресурса превышает 50 мсек\сек (по одному ядру процессора), то необходимо проанализировать возможные причины.
Панель Resource Waits
3.5. Наиболее полезными и информативными отчетами для анализа производительности являются Top Queries by total CPU и Top Queries by total I\O, которые доступны в Activity Monitor в меню стандартных отчетов (Standard Reports – Performance). Они отображают совокупное время на выполнение запросов и среднее время выполнения. В нормальном состоянии сервера даже для наиболее ресурсоемких запросов среднее время выполнения не превышает 100 мсек. Еще одним показателем нормальной работы является отсутствие ярко выраженных "чемпионов" — запросов, которые потребляют ресурсы в несколько раз больше, чем другие.
3.6. Оптимальным вариантом является предоставление экземпляра SQL Server в исключительное пользование "Первой Форме". Но если это невозможно (например, из-за ограничений количества лицензий) и один SQL Server обслуживает несколько приложений, то необходимо постоянно следить за тем, относятся ли наиболее ресурсоемкие запросы к приложению "Первая Форма". Это можно сделать, просматривая детальную информацию по запросам как непосредственно из отчета в Activity Monitor, так и выгрузив результаты отчета в Excel.
3.7. Стандартные отчеты в составе Activity Monitor не показывают данные по абсолютно всем запущенным запросам, а включают лишь некоторое количество "топовых" запросов. Чтобы посмотреть полную информацию по загрузке сервера нужно использовать дополнительные инструменты — например, отчеты Blitz в режиме администрирования "Первой Формы" или отдельную утилиту BlitzCache от компании Baltazar). Эта программа не только выдает общие рекомендации по оптимизации запросов, но также позволяет оценить совокупное потребление ресурсов по каждому запросу, что иногда помогает выявить проблемные ситуации (например, запрос может потреблять не слишком много времени процессора и поэтому не входит в список "топовых" запросов, но при этом он выполняется довольно часто и в совокупности потребляет большой объем ресурсов).
4. В заключение можно рекомендовать оценить количество записей в основных таблицах БД. Это можно сделать в интерфейсе администратора "Первой Формы", в разделе "Таблицы БД" (меню "Прочее" — "Журналы и статистика"). Наиболее показательны таблицы Comments ("Комментарии"), CommentRecipients ("Получатели уведомлений и комментариев"), Tasks ("Задачи"), ExtParamValues ("Значения ДП"). Полезным будет регулярное сохранение этих данных в Excel для последующего сравнения — таким образом можно оценить прирост объемов и спрогнозировать потребление ресурсов.
Информация о таблицах БД в режиме администрирования "Первой Формы"
Также ценную информацию можно извлечь из анализа регулярно выполняемых заданий (меню "Прочее" — "Системные настройки" — "Задания по таймеру"). Если задание длительное время находится в состоянии EXECUTING (оценить это время можно по показателю в колонке "Предыдущий запуск"), то велика вероятность того, что оно "зависло", а это может вызвать значительные задержки на SQL Server. Чтобы выявить подобную связь, надо сравнивать время пиковой нагрузки на SQL Server со временем запуска одного из таких "зависших" заданий.
Информация о заданиях по таймеру в режиме администрирования "Первой Формы"
Полезные ссылки
