Тренд современного времени – рост информационных потоков внутри компании, он достигается за счет многих факторов: рост количества пользователей, рост числа автоматизированных бизнес-процессов, рост количества бизнес единиц (филиалы, торговые площадки, дополнительные офисы, склады). Необходимо непрерывно иметь доступ к необходимой информации, от этого зависит оптимальность того или иного решения, прибыльность компании. Организовать непрерывный доступ не всегда получается. Связано это может быть со сбоями в ПО и оборудовании, с различными нагрузками (регламентные мероприятия, например, в системе 1С 8.x это может быть закрытие месяца, расчет себестоимости, расчет заработной платы; предпраздничные распродажи, акции и прочее). Как же разобраться в причинах проблем производительности и максимально оперативно их решить?
Для этого с помощью различных инструментов собирают информацию о показателях производительности информационной системы (в нашем случае мы используем мониторинг производительности PerfExpert, имеющий тесную интеграцию с такими информационными системами как 1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) и анализируют с поиском «узких» мест в производительности. Учитывая, что информация собирается в большом количестве из различных источников (счетчики производительности Windows, MS SQL Server, процессы нагрузки SQL Server, тяжелые и неоптимальные запросы SQL, нагрузка пользовательских сессий), ее необходимо группировать и ранжировать по степень важности.
В нашей практике анализ и, что особенно важно, визуальное представление информации давало возможность найти закономерность поведения, а это в свою очередь позволяло выйти на причину сбоев.
Приведу один из примеров: один из наших многоуважаемых клиентов жаловался на зависание информационной системы при открытии окна документа «Расходная Накладная», мы как обычно, провели анализ кода средствами встроенного отладчика – не нашли никаких проблем, проводили синтетическое тестирование – торможение практически никогда не происходило, пока не разработали обработку, которая с равным периодом открывало окно документа и сохраняла длительности этих открытий. С первого взгляда «криминала» не было, менее 2% открытий открывались неприемлемо долго. Но как только мы создали диаграмму в Excel на основе данных мы заметили интересную закономерность.
Как видно из рисунка 1, лишь небольшое количество открытий форм документа происходит значительно медленнее обычного, но обратите внимание, что моменты этих замедлений повторяются с практически одинаковой периодичностью – это дало возможность найти причину медленной работы – фоновая задача, повторяющаяся каждые 2 минуты. На этом примере хотелось бы показать, как важно правильно и эффективно работать с статистической информацией.
В качестве второго примера хотелось бы показать, как наша компания ведет анализ и решает проблемы производительности у клиентов. Не секрет, что пользователи при анкетировании жалуются на многие операции: и оперативное проведение документов, и выполнение отчетов и обработок, и появление сообщений с блокировками или просто зависание интерфейсных форм информационных систем. Мы разумеется в своем анализе учитываем информацию от пользователя, но стараемся в первую очередь учитывать реальные данные по статистике от информационных систем и серверов баз данных
Например, пользователь жалуется на длительность выполнение отчета X. Разумеется изначально хочется проанализировать код ИС, на котором написан отчет. Но мы в этой ситуации рекомендуем сначала посмотреть на данные мониторинга производительности и определить, не было ли нехватки ресурсов сервера (как правило сервера БД) в момент выполнения отчета. Если нехватка ресурсов была, то мы далее рекомендуем вместо анализа кода реализации отчета проанализировать на причину нехватки ресурсов, а именно, какие команды/запросы SQL потребляли ресурсы. В большинстве случаев эти запросы SQL не относятся непосредственно к отчету X, а являются сторонними операциями (запросы по экранным формам, интерфейсные процедуры, оперативные отчеты). Их и надо оптимизировать.
Для поиска подобных запросов SQL мы используем форму для трассировки запросов мониторинга производительности PerfExpert.
Как показано на рисунке 2, на первую строчку кода приложения приходится 13,19% общей нагрузки CPU на сервер БД MS SQL, на вторую строку — 9,42%. Таким образом, если для быстрого выполнения пользовательской операции не хватало ресурсов CPU, то целесообразно оптимизировать 2 первые строчки – суммарно они дают почти 23% общей нагрузки CPU. Аналогично ситуация обстоит и с диском/памятью и анализ необходимо проводить аналогично.
Надеюсь данный материл будет полезен Вам в вашей работе и пониманию важности работы и анализа статистической информации. Подробно о используемом нами инструменте мониторинга информационной системы PERFEXPERT вы можете узнать по адресу http://www.softpoint.ru/perfexpert-administrirovanie-serverov и об оказываемых нами услугах http://www.softpoint.ru/vse-it-uslugi-dly-biznesa
Be the first to comment on "Статистика , как ключ к решению проблем производительности"