phone +7 (495) 66 014 66

× Общий раздел

Анализ производительности и оптимизация работающей многопользовательской системы

4 года 9 мес. назад #4935 от Дмитрий
В статье рассматривается базовая методика анализа проблем производительности в работающей многопользовательской системе при помощи "Центра управления производительностью".

В настоящей статье рассматривается методика анализа производительности и оптимизации реально работающей многопользовательской системы на платформе "1С:Предприятие 8".

Данная методика будет наиболее полезна в следующих случаях:
• Проблемы производительности не локализованы в определенных бизнес-процессах, а "равномерно распределены" по всей функциональности системы. Все (или почти все) пользователи жалуются на недостаточную производительность системы, но не могут назвать одну конкретную операцию, производительность которой их не устраивает. Субъективная оценка формулируется так: "все работает медленно".
• В системе имеются четко локализованные проблемы производительности, которые не воспроизводятся на тестовой базе в однопользовательском режиме. Например, пользователи жалуются на недостаточную производительность документа "РеализацияТоваровУслуг", но при проведении этого документа в нерабочее время и/или на тестовой базе производительность оказывается в норме.
• В системе имеется большое количество хорошо локализованных проблем производительности. Задача заключается в том, чтобы максимально быстро определить, с чего именно следует начинать оптимизацию системы. Необходимо обнаружить источник (или источники) всех имеющихся проблем и найти наиболее узкое место в системе.
• Система запускается в рабочую эксплуатацию после существенного изменения условий работы системы:
o изменилась нагрузка на систему;
o изменилась конфигурация;
o изменилась используемая версия "1С:Предприятия";
o изменилась используемая СУБД;
o изменилась конфигурация оборудования;
o и т. п.
• На начальном этапе эксплуатации системы ее производительность была признана удовлетворительной, но по мере наполнения информационной базы производительность стала падать.
• Планируется увеличение нагрузки на систему, и необходимо гарантировать отсутствие в системе скрытых проблем, которые могут привести к падению производительности при росте нагрузки.
• Система стабильно работает с удовлетворительной производительностью. Необходимо гарантировать своевременную и точную диагностику проблем производительности в случае их возникновения.
Кроме того, методику рекомендуется использовать при проведении многопользовательского нагрузочного тестирования системы с целью оценки производительности, анализа возникающих проблем и оптимизации системы.

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

Неудовлетворительная производительность
Критерии:
• Производительность системы не удовлетворяет требованиям бизнес-логики автоматизируемого предприятия на значительной части операций.
• Большая часть пользователей системы жалуется:
o На неприемлемую общую производительность системы.
o Неприемлемую производительность на отдельных операциях.
o Внезапное ухудшение производительности.
o Частое возникновение ошибок:
 "Lock request time out period exceeded".
 "Превышено максимальное время ожидания предоставления блокировки".
 "Transaction was deadlocked on lock resources with another process and has been chosen as deadlock victim".
 "Конфликт блокировок при выполнении транзакции".
Недостаточная производительность
Наблюдаются аналогичные симптомы, но возникающие реже либо проявляющиеся не в такой серьезной форме.

Удовлетворительная производительность

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

Регламентные операции

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

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

Анализ загруженности оборудования

Если производительность системы признана удовлетворительной, то этот шаг можно пропустить. Переходите к следующему шагу: мониторингу производительности системы.

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

Если в результате анализа будет выявлена чрезмерная загруженность оборудование, то производительность системы может быть повышена путем аппаратного апгрейда (увеличения производительности аппаратного компонента, который является узким местом).

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

Мониторинг производительности системы

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

Мониторинг производительности системы рекомендуется использовать в том случае, если текущая производительность признается удовлетворительной.

Мониторинг позволит решить следующие задачи:
• Собирать и накапливать объективную информацию о производительности системы.
• Оперативно диагностировать проблемы производительности.
• Выявлять скрытые проблемы производительности. При определенных условиях (например, в начале работы системы, когда информационная база содержит незначительное количество данных) система может работать неоптимально, но пользователи системы не будут этого замечать. Впоследствии эти скрытые проблемы могут проявиться.
Для решения этой задачи рекомендуется использовать Центр управления производительностью, входящий в состав 1С:Корпоративного инструментального пакета.

Рекомендуемая последовательность действий

1. Подключитесь к исследуемой информационной базе при помощи ЦУП в режиме "Мониторинг".
Подробные инструкции по подключению см. в книге "1С:Корпоративный инструментальный пакет 8. Редакция 1.1. Руководство по использованию", стр. 37.
2. Включите сбор следующих показателей производительности:
• Запросы \ Максимальное время выполнения запроса;
• Запросы \ Среднее время выполнения запроса;
• Ожидания на блокировках \ Только блокировки СУБД \ Среднее время ожидания на блокировке СУБД;
• Ожидания на блокировках \ Только блокировки СУБД \ Количество таймаутов;
• Ожидания на блокировках \ Только блокировки 1С \ Среднее время ожидания на блокировке 1С;
• Взаимоблокировки \ Количество взаимоблокировок.



Подробные инструкции см. там же, на стр. 41.
3. Включите запись всех показателей производительности (см. там же, на стр. 45).



4. Рекомендуется осуществлять постоянный мониторинг и вести запись показателей в течение всего "срока жизни" системы.

Оценка значений показателей, поиск симптомов проблем

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

Симптом 1

Значения показателя "Среднее время ожидания на блокировке СУБД" близки к значениям показателя "Среднее время выполнения запроса". Это означает, что большую часть времени система простаивает в ожиданиях на блокировках СУБД. Если время ожиданий составляет 50 % от времени выполнения запросов, то проблему необходимо расследовать. Если это соотношение еще больше, то проблема является серьезной.



Симптом 2

Не равны нулю значения следующих показателей:
• "Количество взаимоблокировок";
• "Количество таймаутов".

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



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




Симптом 4

Наблюдается постепенный значительный рост или внезапный "всплеск" значений следующих показателей:
• "Среднее время выполнения запроса";
• "Среднее время ожидания на блокировке СУБД";
• "Среднее время ожидания на блокировке 1С".

Это означает, что производительность системы со временем ухудшается, что может свидетельствовать о наличии в системе неоптимальных запросов.



Анализ проблем производительности и оптимизация системы


Анализ проблем производительности и оптимизация системы состоят из следующих основных этапов:
• Сбор аналитической информации о проблемах производительности;
• Цикл по основным проблемам производительности в порядке убывания их важности (степени влияния на общую производительность системы);
• Анализ проблем, обнаруженных в данной строке кода.

Сбор аналитической информации о проблемах производительности

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

Для этого следует выполнить следующую последовательность действий:
1. Добавить к списку показателей все показатели производительности, входящие в группу "Анализ".



Вы можете не добавлять в список показатель "Анализ взаимоблокировок" в том случае, если уверены, что взаимоблокировок в системе нет. Например, система работала в однопользовательском режиме или в многопользовательском режиме не наблюдалось отличное от нуля значения показателя "Количество взаимоблокировок".

Вы можете не добавлять в список показатель "Анализ ожиданий на блокировках" в том случае, если вы уверены, что в системе нет ожиданий на блокировках. Например, система работала в однопользовательском режиме или в многопользовательском режиме значения показателей "Суммарное время ожидания на блокировках СУБД" и "Суммарное время ожидания на блокировках 1С" было близко к нулю.

Это позволит несколько уменьшить количество информации, собираемой ЦУП, и сократит время ее обработки.

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

ВНИМАНИЕ!
Включение записи аналитических показателей может привести к замедлению работы системы.

3. Собирать аналитическую информацию в течение необходимого и достаточного периода времени
Период сбора аналитической информации необходимо выбирать исходя из следующих факторов:
• Время сбора аналитической информации не может быть менее 1 минуты. Рекомендуемое минимальное время – 2 минуты.
• За время сбора информации должна успеть проявиться значительная часть наблюдающихся в системе проблем. То есть период сбора информации должен быть достаточно большим.
• Чем дольше собирается аналитическая информация, тем дольше она будет анализироваться. То есть период сбора информации не должен быть слишком большим.
Как правило, для сбора исчерпывающей информации по основным проблемам, имеющимся в системе, достаточно включить запись аналитических показателей на 10–15 минут.
4. Отключить запись аналитических показателей
После отключения записи аналитических показателей ЦУП произведет анализ собранных данных и поместит результаты анализа в свою информационную базу. Время анализа данных пропорционально периоду сбора аналитической информации и может быть значительным.

Цикл по основным проблемам производительности

Для анализа проблем производительности и оптимизации системы необходимо выполнить следующую последовательность действий.
1. Перейти в режим анализа собранной информации
Для этого необходимо подключиться к исследуемой базе в режиме "Просмотр". Если отключение мониторинга нежелательно (необходимо обеспечить постоянный мониторинг производительности в исследуемой базе), то следует открыть новое соединение с информационной базой ЦУП и подключиться к исследуемой базе в режиме "Просмотр".
2. Выбрать период времени, на котором собиралась аналитическая информация
Для упрощения работы с различными периодами времени рекомендуется использовать закладки. См. "Руководство по использованию", стр. 60.
3. Открыть форму анализа проблем производительности

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

4 года 9 мес. назад #4936 от Дмитрий
4. Анализировать источники проблем в разрезе строк кода конфигурации, начиная с наиболее "тяжелых" проблем

Следует анализировать проблемы в разрезе строк кода конфигурации. Для справки во время анализа можно использовать информацию о проблемах в разрезе структуры данных.

Источники проблем (строки кода) следует анализировать сверху вниз – в порядке убывания общего веса проблем, относящихся к данному источнику.



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

После того как будет завершен анализ и проведена оптимизация 80 % (по весу) источников проблем, рекомендуется повторно оценить текущую производительность системы и при необходимости повторить весь цикл анализа производительности заново.

Анализ проблем, обнаруженных в данной строке кода

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



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

• Типичные причины неоптимальной работы запросов и методы оптимизации
• Типичные причины возникновения избыточных блокировок и методы оптимизации
• Анализ и устранение взаимоблокировок
Вложения:

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Время создания страницы: 0.266 секунд