Развитие технологий хоть и идет семимильными шагами, но проблемы с производительностью 1С остаются актуальными.
Возможно, вскоре ИИ научится автоматически “на лету” реконфигурировать инфраструктуру и оптимизировать проблемные участки кода 1С. А пока мы решили автоматизировать диагностику проблем производительности 1С, чтобы оперативнее разбираться, в чем проблема в каждом случае: в слабой ИТ-инфраструктуре, ее некорректной настройке или неоптимальном коде 1С.
В этой статье расскажем о том, как мы дали возможность нашим клиентам самостоятельно проводить разбор проблем с производительностью их системы 1С в одном окне, а заодно сильно упростили жизнь руководителям команд разработки 1С, на которых падают вопросы “1С подтормаживает” как от пользователей, так и от ИТ-поддержки, у которой “с железом всё хорошо”. :)
Предпосылки
Потребовалось время, чтобы накопить опыт разбора проблем с производительностью 1С, в том числе при размещении и обслуживании клиентской инфраструктуры в дата-центре.
Затем, как обычно, встал вопрос автоматизации для более оперативной диагностики и сокращения ручных операций, ведь помимо диагностики проблему нужно еще и решить. Да и не только нам это важно, но и нашим клиентам, которые проблемы анализируют сами и оптимизируют 1С тоже сами.
Диагностика проблем
Классический подход в диагностике проблемы производительности 1С включает:
1) анализ настроек ИТ-инфраструктуры и ПО;
2) анализ кода 1С.
Если с первой категорией проблем системный администратор может хотя бы попробовать разобраться, то со второй - требуется привлечение не просто разработчика 1С, а эксперта по анализу и оптимизации кода.
Часто система 1С и инфраструктура не мониторится должным образом, поэтому при возникновении проблем сложно оперативно провести диагностику.
Мониторить нужно не только инфраструктуру, но и качество кода 1С. Собирать не только метрики, но и логи событий. Однако, практика показывает, что даже в крупных организациях применяется классический мониторинг - жалобы пользователей.
Как правило, для диагностики используется несколько разных инструментов, ручные проверки - всё это занимает время, требует компетенций. Поэтому мы собрали набор инструментов, достаточных для диагностики проблем с производительностью 1С и всё это в одном окне браузера.
Упрощенная схема работы выглядит так:
Рисунок 1 - Упрощенная схема работы
Далее расскажем подробнее об организации диагностики проблем с 1С с помощью функционала, который состоит из трех основных сегментов: мониторинга серверов, мониторинга производительности 1С и мониторинга качества кода 1С.
Мониторинг серверов
Для наглядного вывода данных с графиками метрик работы серверов 1С, СУБД и любых других используем графический дашборд, где также есть отдельная панель с актуальными на данный момент проблемами высокой важности на серверах. Данные собираются с серверов агентами в реальном времени.
Рисунок 2 - Дашборд мониторинга серверов 1С и СУБД
Когда может быть полезно
Это не полная замена классической системы мониторинга (а-ля Zabbix), применяемой для контроля за состоянием ИТ-инфраструктуры 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 важна для мониторинга “здоровья” 1С на постоянной основе.
Индивидуальный профиль APDEX полезен тем, что можно не только просматривать график с оценкой производительности по выбранным операциям, но и получать детализированный отчет по времени выполнения каждой ключевой операции, частоте выполнения и оценке APDEX для нее.
Например, процедура закрытия месяца критически важна и проблемы производительности в этой области работы с 1С – самые болезненные. В этом случае можно создать профиль APDEX с операциями закрытия месяца и контролировать динамику.
Для уточнения целевого времени, можно вручную задать через сервис целевое время для каждой целевой операции, либо использовать то, которое установилось автоматически.
Рисунок 5 - Вывод значений APDEX в разрезе ключевой операции
Анализ запросов 1С
Длительные запросы 1С могут быть вызваны различными факторами, такими как большие объемы данных, неоптимизированные запросы или проблемы с железом.
Анализ длительных запросов 1С – довольно полезная операция в диагностике проблем, но нужно погружаться в подробности технологического журнала 1С: вплоть до пользователя, детальной записи технологического журнала и контекста.
Используем графические дашборды, в которых можно практически как угодно сортировать данные, что кардинально отличается от парсинга и разбора техжурнала 1С в excel.
Агент собирает техжурнал и отдает в систему, которая хранит и управляет данными, в т.ч. визуализацией.
Рисунок 6 - Вывод данных по длительным запросам 1С
В вывод попадают события с отбором:
- Событие DBMSSQL (или другие в зависимости от используемой СУБД), SDBL.
- Длительность события больше 1 сек (1 000 000 микросекунд).
Когда может быть полезно
Полезно просматривать список запросов, которые выполнялись долго (например, более 10 секунд). Это помогает выявить проблемные места в коде или конфигурации 1С.
Например, обнаружили запрос, который выполнялся 19 секунд, что привело к длительной блокировке и проблемам для других пользователей. Нужно выявить такой запрос и начать его исследование.
Анализ ошибок 1С
Диагностика ошибок по сбоям в работе сервера 1С полезна для анализа проблем в том числе с производительностью системы.
Сбор и обработка событий ошибок 1С не отличается от предыдущего пункта концептуально, разница лишь в преднастроенных фильтрах в графическом дашборде - ошибки классифицируем по категориям, подкатегориям, а также разделяем по базам.
Рисунок 7 - Вывод данных по ошибкам сервера 1С
Каждую ошибку стоит детально проанализировать, используя информацию о времени возникновения, сервере, пользователе, контексте, тексте ошибки и исходной записи технологического журнала.
Когда может быть полезно
В сочетании с другими данными диагностики, можем более глубоко исследовать не только конкретные проблемы с производительностью 1С, но и в целом сбои сервера 1С. Наглядная гистограмма помогает отследить динамику в разрезе выбранного временного интервала и конкретной ошибки или типа ошибки, что поможет выявить зависимости в случае, если проблема системная.
Анализ блокировок 1С
Когда в 1С возникает блокировка - ничего страшного, это стандартный функционал, который ограничивает доступ к данным или объектам, чтобы избежать их одновременного изменения несколькими пользователями.
Проблема возникает тогда, когда есть длительные ожидания на блокировках, связанные с какими-либо проблемами в коде 1С.
Стоит проанализировать и ошибки и ожидания на блокировках конкретной базы 1С.
Используем графический вывод информации по событиям TTIMEOUT и TDEADLOCK из логов технологического журнала 1С для:
- контроля производительности системы;
- выявления проблемных участков кода;
- определения необходимости оптимизации;
- предупреждения массовых сбоев;
- принятия решений по масштабированию системы.
Частое появление этих ошибок в логах сигнализирует о необходимости оптимизации кода или увеличения производительности системы.
Рисунок 8 - Анализ ошибок блокировок 1С
Сбор событий также осуществляется через агент, упомянутый выше, но помимо указания на сами ошибки блокировок, есть и детализация логики кто виноват и кто пострадал в виде двух таблиц:
- таблица виновников блокировки (слева). В этой таблице отображаются виновники, которые группируются по контексту. Контекст может быть развернут для детализации, которая содержит время возникновения, пользователя (виновника), количество жертв, общее время блокировки, контекст виновника;
- таблица жертв блокировки (справа). Заполняется при выборе виновника в левом секторе. Эта таблица содержит всех жертв выбранного виновника из левой таблицы со следующими данными: дата блокировки, время ожидания, объект метаданных, заблокированный пользователь (жертва), контекст жертвы.
Рисунок 9 - Анализ ожиданий на блокировках 1С
Рисунок 10 - Детали события при анализе жертвы блокировки
Когда может быть полезно
Пользователи получают ошибки, связанные с тайм-аутом, например, "Превышено время ожидания блокировки".
Причина: Это происходит, когда система не может получить доступ к заблокированному ресурсу в течение заданного времени.
Что делать: Анализировать блокировки, чтобы определить, какие процессы вызывают тайм-ауты и почему они занимают так много времени.
Анализ СУБД
Для диагностики проблем с производительностью, нужно обращать внимание на метрики сервера СУБД, влияющие на производительность системы 1С, собираем также их агентом-сборщиком в реальном времени.
Мониторинг СУБД нацелен на проверку настроек СУБД на соответствие рекомендациям фирмы 1С, статус выполнения регламентных заданий, статистику по фрагментации таблиц в разрезе БД, ожидания СУБД, состояние индексов и нагрузку баз на ЦП, ОЗУ, диск.
Рисунок 11 - Анализ метрик СУБД
Рисунок 12 - Состояние сервера СУБД
Когда может быть полезно
Предположим, система 1С работает медленно, пользователи жалуются на долгое выполнение операций (например, проведение документов, формирование отчетов). Не всегда проблемы с производительностью 1С можно объяснить наличием блокировок или долгих запросов в 1С – стоит обратиться к метрикам СУБД.
Что смотреть:
- нагрузка на CPU — высокая загрузка процессора может указывать на неоптимизированные запросы или недостаток ресурсов;
- оперативная память — нехватка RAM может приводить к использованию диска для временных данных (swapping), что замедляет работу;
- дисковые операции (I/O) — высокая нагрузка на диск (чтение/запись) может быть признаком неэффективных запросов или недостатка индексов;
- очереди запросов — если запросы долго находятся в очереди на выполнение, это может указывать на недостаток ресурсов или неправильную настройку СУБД.
Мониторинг качества кода 1С
Качество кода 1С напрямую зависит от процессов разработки, а именно от полноты и достаточности тестирования, чтобы избежать ошибок в продакшн, которые могут привести к замедлению работы системы, отдельных запросов или другим проблемам.
Одним из инструментов обеспечения качества кода является статический анализ.
Используем статический анализ кода 1С по принципу двух действий (загрузил файл, открыл отчет о результатах сканирования):
Рисунок 13 - Схема автоматического статического анализа кода 1С
Случай из практики:
Однажды сканировали разработку внешнего поставщика нетиповой конфигурации 1С, разрабатываемую и поставляемую им в качестве надстройки для типовой конфигурации 1С, нашли массу ошибок и проблем, не только влияющих на производительность 1С, но и на безопасность системы в том числе.
Отчет отправили разработчику, но картина сама по себе неприятная, что говорит о том, что технический долг даже у таких компаний не всегда мониторится должным образом.
Рисунок 14 - Вид отчета после проведения анализа кода 1С
Когда может быть полезно
Статический анализ важен, чтобы выявить ошибки и потенциальные проблемы в коде на ранних этапах разработки (до его компиляции или выполнения).
Чтобы сэкономить время и ресурсы, которые могли бы быть потрачены на исправление ошибок на более поздних стадиях разработки или после релиза продукта, важно:
- Отслеживать прогресс: история позволяет видеть, как улучшалось качество кода с течением времени, какие ошибки были исправлены, а какие проблемы остаются нерешенными.
- Анализировать тенденции: разработчик может отслеживать изменения в качестве кода на протяжении разных итераций, что помогает выявить потенциальные источники проблем в процессе разработки.
- Оценить результаты тестирования: история проверок помогает понять, насколько эффективно проводилось тестирование и где возможны пропуски, которые могли привести к новым багам.
- Управлять техническим долгом: с помощью истории проверок можно идентифицировать участки кода, которые были подвержены частым исправлениям, что позволяет разработчику или команде фокусироваться на этих проблемных областях для уменьшения технического долга.
- Улучшить командную работу: история проверок может быть использована для анализа работы различных участников проекта, помогая разработчикам учиться на ошибках друг друга и улучшать общие практики кодирования.
- Подготовить отчетность: для создания отчетов по качеству кода, истории проверок можно использовать для документирования изменений и улучшений в проекте, что полезно для внутренней отчетности или внешних заинтересованных сторон.
Послесловие
В целом, автоматизация диагностики проблем с производительностью 1С, как и принцип одного окна браузера - объективно полезная вещь, ведь можно оперативно проанализировать проблему с 1С, не переключаясь между различными инструментами диагностики, которых может вообще и не быть в контуре. :)
Насколько оперативно теперь можно диагностировать неполадки в производительности 1С? Время на расследование сокращается буквально в разы, но это уже тема отдельной статьи, как и отдельные вопросы оптимизации.
Ответы на актуальные вопросы:
- Оповещения. Алерты тоже можно устанавливать, все таки мониторить через жалобы пользователей - не очень хорошо. :)
- Как и где применимо - везде, если контур инфраструктуры не закрыт от доступа в Интернет.
А как проблемы с производительностью 1С диагностируете вы и ваша команда?
