Обновлено: 08.01.2025

В первой части статьи мы приводим список и описание из 5 шагов для самостоятельного выполнения процедуры. Если же Вам лень читать и Вы любите смотреть и слушать, то можно перейти к видео-уроку и посмотреть небольшой 5 минутный ролик по выполнению необходимой последовательности действий и повторить при необходимости.

Совет. Боевую базу мониторинга лучше всего развернуть на отдельном сервере, по крайней мере на отдельном кластере.

2. Определим цели и задачи

Что мы будем мониторить? Проблемные ситуации влияющие в целом на производительность и работоспособность базы:

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

Зачем будем мониторить? Для возможности проведения анализа проблемных ситуаций возникающих при работе базы и последующему их исправлению. Ознакомлен - значит вооружен.

3. Настроим технологический журнал (ТЖ) для 1С

Давайте настроим конфигурационный файл для технологического журнала всех указанных случаев. Эту операцию настроим вручную с использованием Notepad++. Однако вы всегда можете воспользоваться специальной обработкой с ИТС для настройки этого файла.

Каждую проблемную ситуацию будем выгружать в отдельный каталог и обрамляется она тегом "log" (примерный исходный код файла приведен ниже). Эти каталоги должны быть видны с сервера где развернута наша конфигурация - можно сделать общий каталог.

Созданный файл "logcfg.xml" копируем в папку с установленным предприятием 1С боевого сервера (обычно куда-то по похожему пути: "c:\Program Files\1cv8\8.3.12.1855\bin\conf\").

Пример файла "logcfg.xml":

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

4. Настроим базу мониторинга

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

• Создаем в справочнике "Замеры" три замера с наименованиями по ситуациям: блокировки, долгие запросы и ошибки;
• Указываем путь к соответствующим каталогам;
• Ставим флаг "загружать в реальном времени" - означает, что данные будут подгружаться автоматически регламентным заданием;
• Ставим флаг "загружать автоматически" и указываем интервал загрузки 5-10 минут - будет загружаться по регламентному заданию;
• Детализируем расписание загрузки лога.

После создания замеров с указанными параметрами загрузка логов технологического журнала будет выполняться автоматически (по регламентному заданию для каждого замера).

Совет. Вы можете для каждого замера указать фильтры загрузки данных из логов, чтобы ограничить количество и качество поступаемой информации (дополнительно к настройкам logcfg.xml). К примеру, игнорировать события не подлежащие анализу - обрывы соединений и т.п.

5. Запустим и проверим

Фактически все необходимые операции мы выполнили и теперь можно проверить что получилось.

Для анализа ситуации у нас имеются следующие обработки:

1. Журнал событий замеров. Позволяет просматривать список событий в временной последовательности с отборами и сортировками.

2. Рабочее место по изменению количества событий. Позволяет сравнить изменение количества событий на временной относительной оси по двум временным окнам, к примеру, сравнить среду и вторник текущей недели или разных.

Совет. Для изменения состава отображаемых колонок (добавить новые поля через ссылку, которых нет изначально) в динамическом списке пользуйтесь возможностью "изменить форму" через "еще".

Видео-урок.

В этом видео-уроке мы с вами установим конфигурацию "Анализ ТЖ", проведем необходимые настройки и посмотрим результаты на примере искусственных ситуаций.

Дополнительно.

Подключиться к проекту или его скачать вы можете с git-hub репозитория polyplastic Решение проблемы быстродействия в ERP на рабочем примере. Также в этой статье приводится методика пример выполнения задачи оптимизации проблемного участка для базы 1С.

Есть ли аналоги? К аналогам в какой-то мере можно отнести: Notepad++ и другие механизмы полу-ручного анализа; ЦУП от 1С из Корпоративного инструментального пакета.

Исправления и анализ проблемных ситуаций.

Проблемы исправляются в зависимости от проведения анализа и дальнейшей классификации. К примеру, выявленные ошибки можно классифицировать по следующим уровням:

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

Наличие "долгих" запросов сообщает о проблемах в производительности базы данных. Для их анализа и наличия можно воспользоваться журналом "свойства замеров" с сортировкой по длительности и фильтром за сегодня. Их можно классифицировать

• проблемы rls - вызваны сложными ограничениями и/или не верным назначением прав доступа;
• проблемы запроса - не правильный запрос, который стоит оптимизировать;
• проблемы производительности - проседание мощности в часы пик или по другим подобными причинам.

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

Специальные предложения

Есть отличный инструмент "Анализ технологического журнала" в Инструментах разработчика alx1c; ilyatyurin1988; Sodrugestvo; TuneSoft; user612295_death4321; CSiER; + 6 – Ответить (7) эти команды можно и на винде выполнить. И не всегда красивые графические кнопочки и таблички - значит гибко, быстро и эфективно (1) анализ от Группы Гилева - анализ Тех.Журнала,
а так же Анализы: Длительных запросов, Блокировок, Взаимо-блокировок
всё там есть. и давно

(0) используется только технологический журнал?

Просто ведь без магии иногда не обойтись, потому что ни план запроса через ТЖ без последствий нормально не получить, ни причины замедления запроса и др.

За труды спасибо, плюс поставил.

(2)
1. Проект развивается. На текущий момент доступен такой функционал.
2. В вашем случае мы используем дополнительно другие инструменты и методики для поиска сопоставления запроса с точкой в конфигурации (когда не понятно).

(3) спасибо за инструмент еще раз.

Попробую на досуге.

А есть ли возможность сделать внутри аналитической базы фильтра(отбора/группировки) по Иинформационной базе/Серверу1С/СерверуSQL/Пользователю т.е. архитектура конфигурации подразумевает что под каждую ИБ/Сервер нужно заводить отдельную ИБ анализа ТехЖурнала и уже в каждой настраивать общий доп фильтр по ИБ/Серверу или я что-то не так понял?

Жалко нет скриншота с возможными настройками, непосредственно связанными с анализом разобранного тех журнала

И ещё резонный вопрос - как это всё хранится - скажем, если тех журнал весить в тексте 1Gb то сколько он будет весить в такой аналитической базе (с учётом того, что всё что есть в тех журнале - загружается в базу).
Понятно, что объёмами тех журнала в 1Gb даже в день никого не удивишь и не шокируешь - но в больших базах, в час, тех журналы, ежедневно, бывают и по 10Gb на сервер/ИБ, а уж в периоды сдачи отчётности или под НГ могут быть и по 100Gb в час - даже если в них писать только самое важное - итого - у крупных организаций с кучей баз это будут, в пике, уже десятки терабайт в сутки! Даже если хранить это всё не более суток, как с этим объёмом справится данная аналитическая база? Компактность хранения, фильтрации, и насколько эффективно идёт разбор таких больших логов?

Да и, смотрю, нет никакой защиты от чрезмерного роста объёма данных - а желательно бы - на кризисный случай: т.е. хотя бы ограничить не только сроком хранения, а, скажем, числом записей тоже (причём, хорошо иметь не только общий максимум, но и отдельно - по каждой ИБ).

(8)
1. Удаление старых событий или "нет никакой защиты от чрезмерного роста":
- Есть константа "УдалятьУстаревшиеСобытия" и регламентное задание "УдалениеУстаревшихСобытий".
- Для замеров есть параметр Глубина Хранения - при условии не равном "0" данные будут очищаться.

2. "..журнал весить в тексте 1Gb.." - ставьте фильтры на собираемые данные. Для действительно полезных данных объемы значительно меньше!

Замер для каждого сервера отдельно, у вас не получится писать в одну папку на диске разным серверами 1С.
Базу для каждого сервера не обязательно создавать - вы создаете замер под каждый каталог, к примеру, "замер для сервера1 по ошибкам", "замер для сервера 2 по блокировкам", "замер для сервера 3 только для базы ERP по длительным запросам" и т.п.

4. Если у вас возникнут идеи по "фитчам", то пишите в issues, а еще лучше подключайтесь)
К примеру, можно добавить справочник сервер и сделать его реквизитом замера.

5. Анализ разобранного журнала это отдельная сложная задача и не входит в рамки этой промо-статьи. Для разных ситуаций оптимальны разные наборы колонок и отборов. В дальнейшем приведем еще некоторые примеры использования - все зависит от востребованности данного инструмента коллегами.

Использование замера производительности для оптимизации клиент-серверных приложений в 1С:Предприятии 8

1С:Предприятие 8 позволяет отлаживать и измерять производительность для кода на встроенном языке, исполняемом как на клиенте, так и на сервере.

Объединение результатов замера производительности для клиента и сервера

Особенностью работы замера производительности для клиент-серверной информационной базы в 1С:Предприятии 8 является то, что результаты замера производительности объединяются в один файл. Они включают в себя данные о ходе исполнения кода на встроенном языке как на клиенте, так и на сервере. Для получения такого замера достаточно запустить сервер 1С:Предприятия 8 в отладочном режиме (с помощью ключа командной строки /debug ) и в Конфигураторе в нужный момент просто включить режим замера производительности.

Отображение серверных вызовов.

Режим замера производительности 1С:Предприятия 8 показывает серверные вызовы:
1) вызовы сервера методами объектов встроенного языка, вызовы процедур и функций, исполнение которых происходит на сервере, отображаются в замере производительности в колонке "Обр. сервером" ("Обработка сервером") с помощью значка ;
2) вызовы клиентских процедур и функций, в которых тем или иным способом происходил вызов сервера, отображаются в замере производительности в колонке "Обр. сервером" ("Обработка сервером") с помощью значка .

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

По колонке "Обр. сервером" ("Обработка сервером") в замере производительности возможна сортировка: для этого достаточно щелкнуть мышью по заголовку колонки. При этом все строки кода, исполнение которых приводило к серверным вызовам, будут сгруппированы:

Отображение места исполнения кода: на клиенте или на сервере.

Режим замера производительности 1С:Предприятия 8 отображает, где исполнялся код на встроенном языке в клиент-серверной информационной базе: на клиенте или на сервере:
1) строки кода на встроенном языке, исполнение которых происходило на клиенте, отображаются в замере производительности с помощью значка в колонке "Клиент";
2) строки кода на встроенном языке, исполнение которых происходило на сервере, отображаются в замере производительности с помощью значка в колонке "Сервер".

На приведенном ниже рисунке выделены колонки, в которых значками отображаются строки, исполнение которых происходило на клиенте и на сервере:

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

Фильтрация результатов замера

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

Оптимизация приложения

Режим замера производительности в 1С:Предприятии 8 позволяет успешно производить оптимизацию работы клиент-серверных приложений. Для выполнения такой оптимизации достаточно выполнить всего несколько действий, после чего проанализировать результаты замера производительности и перейти к улучшению кода на встроенном языке.

Выполнить замер производительности

Первый шаг - выполнить замер производительности кода на встроенном языке, исполняемом на клиенте и на сервере. Получив результаты замера производительности, сохранить их в файл.

Проанализировать результаты замера производительности

Второй шаг - проанализировать результаты замера производительности.

Проанализировать в результатах время исполнения функций на клиенте и на сервере. Выбрать и проанализировать функции, исполнение которых на клиенте и на сервере заняло максимальное количество времени. Это удобно сделать, отображая с помощью фильтра информацию только для клиента или только для сервера и выполняя сортировку по колонкам времени и процентов.

Проанализировать серверные вызовы: вызовы процедур и функций общих модулей на сервере, вызовы сервера при обращении к методам и свойствам объектов языка (обращение к базе данных, оперативная отметка времени и т.п.).

Проведенный анализ результатов замера позволит выявить узкие места в приложении даже без наличия большой тестовой базы и выполнения нагрузочного тестирования:

• обращения к серверу в цикле, запросы в цикле;
• обращения к свойствам объекта по ссылке;
• и другие.

Оптимизировать прикладной код

Последний шаг - оптимизация прикладного кода. На основе анализа результатов замера производительности и выявленных узких мест произвести оптимизацию прикладного кода.

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

Чтобы выполнить замер, нужно в некоторый момент времени его начать, и в некоторый момент времени его закончить. Оба эти действия выполняются одной и той же командой в командной панели основного окна — Замер производительности . По окончании замера будет автоматически открыта панель Замер производительности , содержащая результаты замера.

Замер при старте приложения

1. В командной панели основного окна нажмите , чтобы включить замер производительности;
2. Запустите прикладное решение в режиме отладки;
3. После того, как нужные действия будут выполнены, в командной панели основного окна нажмите , чтобы выключить замер производительности;
   • будет открыта панель Замер производительности .

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

Замер произвольного участка интерактивных действий

1. Запустите прикладное решение в режиме отладки;
2. Подготовьте приложение к выполнению требуемого участка;
3. Перейдите в 1C:EDT и в командной панели основного окна нажмите , чтобы включить замер производительности;
4. Перейдите в прикладное решение и выполните требуемую последовательность действий;
5. Перейдите в 1C:EDT и в командной панели основного окна нажмите , чтобы выключить замер производительности;
   • будет открыта панель Замер производительности .

Замер произвольного участка программного кода

точки прерывания в начале и в конце того участка, который вы хотите замерить;
1. Запустите прикладное решение в режиме отладки;
2. Выполните последовательность действий, которая приводит к остановке в начале вашего участка;
3. После того, как исполнение остановлено, в командной панели основного окна нажмите , чтобы включить замер производительности; исполнение программы;
4. После того, как исполнение будет остановлено в конце вашего участка, в командной панели основного окна нажмите , чтобы выключить замер производительности;
   • будет открыта панель Замер производительности .

Замер при завершении работы приложения

1. Запустите прикладное решение в режиме отладки;
2. Подготовьте приложение к выполнению требуемого участка;
3. Перейдите в 1C:EDT и в командной панели основного окна нажмите , чтобы включить замер производительности;
4. Выполните последовательность действий и завершите работу прикладного решения;
   • будет открыта панель Замер производительности .

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

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

1. Нагрузка, создаваемая пользователями относительно СУБД: "Время захвата СУБД" (db-proc-took) и "Очередь захвата СУБД" (количество сеансов пользователей, стоящих в очереди)
2. Нагрузка, создаваемая пользователями относительно сервера 1С: "Время вызова текущее" (duration-current) и "Очередь пользователей по времени вызова" (количество сеансов пользователей, стоящих в очереди).
3. Общее состояние серверов 1С и СУБД.

По данным 1C its выбранные в задаче параметры хорошо характеризуют "жизненные" показатели сервера, чуть более подробно про них расскажем в конце статьи. Обратите внимание, что интерпретация этих показателей зависит от конкретной ситуации, но в целом прослеживаются общие черты.

Подключим замеры счетчиков от сервиса RAS 1С!

Для выполнения данной процедуры мы должны использовать обработку подключения к службе RAS «МониторRAS_1C.epf», которую предварительно нужно скачать и загрузить в базу мониторинга (укажите размещение в разделе "Замеры").

1. Сначала создадим новый замер . Для этого перейдите в замеры и создайте замер под наименованием «Лариса наблюдает за RAS 1C» и укажите следующие параметры:

• глубина хранения 5-7 дней;
• тип замера - "произвольный";
• загрузка в реальном времени;
• обработка - «МониторRAS_1C.epf».

2. Настраиваем обработку замеров . Переходим в замеры, открываем дополнительные обработки и выбираем "Настройка 'Монитор RAS 1C'". Открываем форму настроек монитора и указываем следующие параметры и выполняем действия.

• замер - «Лариса наблюдает за RAS 1C»
• путь к серверу 1С и порт RAS сервера (если у вас не установлена служба RAS, то выполните ее установку прежде)
• выбираем кодировку файла (обычно "cp866")
• После настроек жмем кнопку получить список кластеров и в случае успеха у нас должны появиться данные, по крайней мере одна новая строка. Если у вас для кластера используется авторизация, тогда укажите имя пользователя и пароль.
• Далее устанавливаем флаг получать детальные записи (вкладка "Свойства/Корзина"). В рамках этого мы сможем получать историческую информацию о всех событиях. Если вам не нужны агрегирующие функции, но детальные записи списка хотите получать, то необходимо добавить в корзину любое свойство без выбора функции агрегации.
• Добавляем к агрегирующим функциям (вкладка "Свойства/Корзина") следующие параметры согласно таблице, ниже:

• Далее установим цветовую раскраску и граничные значения для показателей (вкладка "Цветовая индикация"), в рамках которых мы сможем просматривать на графике агрегации две дополнительные линии уровня и увидим раскраску в таблице данных соответствующую ситуациям находящимся в желтой и в красной зонах. Согласно таблице:

3. Выполняем тестовый замер . Для проверки выполнения замера нажимаем кнопку выполнить замер. В результате правильных настроек у нас с вами должны появиться записи в журнале событий замеров.

4. Подключаем в замере регламент .

• для регламентного задания обязательно указываем пользователя, у которого снят запрет на защиту опасных действий.
• время обновления рекомендуем установить в районе 60 секунд (120 секунд максимум)

5. Открываем обработку монитора и проверяем работу .

• Переходим в подсистему замеры и открываем дополнительные обработки;
• Находим "Монитор 1С" и запускаем;
• Выбираем замер и нажимаем обновить данные.

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

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

Видео-урок.

Быстрый старт. Видео-урок настройка и подключение монитора для сервера 1C RAS

Как это все использовать?

Приведем несколько примеров использования данной информации на практике, продолжаем:

а) Как узнать кто и что запускал? Какое фоновое задание крутилось или крутится сейчас?

В данном случае нам необходимо воспользоваться историей замера или текущей ситуацией монитора. Открываем список сеансов (sessions) и ищем "проблемного" пользователя и его номер сеанса:

Далее открываем рабочую базу, журнал регистрации и ставим отбор по номеру сеанса и отбор по периоду времени этого события

В результате у нас есть понятие что запускалось и какие действия выполнялись или выполняются сейчас.

б) Хорошо или плохо серверу? Кто у нас нагрузил сервер 1С? Кто у нас грузит сервер SQL?

Открываем монитор и начинаем анализировать данные. Можно сделать следующие выводы, что пользователь запустив какой-либо процесс (обработка/фоновое задание) может довольно серьезно снизить производительность базы 1С. На рисунке ниже показаны два графика загрузки процессора и роста счетчика "Захвачено СУБД", на которых прослеживается корреляция.

О чем говорят показатели:

"Захвачено СУБД" - содержит время соединение с СУБД с момента захвата в миллисекундах (у нас преобразовывается к секундам). Характеризует текущую нагрузку сервера СУБД. Чем больше значение и чем больше сумма по этому полю для всех пользователей (очередь захвачено СУБД), нагружен сервер и тем более ему становится хуже. К примеру, кто-то запустил сложный SQL запрос к базе данных.

"Время вызова (текущее)" - содержит интервал времени в миллисекундах (у нас преобразовывается к секундам), прошедший с момента начала обращения, в случае, если сеанс выполняет обращение к серверу 1С:Предприятия. Чем больше значение и чем больше сума по этому полю для всех пользователей (очередь время вызова), тем более нагружен сервер 1С и тем более ему становится хуже. К примеру, кто-то запустил пустой бесконечный цикл, серьезные вычисления.

Большой рост по обоим показателям (выше) - говорит о том, что сервер гарантированно идет на "посадку". К примеру, запускаем процедуру удаление помеченных объектов или замену дублей в рабочее время, посчитать себестоимость и т.п.

в) Оповещение через мессенджеры с помощью Ларисы и предсказание возможных проблем производительности .

Это тема отдельной статьи, но мы поясним основные моменты в кратком изложении.

• Зная значения счетчиков производительности 1С можно сделать некоторые логические выводы. К примеру, если "Захвачено СУБД" от 0 до 60 сек, это норма (low), если от 60 до 300 сек - уже желтый (medium) уровень, а вот если более 300 сек - совсем плохо (high).
• Обладая информацией о связанном поведении наборов можно сделать определенные логические суждения.

• Исходя из предыдущих суждений можно настроить оповещения при переходе из одного состояния в другое (FSM или HFSM). Т.е. если существует большое значение "Захвачено СУБД" и идет рост очереди пользователей, то значит ситуация усугубляется и пора бить в набад.

г) Анализ изменений параметров сервера или базы . Пример: Корректировка количества соединений на процесс. В начале рабочего дня в Москве у нас стали возникать проблемы производительности (недавно перешли на новую подверсию платформы), связанные с резким наплывом пользователей (+200 в течении 30-40 минут), которое потом через 1-2ч снижалось. В результате анализа графиков было установлено, что 1С с запаздыванием (20 минут) отрабатывало запуск новых процессов и в моменты запуска производительность достаточно сильно снижалась.

Графики количества запущенных процессов (rphost.exe) и очереди сеансов к серверу 1С Предприятие (день первый).

В результате было предложено уменьшить количество соединений на кластер на 30% (в совсем новой версии 1С уже появилась возможность заранее создавать резервные процессы). В результате нагрузки связанные с запуском хостов практически исчезли. Количество пользователей и интенсивность работы одинаковая в эти два дня.

Читайте также:

  
• Как получить структуру конфигурации 1с
  
• Как сделать чтобы ссылка не открывалась в браузере
  
• Поиск по содержимому excel файлов
  
• Программы спортивные трекеры для андроид
  
• Где находится burn в фотошопе