Тормозит 1С? Автоматизируем диагностику проблем производительности, связанных с инфраструктурой и кодом

Развитие технологий хоть и идет семимильными шагами, но проблемы с производительностью 1С остаются актуальными. Возможно, вскоре ИИ научится автоматически “на лету” реконфигурировать инфраструктуру и оптимизировать проблемные участки кода 1С. Но это лишь вероятное будущее, а сегодня мы создали продукт, который позволяет автоматизировать диагностику проблем производительности 1С и разобраться, в чем проблема: в слабой ИТ-инфраструктуре, ее некорректной настройке или неоптимальном коде.

Предпосылки

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

Разделение проблемы

Классический подход в диагностике проблемы производительности 1С включает:

• анализ настроек ИТ-инфраструктуры и ПО;
• анализ кода 1С.

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

Инструменты для диагностики производительности 1С

Как правило, для диагностики используется несколько разных инструментов, ручные проверки – всё это занимает время, требует компетенций. Поэтому в нашем сервисе мы создали набор инструментов, достаточных для диагностики проблем с производительностью 1С и всё это в одном окне. С момента публикации прошлой статьи произошли изменения в нашем продукте и теперь его схема работы выглядит так:

Рисунок 1 – Схема работы сервиса анализа производительности 1С.

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

Мониторинг серверов

Функционал мониторинга серверов представляет собой наглядный вывод данных с графиками метрик работы серверов 1С, СУБД и любых других. Также есть отдельная панель с критичными триггерами (опционально), то есть актуальными на данный момент проблемами высокой важности на серверах.

Рисунок 2 – Дашборд мониторинга серверов 1С и СУБД.

Когда может быть полезно

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

Производительность 1С

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

Оценка APDEX

Методика APDEX позволяет объективно оценить производительность информационной системы 1С, при условии, что известны ключевые операции системы (важные для бизнеса) и правильно задано целевое время их выполнения. Оценка производительности 1С по APDEX включает в себя:

• получение списка ключевых операций;
• сортировка по приоритету;
• определение целевого времени для каждой ключевой операции;
• сбор времени выполнения каждой ключевой операции;
• расчет оценки APDEX и интерпретация.

Интерпретация полученных данных происходит в терминах качественных оценок (то есть, по шкале «хорошо – плохо»). Значение APDEX вычисляется по формуле: APDEX = (NS + NT/2) / N, где:

• N – общее количество выполнений данной операции;
• NS – количество выполнений с временем отклика от 0 до T;
• NT – количество выполнений с временем отклика от T до 4T.

Рисунок 3 – Шкала оценок APDEX.

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

Рисунок 4 – На графике отображается усредненное значение APDEX по ключевым операциям конкретной базы данных 1С, а также цветовые зоны уровня оценки.

Более ценная возможность – подключение персонализированных профилей мониторинга APDEX. Можно создавать профили с выбранным набором ключевых операций (их можно выбрать при создании профиля).

Когда может быть полезно

Индивидуальный профиль APDEX позволяет не только просматривать график с оценкой производительности по выбранным операциям, но и получать детализированный отчет по времени выполнения каждой ключевой операции, частоте выполнения и оценке APDEX для нее. Например, процедура закрытия месяца критически важна и проблемы производительности в этой области работы с 1С – самые болезненные. В этом случае можно создать профиль APDEX с операциями закрытия месяца и контролировать динамику. Для уточнения целевого времени, можно вручную задать через сервис целевое время для каждой целевой операции, либо использовать то, которое установилось автоматически.

Рисунок 5 – Вывод значений APDEX в разрезе ключевой операции.

Анализ запросов 1С

Длительные запросы 1С могут быть вызваны различными факторами, такими как большие объемы данных, неоптимизированные запросы или проблемы с железом. Анализ длительных запросов 1С – довольно полезная функция, особенно, когда в разрезе детализации видны подробности вплоть до пользователя, детальной записи технологического журнала и контекста. Можно практически как угодно сортировать данные через мощный фильтр, а благодаря наличию поиска, можно оперативно найти нужное значение и тут же отсортировать по нему результаты.

Рисунок 6 – Вывод данных по длительным запросам 1С.

В технологический журнал попадают события с отбором:

• событие DBMSSQL (или другие в зависимости от используемой СУБД), SDBL;
• длительность события больше 1 сек (1 000 000 микросекунд).

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

Когда может быть полезно

После включения анализа запросов можно просматривать список запросов, которые выполнялись долго (например, более 10 секунд). Это помогает выявить проблемные места в коде или конфигурации. Например, вы обнаружили запрос, который выполнялся 19 секунд. Это привело к длительной блокировке и проблемам для других пользователей. Анализ запросов позволит выявить такой запрос и начать его исследование.

Анализ ошибок 1С

Функционал анализа ошибок позволяет получить информацию по сбоям в работе сервера 1С, а также подробную детализацию для диагностики причин.

Рисунок 7 – Вывод данных по ошибкам сервера 1С.

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

Когда может быть полезно

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

Анализ блокировок 1С

Когда в 1С возникает блокировка – ничего страшного, это стандартный функционал, который ограничивает доступ к данным или объектам, чтобы избежать их одновременного изменения несколькими пользователями. Проблема возникает тогда, когда есть длительные ожидания на блокировках, связанные с какими-либо проблемами в коде 1С. С помощью нашего инструмента, можно проанализировать и ошибки и ожидания на блокировках конкретной базы 1С. Функционал анализа ошибок блокировок 1С позволяет подключить графический вывод информации по событиям TTIMEOUT и TDEADLOCK из логов технологического журнала 1С. Мониторинг событий TTIMEOUT и TDEADLOCK в логах 1С необходим для:

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

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

Рисунок 8 – Анализ ошибок блокировок 1С.

Функционал анализа ожиданий на блокировках при выборе базы 1С отображается в виде двух таблиц:

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

Рисунок 9 – Анализ ожиданий на блокировках 1С.

Рисунок 10 – Детали события при анализе жертвы блокировки.

Когда может быть полезно

Пользователи получают ошибки, связанные с тайм-аутом, например, “Превышено время ожидания блокировки”. Причина: Это происходит, когда система не может получить доступ к заблокированному ресурсу в течение заданного времени. Что делать: Анализировать блокировки, чтобы определить, какие процессы вызывают тайм-ауты и почему они занимают так много времени.

Анализ СУБД

Анализ сервера СУБД представляет собой вывод метрик, влияющих на производительность системы 1С. Мониторинг СУБД отслеживает настройки СУБД на соответствие рекомендациям фирмы 1С, статус выполнения регламентных заданий, статистику по фрагментации таблиц в разрезе БД, ожидания СУБД, состояние индексов и нагрузку баз на ЦП, ОЗУ, диск.

Рисунок 11 – Анализ метрик СУБД.

Также метрики сервера СУБД выводятся в функционале Мониторинг серверов:

Рисунок 12 – Состояние сервера СУБД.

Когда может быть полезно

Система работает медленно, пользователи жалуются на долгое выполнение операций (например, проведение документов, формирование отчетов). Если проблемы с производительностью не удается объяснить анализом блокировок или запросов в 1С, стоит обратиться к метрикам СУБД. Что смотреть:

• нагрузка на CPU — высокая загрузка процессора может указывать на неоптимизированные запросы или недостаток ресурсов;
• оперативная память — нехватка RAM может приводить к использованию диска для временных данных (swapping), что замедляет работу;
• дисковые операции (I/O) — высокая нагрузка на диск (чтение/запись) может быть признаком неэффективных запросов или недостатка индексов;
• очереди запросов — если запросы долго находятся в очереди на выполнение, это может указывать на недостаток ресурсов или неправильную настройку СУБД.

Мониторинг качества кода 1С

Качество кода 1С напрямую зависит от качества разработки, а именно от полноты и достаточности тестирования, чтобы избежать ошибок в продакшн, которые могут привести к замедлению работы системы, отдельных запросов или другим проблемам. Одним из инструментов обеспечения качества кода является статический анализ. В рамках сервиса доступен инструмент, который автоматически выполнит статический анализ вашего кода 1С в форматах .cf, .cfe, .epf и предоставит отчет.

Рисунок 13 – Схема автоматического статического анализа кода 1С.

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

Рисунок 14 – Состояние сервера СУБД.

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

• проверка форматов .cf/.epf/.cfe;
• поиск проблем качества кода по критериям: безопасность, надежность, сопровождаемость;
• сортировка по серьезности ошибок: высокий, средний, низкий уровень;
• сортировка проблем кода по типам: ошибка, уязвимость, дефект кода 1С;
• фильтрация проблем по правилам проверки кода 1С;
• детализация каждой проблемы с подсветкой замечания, описанием почему это проблема и рекомендацией как ее исправить;
• история проверок (опция);
• разбивка по проектам (опция);
• настройка профилей качества (опция).

Когда может быть полезно

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

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