Запись вебинара "Анализ технологического журнала 1С с помощью регулярных выражений"

База с паранормальными явлениями

На днях дали базу 1С:ERP на анализ. Симптомы - все тормозит. Открытие конфигуратора (примерно 1,5 часа), клиента, переходы по навигационным ссылкам - все. Остальные базы в кластере работают нормально, в том числе и другая ERP, а с этой непонятная беда. Чистка кэша, тестирование/исправление, DBCC CHECKDB, разворачивание из SQL бэкапа в чистую базу, выгрузка/загрузка .dt, пересоздание базы в кластере, какие-то еще шаманства - ничего не помогает.

bash, еще bash, еще много-много bash

А на ловца и зверь бежит, коллеги. Буквально недавно эпизодически bash'ил подведомственный техжурнал и делал заготовки скриптов. И тут свершилось - двухнедельный проект по анализу текущих проблем производительности. Без ограничений не обошлось, в лучших традициях жанра. Конфигурация УПП 1.3 - соответственно, древняя БСП, где подсистема оценки производительности еще на перечислениях. На продуктив ходить только под присмотром, самостоятельно ничего не менять, ничего не запускать. ЦУП нельзя, как сказали, уже пробовали - сбор данных тормозит систему. Заказчик привел адекватные аргументы в пользу поставленных ограничений. В итоге, из доступных инструментов остались логи технологического журнала и счетчики производительности, которые складываются на отдельный тестовый сервер. Там же развернута копия базы. Если бы не скрипты, то тогда вообще непонятно бы было, что со всем этим делать.

grep всему голова

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

Где моя отладка, чувак?

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

Знакомство с Docker'ами

Собственно, руки давно уже чесались попробовать. Я часто использую VirtualBox для организации различного окружения под свои потребности, как на работе, так и дома. Общие плюсы виртуализации и конкретику Docker расписывать не буду, перейду сразу же к практической части.
Развертывание под Windows возможно в двух вариантах:
- Docker for Windows под Win 10 Pro 64x с включенным Hyper-V, позволяет использовать контейнеры под win/linux.
- DockerToolbox под другие 64х ОС без поддержки или выключенным Hyper-V с использованием VirtualBox, работает только контейнерами под linux.
Я хоть и сижу под необходимой версией, но поскольку VirtualBox не работает при включенном Hyper-V, то буду пробовать второй вариант.

Проблемы производительности. Фрагментация индексов.

Недавно на практике получилось увидеть влияние чрезмерной фрагментации индексов на производительность базы, конфигурация 1С: ERP. Ранее я читал, что излишняя фрагментация влияет на скорость выполнения операций INSERT, UPDATE, DELETE, в чем и удалось убедиться. Как обычно бывает, проблему обрисовали в общих чертах - у клиента тормозит база. В таких случаях, когда не известно, с чего начать - начинаем с настройки сбора данных по счетчикам производительности и технологического журнала. В моем случае анализ данных по счетчикам производительности проблем загруженности оборудования не выявил. Так же в существующие настройки техжурнала была добавлена секция для сбора событий с длительностью, превышающей три секунды.

Произвольная иерархия в СКД: вывод дерева значений

Просматривал утром статистику посещений блога, наткнулся на переход с форума Инфостарта, из темы про сохранение дерева значений в табличный документ. Самый простой способ - рекурсивный обход строк дерева, автор так и поступил. Но тема перекликается с моей предыдущей статьей о произвольной иерархии СКД, только использование внешних наборов данных в ней не рассматривается. Поэтому решил исправить данный недостаток и набросать небольшой пример вывода дерева значений с помощью системы компоновки данных.

Произвольная иерархия в СКД

Относительно недавно попал на доработку отчет, содержащий приличное количество кода, который в итоге был выброшен полностью, поскольку возможностей системы компоновки данных вполне хватило для получения необходимого результата. Большая часть этого кода как раз отвечала за построение иерархической структуры. К сожалению, этому разработчику продемонстрировать возможности СКД возможности нет. Но поделиться со всеми остальными коллегами, интересующимися данной темой, это всегда пожалуйста :)

В СКД можно реализовать следующие варианты построения иерархии:
- к основному набору данных достраивается иерархическая структура;
- рекурсивное построение иерархии по одному набору данных.
В этом посте я хочу рассмотреть второй вариант на примере ресурсных спецификаций в демо-базе 1С:ERP 2.