Технологии развиваются очень быстро, но проблемы с производительностью 1С всё ещё остаются.
Возможно, скоро искусственный интеллект сможет сам менять настройки и улучшать код 1С прямо на ходу. Но пока этого нет, мы решили сделать автоматическую диагностику проблем с производительностью 1С. Это помогает быстро понять, в чём именно дело: слабое железо, неправильные настройки или плохо написанный код.
В этой статье расскажем, как мы сделали так, чтобы наши клиенты могли сами разбираться с проблемами 1С через один удобный экран в браузере. Это сильно облегчает жизнь тем, кто руководит командами разработчиков 1С и часто слышит от пользователей «почему 1С тормозит?», а IT-поддержка говорит «с серверами всё в порядке».
Откуда всё началось?
Сначала мы накопили опыт, разбираясь с проблемами производительности 1С, в том числе когда помогали с инфраструктурой в дата-центрах.
Потом возникла идея сделать процесс диагностики проще и быстрее. Ведь не только найти проблему важно, её ещё нужно решить. И не только мы хотим это делать быстро — наши клиенты тоже хотят сами видеть, где у них беда, и исправлять её.
Как обычно ищут причины?
Когда что-то тормозит в 1С, обычно смотрят на два момента:
- Как настроено оборудование и программное обеспечение;
- Как написан сам код 1С.
С настройками оборудования может разобраться системный администратор. А вот чтобы разобраться с кодом, нужен специалист, который хорошо понимает 1С и умеет оптимизировать его.
Проблема в том, что часто не ведут нормальный мониторинг — ни инфраструктуры, ни самого кода. Поэтому, когда появляются проблемы, быстро их найти сложно.
Чтобы нормально следить за работой, нужно собирать и метрики, и логи. Но чаще всего даже крупные компании просто слушают жалобы пользователей.
Обычно для диагностики используют разные программы и делают много ручной работы — это долго и сложно. Мы решили собрать все нужные инструменты в одном месте, в одном окне браузера, чтобы облегчить жизнь всем.
Упрощенная схема работы Metrika42 выглядит так:
Дальше расскажем, как устроена диагностика проблем с 1С — она состоит из трёх главных частей: мониторинг серверов, мониторинг производительности самой 1С и проверка качества кода 1С.
Мониторинг серверов
Чтобы было проще видеть, как работают серверы 1С, базы данных и другие системы, мы сделали удобный дашборд с графиками. Там можно сразу увидеть важные проблемы, которые сейчас есть на серверах. Данные с серверов собираются автоматически и показываются почти сразу.
Когда это пригодится:
Этот инструмент не заменяет полностью классические системы мониторинга вроде Zabbix, которые обычно следят за всей ИТ-инфраструктурой 1С.
Скорее, это дополнительный способ быстро получить данные о работе серверов прямо в одном окне браузера и сопоставить их с другой информацией, чтобы лучше разобраться с проблемами производительности 1С.
Мониторинг производительности 1С
Чтобы разобраться, почему 1С работает медленно, обычно нужно пройти несколько этапов проверки. Разные специалисты могут использовать разные методы и инструменты, в зависимости от своих знаний.
Мы постарались учесть почти все важные шаги, которые обычно применяются для диагностики, и сделали такой набор:
- Оценка APDEX
- Анализ запросов 1С
- Анализ ошибок 1С
- Анализ блокировок 1С
- Анализ СУБД
Что такое APDEX?
APDEX — это метод, который помогает объективно измерить, насколько хорошо работает система 1С. Главное, чтобы были известны важные операции для бизнеса и заданы целевые времена их выполнения.
Процесс оценки по APDEX выглядит так:
- Определяем список ключевых операций
- Расставляем их по приоритету
- Задаём целевое время для каждой операции
- Собираем данные о времени выполнения этих операций
- Считаем показатель APDEX и делаем выводы
Как интерпретировать APDEX?
Результаты выражаются в понятных оценках — от хорошего до плохого состояния.
Формула для расчёта выглядит так:
APDEX = (NS + NT/2) / N
Где:
- N — общее количество запусков операции
- NS — количество запусков с временем ответа от 0 до T (целевого времени)
- NT — количество запусков с временем ответа от T до 4T
Так можно понять, насколько часто операции выполняются быстро, а насколько часто — с задержками.
По умолчанию можно использовать базовую оценку APDEX с готовым списком основных операций для конкретной версии 1С. Такой вариант не даёт очень детального анализа, но отлично помогает быстро заметить серьёзные просадки в работе системы.
Чтобы углубиться в детали, можно использовать персональные профили APDEX. В них вы сами выбираете ключевые операции и формируете свой набор для оценки.
Когда это пригодится?
APDEX — отличный инструмент для постоянного контроля “здоровья” вашей 1С.
С персональным профилем можно не только смотреть общий график производительности по выбранным операциям, но и получать подробные отчёты: сколько времени занимает каждая операция, как часто она выполняется и какой у неё APDEX.
Например, операция закрытия месяца — очень важная и часто проблемная. Создав профиль именно для таких операций, можно следить за их динамикой и вовремя реагировать на замедления.
Если нужно, целевое время выполнения каждой операции можно настроить вручную через сервис или оставить то, что система определила автоматически.
Анализ запросов 1С
Долгие запросы в 1С могут появляться по разным причинам — например, из-за больших объёмов данных, плохо написанных запросов или проблем с оборудованием.
Разбираться с такими запросами полезно, но для этого нужно детально изучать технологический журнал 1С — вплоть до того, кто именно выполнял запрос и в каком контексте.
Мы используем удобные графические дашборды, где данные можно сортировать и фильтровать практически любым способом. Это намного проще и нагляднее, чем разбирать журналы вручную через Excel.
Специальный агент собирает техжурнал и отправляет его в систему, которая хранит все данные и отвечает за их визуализацию.
В результаты попадают только события, отобранные по следующим критериям:
- Тип события — DBMSSQL (или другой, в зависимости от используемой базы данных);
- Длительность выполнения больше 1 секунды (то есть свыше 1 000 000 микросекунд).
Когда это полезно?
Очень полезно смотреть список запросов, которые выполнялись долго, например, дольше 10 секунд. Это помогает быстро найти узкие места в коде или настройках 1С.
Например, если найден запрос, который работает 19 секунд и вызывает длительные блокировки, это сигнал к тому, чтобы внимательно его изучить и исправить.
Анализ ошибок 1С
Отслеживание ошибок при сбоях сервера 1С помогает не только выявлять проблемы с производительностью, но и находить другие сбои в работе системы.
Принцип сбора и обработки ошибок похож на анализ длительных запросов, только здесь применяются специально настроенные фильтры в дашборде. Ошибки классифицируются по категориям, подкатегориям и распределяются по разным базам 1С для удобства анализа.
Когда это пригодится?
Вместе с другими диагностическими данными это помогает глубже понять не только конкретные проблемы с производительностью 1С, но и общие сбои на сервере. Наглядные графики показывают, как меняется количество ошибок за выбранный период, что помогает выявить системные закономерности.
Анализ блокировок в 1С
Блокировки в 1С — это обычный механизм, который защищает данные от одновременного изменения несколькими пользователями.
Проблемы начинаются, когда блокировки становятся слишком долгими из-за ошибок в коде 1С.
Важно анализировать как сами ошибки, так и случаи ожидания блокировок в конкретной базе.
Для этого мы визуализируем события TTIMEOUT и TDEADLOCK из технологического журнала 1С, чтобы:
- Следить за производительностью системы;
- Находить проблемные участки кода;
- Определять, где нужна оптимизация;
- Предотвращать массовые сбои;
- Принимать решения о масштабировании.
Частое появление таких ошибок говорит о том, что код нужно оптимизировать или систему — улучшить.
- Таблица виновников блокировок (слева): здесь собраны все пользователи или процессы, которые стали причиной блокировки. Их можно сгруппировать по контексту, а при раскрытии увидеть подробности — время события, кто виновник, сколько было пострадавших, общее время блокировки и дополнительный контекст.
- Таблица жертв блокировок (справа): появляется, когда выбираешь конкретного виновника слева. В ней перечислены все пользователи или процессы, которые пострадали из-за этой блокировки, с данными о дате и времени ожидания, заблокированном объекте, пользователе-жертве и её контексте.
Когда это пригодится
Пользователи иногда видят ошибки с тайм-аутом, например: «Превышено время ожидания блокировки».
Почему так происходит?
Это случается, когда система не может получить доступ к нужному ресурсу, потому что он заблокирован слишком долго.
Что делать?
Нужно анализировать блокировки, чтобы понять, какие процессы вызывают эти тайм-ауты и почему они так долго держат ресурс.
Анализ работы СУБД
Чтобы понять причины проблем с производительностью 1С, важно следить за метриками сервера базы данных (СУБД). Мы собираем эти данные с помощью специального агента в режиме реального времени.
Мониторинг СУБД помогает проверить:
- Правильность настроек базы данных в соответствии с рекомендациями 1С;
- Выполнение регламентных заданий;
- Статистику по фрагментации таблиц внутри базы;
- Ожидания и задержки внутри СУБД;
- Состояние индексов;
- Нагрузку на процессор, оперативную память и диск.
Когда это пригодится:
Если 1С начинает работать медленно, а пользователи жалуются на долгое выполнение операций (например, проведение документов или формирование отчетов), не всегда причина кроется в блокировках или медленных запросах. В таких случаях стоит обратить внимание на метрики базы данных (СУБД).
Что нужно проверить:
- Загрузка процессора (CPU): высокая нагрузка может говорить о неэффективных запросах или недостатке ресурсов.
- Оперативная память (RAM): её нехватка заставляет систему использовать диск для временных данных (swapping), что снижает скорость работы.
- Дисковая активность (I/O): слишком высокая нагрузка на диск (чтение/запись) может быть признаком неоптимальных запросов или отсутствия индексов.
- Очереди запросов: если запросы долго ждут своей очереди, возможно, ресурсов не хватает или база неправильно настроена.
Мониторинг качества кода 1С
Качество кода напрямую зависит от того, как проходит процесс разработки и насколько полно выполняется тестирование. Ошибки, попадающие в рабочую систему, могут привести к тормозам и другим проблемам.
Одним из эффективных способов контроля является статический анализ кода.
Мы используем простой подход: загружаем файл с кодом и сразу получаем подробный отчет с результатами сканирования.
Один из примеров из практики: мы проверяли код нестандартной конфигурации 1С, которую внешний поставщик создал как надстройку к типовой версии. В ходе анализа обнаружили множество ошибок и проблем — не только снижающих производительность, но и влияющих на безопасность системы.
Отчёт отправили разработчику, но ситуация оказалась серьёзной. Это показывает, что даже у опытных компаний технический долг часто не контролируется должным образом.
Когда статический анализ особенно полезен
Статический анализ помогает находить ошибки и возможные проблемы в коде ещё на ранних этапах — до того, как код будет запущен или скомпилирован.
Это экономит время и силы, которые иначе ушли бы на исправление багов на более поздних этапах или уже после релиза.
Почему стоит использовать историю проверок кода:
- Отслеживать прогресс: видно, как качество кода менялось с течением времени, какие ошибки исправили, а какие остались.
- Анализировать тенденции: помогает понять, где в процессе разработки могут появляться новые проблемы.
- Оценивать тестирование: можно проверить, насколько хорошо тестировали код и где могли быть пропущены баги.
- Управлять техническим долгом: легко выявлять участки с частыми исправлениями и сосредоточиться на их улучшении.
- Повышать командную работу: анализируя работу разных участников, команда учится на ошибках друг друга и совершенствует подходы к кодингу.
- Подготавливать отчёты: история проверок помогает документировать изменения и улучшения, что полезно для внутренней отчетности или внешних заинтересованных сторон.
Итог
Автоматизация диагностики проблем с производительностью 1С и объединение всех инструментов в одном окне браузера — это реально удобное и полезное решение. Теперь можно быстро разобраться с проблемами, не переключаясь между разными программами, которых порой и вовсе нет.
Насколько быстрее теперь можно находить неполадки?
Время на поиск и анализ проблем сокращается в несколько раз, но это уже отдельная тема — как и методы оптимизации.
Ответы на частые вопросы:
- Алерты и уведомления: их тоже можно настроить. Ждать жалоб от пользователей — не самый хороший вариант.
- Где использовать: практически везде, если ваша инфраструктура не изолирована от интернета.
А как у вас организована диагностика производительности 1С? Делитесь опытом!