18.08.2010
В статье рассматривается базовая методика анализа проблем производительности в работающей многопользовательской системе при помощи "Центра управления производительностью".
В настоящей статье рассматривается методика анализа производительности и оптимизации реально работающей многопользовательской системы на платформе "1С:Предприятие 8".
Данная методика будет наиболее полезна в следующих случаях:
Кроме того, методику рекомендуется использовать при проведении многопользовательского нагрузочного тестирования системы с целью оценки производительности, анализа возникающих проблем и оптимизации системы.
Оцените текущую производительность системы на основании прикладных критериев. После этого последовательно выполните все нижеследующие рекомендации по шагам. В зависимости от того, как оценивается текущая производительность системы, некоторые шаги могут быть пропущены.
Критерии:
Наблюдаются аналогичные симптомы, но возникающие реже либо проявляющиеся не в такой серьезной форме.
Пользователи системы практически не жалуются на проблемы производительности. Однако нет уверенности в том, что система работает оптимально. Возможно, есть скрытые проблемы производительности, которые пока не проявились в явном виде.
В любом случае необходимо убедиться в том, что все необходимые регламентные операции правильно запланированы и своевременно выполняются.
Если производительность системы признана неудовлетворительной или недостаточной, имеет смысл однократно выполнить все рекомендуемые регламентные операции и после этого повторно оценить производительность системы.
Рекомендации по выполнению регламентных операций для систем, работающих с использованием MS SQL Server (статья в базе знаний).
Если производительность системы признана удовлетворительной, то этот шаг можно пропустить. Переходите к следующему шагу: мониторингу производительности системы.
Если производительность системы признается неудовлетворительной или недостаточной, то необходимо провести анализ загруженности оборудования в соответствии с данными рекомендациями базы знаний.
Если в результате анализа будет выявлена чрезмерная загруженность оборудование, то производительность системы может быть повышена путем аппаратного апгрейда (увеличения производительности аппаратного компонента, который является узким местом).
Если этот путь является нецелесообразным или несвоевременным (например, ввиду высокой стоимости апгрейда), то следует переходить к оптимизации системы. Если аппаратный апгрейд был проведен и не принес достаточного прироста производительности, следует также переходить к оптимизации системы.
Если производительность системы признана неудовлетворительной или недостаточной, то этот шаг можно пропустить. Переходите непосредственно к оптимизации системы.
Мониторинг производительности системы рекомендуется использовать в том случае, если текущая производительность признается удовлетворительной.
Мониторинг позволит решить следующие задачи:
Для решения этой задачи рекомендуется использовать Центр управления производительностью, входящий в состав 1С:Корпоративного инструментального пакета.
1. Подключитесь к исследуемой информационной базе при помощи ЦУП в режиме "Мониторинг".
Подробные инструкции по подключению см. в книге "1С:Корпоративный инструментальный пакет 8. Редакция 1.1. Руководство по использованию", стр. 37.
2. Включите сбор следующих показателей производительности:
Подробные инструкции см. там же, на стр. 41.
3. Включите запись всех показателей производительности (см. там же, на стр. 45).
4. Рекомендуется осуществлять постоянный мониторинг и вести запись показателей в течение всего "срока жизни" системы.
Для того чтобы понять, имеются ли в системе проблемы производительности, необходимо иметь критерии оценки полученных значений показателей. В настоящей главе перечислены основные симптомы проблем производительности в работающих многопользовательских системах. В том случае, если в системе наблюдаются симптомы проблем производительности, следует переходить к анализу проблем и оптимизации системы.
Значения показателя "Среднее время ожидания на блокировке СУБД" близки к значениям показателя "Среднее время выполнения запроса". Это означает, что большую часть времени система простаивает в ожиданиях на блокировках СУБД. Если время ожиданий составляет 50 % от времени выполнения запросов, то проблему необходимо расследовать. Если это соотношение еще больше, то проблема является серьезной.
Не равны нулю значения следующих показателей:
Это означает, что в системе наблюдаются взаимоблокировки и/или таймауты, то есть пользователи получают соответствующие сообщения об ошибках.
В течение длительного времени наблюдается практически линейный рост показателя "Максимальное время выполнения запроса", после чего следует его падение до обычных значений. Это означает, что в системе выполнялся один или несколько длительных запросов, которые, вероятно, могут быть оптимизированы.
Наблюдается постепенный значительный рост или внезапный "всплеск" значений следующих показателей:
Это означает, что производительность системы со временем ухудшается, что может свидетельствовать о наличии в системе неоптимальных запросов.
Анализ проблем производительности и оптимизация системы состоят из следующих основных этапов:
Если производительность системы признана неудовлетворительной (или недостаточной) или в результате мониторинга производительности обнаружены симптомы проблем производительности, необходимо собрать аналитическую информацию о проблемах.
Для этого следует выполнить следующую последовательность действий:
Вы можете не добавлять в список показатель "Анализ взаимоблокировок" в том случае, если уверены, что взаимоблокировок в системе нет. Например, система работала в однопользовательском режиме или в многопользовательском режиме не наблюдалось отличное от нуля значения показателя "Количество взаимоблокировок".
Вы можете не добавлять в список показатель "Анализ ожиданий на блокировках" в том случае, если вы уверены, что в системе нет ожиданий на блокировках. Например, система работала в однопользовательском режиме или в многопользовательском режиме значения показателей "Суммарное время ожидания на блокировках СУБД" и "Суммарное время ожидания на блокировках 1С" было близко к нулю.
Это позволит несколько уменьшить количество информации, собираемой ЦУП, и сократит время ее обработки.
Запись показателей необходимо включать в то время, когда в системе наблюдаются проблемы производительности. Если проблемы наблюдаются не всегда, а только эпизодически (в определенных режимах работы, в период предельной загрузки системы и т. д.), то следует включать сбор аналитической информации именно в это время.
ВНИМАНИЕ!
Включение записи аналитических показателей может привести к замедлению работы системы.
Период сбора аналитической информации необходимо выбирать исходя из следующих факторов:
Как правило, для сбора исчерпывающей информации по основным проблемам, имеющимся в системе, достаточно включить запись аналитических показателей на 10–15 минут.
После отключения записи аналитических показателей ЦУП произведет анализ собранных данных и поместит результаты анализа в свою информационную базу. Время анализа данных пропорционально периоду сбора аналитической информации и может быть значительным.
Для анализа проблем производительности и оптимизации системы необходимо выполнить следующую последовательность действий.
Для этого необходимо подключиться к исследуемой базе в режиме "Просмотр". Если отключение мониторинга нежелательно (необходимо обеспечить постоянный мониторинг производительности в исследуемой базе), то следует открыть новое соединение с информационной базой ЦУП и подключиться к исследуемой базе в режиме "Просмотр".
Для упрощения работы с различными периодами времени рекомендуется использовать закладки. См. "Руководство по использованию", стр. 60.
Следует анализировать проблемы в разрезе строк кода конфигурации. Для справки во время анализа можно использовать информацию о проблемах в разрезе структуры данных.
Источники проблем (строки кода) следует анализировать сверху вниз – в порядке убывания общего веса проблем, относящихся к данному источнику.
Для каждого источника (строки кода конфигурации) следует провести анализ проблем, обнаруженных в данной строке кода "Центром управления производительностью".
После того как будет завершен анализ и проведена оптимизация 80 % (по весу) источников проблем, рекомендуется повторно оценить текущую производительность системы и при необходимости повторить весь цикл анализа производительности заново.
Откройте второй уровень дерева источников проблем для выбранной строки кода конфигурации. Он отображает все виды проблем, зафиксированные в данной строке кода, и вес проблем каждого вида.
Виды проблем расположены в порядке убывания веса. Пользуясь рекомендациями, данными ниже по ссылкам, проведите анализ и оптимизацию кода конфигурации и структуры метаданных в зависимости от вида проблем, обнаруженного ЦУП в данной строке кода. Если в данной строке обнаружены проблемы разных видов, то рекомендуется начинать анализ с проблем, имеющих больший вес.