5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С
База данных - HighLoad оптимизация
Какой профит?
- Простая установка и настройка - за 15 минут рабочее решение для "неограниченного" количества баз
- Ничего лишнего и никакой "магии" - используются возможности платформы
- Дружественный интерфейс - только то что нужно
- Информация в реальном времени - ошибки конфигурации, блокировки, длительные запросы и др.
- Бесплатно - проект с открытым исходным кодом на GitHub
Структура статьи:
В первой части статьи мы приводим список и описание из 5 шагов для самостоятельного выполнения процедуры. Если же Вам лень читать и Вы любите смотреть и слушать, то можно перейти к видео-уроку и посмотреть небольшой 5 минутный ролик по выполнению необходимой последовательности действий и повторить при необходимости.
Проект 1с-parsing-tech-log является open source. Уже более года мы активно и продуктивно используем данную систему в облаке для мониторинга наших приложений.
1. Установим
Рассматриваются два варианта:
- Подключаемся к проекту через EDT, закачиваем конфигурацию с репозитория и разворачиваем базу.
(github.com/Polyplastic/1c-parsing-tech-log) - Для тех кто по каким-то причинам не хочет использовать EDT скачиваем скомпилированную конфигурацию и разворачиваем через привычный конфигуратор.
(Решение проблемы быстродействия в ERP на рабочем примере)
Совет. Боевую базу мониторинга лучше всего развернуть на отдельном сервере, по крайней мере на отдельном кластере.
2. Определим цели и задачи
Что мы будем мониторить? Проблемные ситуации влияющие в целом на производительность и работоспособность базы:
- блокировки,
- долгие запросы более 60с,
- ошибки.
Вы можете использовать эти или добавить/выработать другие критерии. Ситуации, которые описаны говорят сами за себя и расшифровывать их не будем.
Зачем будем мониторить? Для возможности проведения анализа проблемных ситуаций возникающих при работе базы и последующему их исправлению. Ознакомлен - значит вооружен.
3. Настроим технологический журнал (ТЖ) для 1С
Давайте настроим конфигурационный файл для технологического журнала всех указанных случаев. Эту операцию настроим вручную с использованием Notepad++. Однако вы всегда можете воспользоваться специальной обработкой с ИТС для настройки этого файла.
Каждую проблемную ситуацию будем выгружать в отдельный каталог и обрамляется она тегом "log" (примерный исходный код файла приведен ниже). Эти каталоги должны быть видны с сервера где развернута наша конфигурация - можно сделать общий каталог.
Созданный файл "logcfg.xml" копируем в папку с установленным предприятием 1С боевого сервера (обычно куда-то по похожему пути: "c:\Program Files\1cv8\8.3.12.1855\bin\conf\").
Пример файла "logcfg.xml":
Совет. Обязательно ставьте фильтры для настроек технологического журнала. Никогда не сохраняйте всё подряд. Для рассматриваемого примера нам важны только проблемные ситуации, а не весь стек всех возможных событий.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<!-- сохраняем ошибки //-->
<log location="C:\v8\excp\" history="8">
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
<!-- сохраняем ошибки запросов //-->
<log location="C:\v8\qerr" history="8">
<event>
<eq property="name" value="QERR"/>
</event>
<property name="all"/>
</log>
<!-- сохраняем конфликт блокировок //-->
<log location="C:\v8\locks\" history="8">
<event>
<eq property="name" value="EXCP"/>
<like property="Descr" value="Конфликт блокировок%"/>
</event>
<property name="all"/>
</log>
<!-- сохраняем длительные запросы более 60 сек //-->
<log location="C:\v8\query1с" history="8">
<event>
<eq property="Name" value="SDBL"/>
<ge property="Durationus" value="60000000"/>
</event>
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Durationus" value="60000000"/>
</event>
<property name="all"/>
</log>
</config>
4. Настроим базу мониторинга
Теперь перейдем к настройке самой базы мониторинга. Наши логи уже начали формироваться, т.ч. продолжим.
- Создаем в справочнике "Замеры" три замера с наименованиями по ситуациям: блокировки, долгие запросы и ошибки;
- Указываем путь к соответствующим каталогам;
- Ставим флаг "загружать в реальном времени" - означает, что данные будут подгружаться автоматически регламентным заданием;
- Ставим флаг "загружать автоматически" и указываем интервал загрузки 5-10 минут - будет загружаться по регламентному заданию;
- Детализируем расписание загрузки лога.
После создания замеров с указанными параметрами загрузка логов технологического журнала будет выполняться автоматически (по регламентному заданию для каждого замера).
Совет. Вы можете для каждого замера указать фильтры загрузки данных из логов, чтобы ограничить количество и качество поступаемой информации (дополнительно к настройкам logcfg.xml). К примеру, игнорировать события не подлежащие анализу - обрывы соединений и т.п.
5. Запустим и проверим
Фактически все необходимые операции мы выполнили и теперь можно проверить что получилось.
Для анализа ситуации у нас имеются следующие обработки:
1. Журнал событий замеров. Позволяет просматривать список событий в временной последовательности с отборами и сортировками.
2. Рабочее место по изменению количества событий. Позволяет сравнить изменение количества событий на временной относительной оси по двум временным окнам, к примеру, сравнить среду и вторник текущей недели или разных.
Совет. Для изменения состава отображаемых колонок (добавить новые поля через ссылку, которых нет изначально) в динамическом списке пользуйтесь возможностью "изменить форму" через "еще".
Видео-урок.
В этом видео-уроке мы с вами установим конфигурацию "Анализ ТЖ", проведем необходимые настройки и посмотрим результаты на примере искусственных ситуаций.
Дополнительно.
Подключиться к проекту или его скачать вы можете с git-hub репозитория polyplastic 1c-parsing-tech-log.
Если хотите посмотреть в действии и вам "лень" ставить/компилировать EDT, то можете воспользоваться ссылкой для скачивания присоединенного файла конфигурации из статьи Решение проблемы быстродействия в ERP на рабочем примере. Также в этой статье приводится методика пример выполнения задачи оптимизации проблемного участка для базы 1С.
Есть ли аналоги? К аналогам в какой-то мере можно отнести: Notepad++ и другие механизмы полу-ручного анализа; ЦУП от 1С из Корпоративного инструментального пакета.
Исправления и анализ проблемных ситуаций.
Проблемы исправляются в зависимости от проведения анализа и дальнейшей классификации. К примеру, выявленные ошибки можно классифицировать по следующим уровням:
- ошибки разработчика - ошибки вызванные результатом деятельности разработчиков. Локализуются, формируются задачи на исправления через систему баг трекинга и исправляются последующими релизами;
- ошибки системные - ошибки вызванные проблемами окружения: доступ, отсутствие сети, проблемы внешних ресурсов, недостаток места на диске или выделенной памяти и др. Локализуются и в зависимости от возможности исправления формируются задачи на их устранение.
Наличие "долгих" запросов сообщает о проблемах в производительности базы данных. Для их анализа и наличия можно воспользоваться журналом "свойства замеров" с сортировкой по длительности и фильтром за сегодня. Их можно классифицировать
- проблемы rls - вызваны сложными ограничениями и/или не верным назначением прав доступа;
- проблемы запроса - не правильный запрос, который стоит оптимизировать;
- проблемы производительности - проседание мощности в часы пик или по другим подобными причинам.
Наличие конфликта блокировок говорит об наличии определенных ситуациях в базе приводящих к отказам в действиях пользователей. Их рост во временном интервале может свидетельствовать о грядущих проблемах, который может быть связан с ростом пользователей, проблемами архитектуры и требует незамедлительных мероприятий по устранению. Провести анализ ситуации во времени можно с помощью рабочего места "анализ".
Вступайте в нашу телеграмм-группу Инфостарт
Анализ технологического журнала мониторинг
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
HighLoad оптимизация Разработчик 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)
Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.
10.11.2025 15873 ivanov660 48
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:ERP Бесплатно (free)
Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.
18.02.2025 16481 ivanov660 39
HighLoad оптимизация Системный администратор Разработчик 1C:ERP Бесплатно (free)
Не всегда индексирование с дополнительным упорядочиванием полезно.
04.02.2025 15126 ivanov660 21
HighLoad оптимизация Технологический журнал Системный администратор Разработчик Бесплатно (free)
Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.
24.06.2024 19112 ivanov660 13
HighLoad оптимизация Разработчик 1С:Предприятие 8 Бесплатно (free)
Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.
06.06.2024 24972 Evg-Lylyk 73
Технологический журнал Разработчик 1С:Предприятие 8 Бесплатно (free)
Шпаргалка по настройке технологического журнала.
27.04.2024 72317 kuzyara 9
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.
13.03.2024 14607 spyke 29
HighLoad оптимизация Разработчик 1С:Предприятие 8 Бесплатно (free)
Оказывается, в типовых конфигурациях 1С есть, что улучшить!
13.03.2024 17009 vasilev2015 22
И что самое ценное - при появлении какой-либо задачи, я могу легко доработать. К тому же предлагаемые некоторые возможности и функционал нашей разработки уже значительно превышают возможности указанных инструментов.
1. Проект развивается. На текущий момент доступен такой функционал.
2. В вашем случае мы используем дополнительно другие инструменты и методики для поиска сопоставления запроса с точкой в конфигурации (когда не понятно).
Жалко нет скриншота с возможными настройками, непосредственно связанными с анализом разобранного тех журнала
И ещё резонный вопрос - как это всё хранится - скажем, если тех журнал весить в тексте 1Gb то сколько он будет весить в такой аналитической базе (с учётом того, что всё что есть в тех журнале - загружается в базу).
Понятно, что объёмами тех журнала в 1Gb даже в день никого не удивишь и не шокируешь - но в больших базах, в час, тех журналы, ежедневно, бывают и по 10Gb на сервер/ИБ, а уж в периоды сдачи отчётности или под НГ могут быть и по 100Gb в час - даже если в них писать только самое важное - итого - у крупных организаций с кучей баз это будут, в пике, уже десятки терабайт в сутки! Даже если хранить это всё не более суток, как с этим объёмом справится данная аналитическая база? Компактность хранения, фильтрации, и насколько эффективно идёт разбор таких больших логов?
Да и, смотрю, нет никакой защиты от чрезмерного роста объёма данных - а желательно бы - на кризисный случай: т.е. хотя бы ограничить не только сроком хранения, а, скажем, числом записей тоже (причём, хорошо иметь не только общий максимум, но и отдельно - по каждой ИБ).
1. Удаление старых событий или "нет никакой защиты от чрезмерного роста":
- Есть константа "УдалятьУстаревшиеСобытия" и регламентное задание "УдалениеУстаревшихСобытий".
- Для замеров есть параметр Глубина Хранения - при условии не равном "0" данные будут очищаться.
2. "..журнал весить в тексте 1Gb.." - ставьте фильтры на собираемые данные. Для действительно полезных данных объемы значительно меньше!
3. В журнал событий замеров можно вывести информацию о всех доступных свойствах лога в сообщении:
p:processName - имя базы.
t:computerName - имя компьютера,
t:applicationName,
#Пользователь,
#Описание
и другие смотрите описание о назначении для формата лога технологического журнала
(Как добавить колонки я писал в статье и показал в видео).
Далее создаете отборы в динамическом списке по полям и получаете необходимые отборы.
Таже мы рекомендуем ставить отбор на форме журнала "Дата события больше Начало этого дня".
Замер для каждого сервера отдельно, у вас не получится писать в одну папку на диске разным серверами 1С.
Базу для каждого сервера не обязательно создавать - вы создаете замер под каждый каталог, к примеру, "замер для сервера1 по ошибкам", "замер для сервера 2 по блокировкам", "замер для сервера 3 только для базы ERP по длительным запросам" и т.п.
4. Если у вас возникнут идеи по "фитчам", то пишите в issues, а еще лучше подключайтесь)
К примеру, можно добавить справочник сервер и сделать его реквизитом замера.
5. Анализ разобранного журнала это отдельная сложная задача и не входит в рамки этой промо-статьи. Для разных ситуаций оптимальны разные наборы колонок и отборов. В дальнейшем приведем еще некоторые примеры использования - все зависит от востребованности данного инструмента коллегами.
Это прекрасно! Ставьте фильтры, готовьте данные вручную. Да на какой хрен тогда нужна эта утилита. Я таким же образом могу тех журнал в CSV перегнать и фильтры в Excel ставить
Разверну немного ответ почему необходимо ставить фильтры и зачем:
Входная информация
1. Сама 1С говорит никогда не сохраняйте все подряд. Это много лишней и ненужной информации.
2. Человек не может обработать психологически, а иногда физически большие объемы. И через какое-то время просто перестается проводится обработка.
3. Мы когда мониторим проблемы (согласно статьи) выбираем какие-то определенные ситуации, которые по объему данных должны быть минимальны. В идеале событий должно быть 0.
Согласитесь, ошибок должно быть 0, блокировок должно быть 0, долгих запросов должно быть 0.
И как только появляются отклонения начинаем анализировать и искать пути решения. А после применения решения ситуация опять должна вернуться к 0.
Если же все время висит проблема, которую мы не можем исправить или она нам не критична (ошибки коннектов и т.п.), то мы ее исключаем через настройку тж или фильтры замеров. Можно выделить при необходимости в отдельный фоновый замер - типа шум.
В результате. Проводить определенные настройки необходимо, т.к. от конкретной ситуации зависит многое (решение из коробки нужно допилить) - это думаю ясно.
В случае использования нашего инструмента нет необходимости использования сторонних решений, нет лишних преобразований, манипуляций, необходимости вызывать шамана знающего перл и RegExp. Тут нет никакой готовки данных вручную.
Проведение настроек, если есть понятие что делать занимает очень мало времени и выполняется практически разово в данном контексте.
блокировки могут вам положить базу 3 апреля и до конца месяца вы не досидите - куй железо пока горячо.
Минимальные телодвижения и расход мозготоплива придется совершать и расходовать в любом случае.
Однако, если у вас нет необходимости в оценке и отслеживании как дела там у меня на проде и ждем когда гром грянет, это ваш выбор.
Ошибки - штука полезная, но любое исключение, которое обрабатывается в попытке, будет валиться в журнал.
Еще бы неплохо мониторить вызовы - память, длительность. И ожидания на получение блокировки - TLOCK. Конфликт блокировок отлавливается в том же TLOCK, TTIMEOUT и TDEADLOCK, а не в исключениях.
Поверхностно, очень поверхностно...
1. Да, вы почти правы делить надо на 10 000, т.е. поправить надо на 600 000.
2. В текущем варианте система не предлагает полноценной замены Тест Центра, но даже текущих возможностей достаточно, чтобы получить определенного минимума информации, особенно актуально у кого нет ничего и для них ТЦ - это космос.
3. Для получения информации по вопросам про нагрузку и другие параметры системы у нас стоит Zabbix.
1. Я полностью прав, микросекунд, 6 нулей плюсом. Пруф - . Кстати, тут же написано, что надо писать Durationus
2. Тест центр применяется для нагрузочного теста, а не мониторинга. Наверное имелся ввиду ЦУП. При этом на двух сдачах на эксперта ни разу не получилось его настроить, и по ощущениям особо он бы не помог.
3. Говоря про память, я имел ввиду Memory и MemoryPeak в CALL. Но в этом предложении важнее суммарная длительность. Сталкивался с огромным отчетом в 400 Гб базе, 30 секунд выполнялся запрос на СУБД, 10-15 минут длился вывод на экран на стороне сервера. При этом улетает память, нагрузка на процессор.
Поправьте logcfg.xml в статье. Во-первых он у меня не "взлетел", копировал из вашей публикации. Не знаю с чем это связано (может комментарии, может какие спец. символы в xml), но я настроил его по аналогии с нуля. Во вторых Вы указывается длительность запроса "60000", а это 6 секунд, а не 60. Надо добавить еще один ноль справа.
Кто мне скажет, есть ли обратная операция для Like в logcfg.xml, хочу сделать "Not Like", некоторые события в ТЖ нормальные, но их слишком много и они мне не нужны?
1. Поправил. Duration (в 10 000 долях секунды) использовалось до версии 8.3, но работает и видимо оставлено для совместимости. Изменил на рекомендуемое значение Durationus и значения в миллионных долях секунды. Пример: Durationus="20000000" это 20 секунд.
2. Не забывайте, что формат файла "logcfg.xml" нужно ставить в utf-8. Также если при вставке добавятся "левые" символы, то соответственно работать не будет.
3. Фильтр на исключения можно добавить на вкладке "Фильтры" замера в поле "Исключить" (по правилам RegExp). Пример:
,Descr=[\s\S]*(Сеанс отсутствует или удален|Текущему соединению с информационной базой не назначен сеанс|Требуется переустановка соединения)
У Вас работает ТЖ с русскими комментариями?
Журнал процесса выполнения:
Ссылка на неизвестный метод - CommonModule.ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное
Ссылка на неизвестный метод - CommonModule.ОбновлениеДанныхРегламентное.УдалениеУстаревшихСобытий
РегламентноеЗадание.Автозагрузка - Имя метода должно быть задано
РегламентноеЗадание.УдалениеУстаревшихСобытий - Имя метода должно быть задано
ФункциональнаяОпция.ИспользоватьПолнотекстовыйПоиск - Не установлено Хранение функциональной опции
"Формат данных XML EDT версии (0.0.0) проекта 'parsing-tech-log' несовместим с текущей версией EDT (1.9.2).
Пожалуйста, сделайте реимпорт проекта из информационной базы".
Это при импорте проекта хоть с локально загруженного, хоть непосредственно с github.
Помогите разобраться, плз.
1. Будет работать и на линукс, но не весь встроенный функционал.
2. Функционал разбора ТЖ 1С использует COMОбъект("VBScript.RegExp") и не доступен на linux.
Данную проблему можно обойти если написать дополнительную внешнюю обработку на других компонентах, которая поддерживает linux.
У нас такой потребности нет, если вдруг найдутся энтузиасты и сделают pull request в проект, то велком.
3. Можете использовать другой функционал при необходимости.
P.S. Open Source в русском сегменте тяжело идет, а в 1С вообще со скрипом(
(60) Судя по всему соединение держалось продолжительный период, ничего необычного.
Я вижу что вы не перезагружаете сервера 1С, все же лучшая практика - это принудительная перезагрузка. Настройте за правило перезагрузку раз в сутки в технический промежуток времени.
Скоро подъедет механизм загрузки данных параметров состояния кластеров через ras.
Через нее можно будет мониторить дополнительные данные о параметрах процессов, сеансов и др.
1. Да, сможете. Только учтите некоторые особенности запуска регламентного задания для файловых баз. Тут вариант либо через Windows Task Manager или придется все время держать открытое клиентское приложение.
2. Я так понимаю лишних лицензий на сервер нет, а то можно было вынести запуск регламентных заданий на Windows сервер.
- парсинг ТЖ работает только под ОС windows.
- в настройках для оперативного чтения должен стоять флаг "загрузка в реальном времени" иначе будет загружать только по прошествии часа, когда 1с открывает новый файл для записи, а текущий закрывает (думаю вот тут не установлен).
- руководство пользователя скоро опубликую, уже где-то на 70-80% готов первый вариант.
Что посмотреть через отладку :
1. Проверьте доступ к файлам.
2. Проверьте наличие ошибок в журнале регистрации
3. Могу предложить посмотреть в отладчике по следующему алгоритму:
а) откройте конфигуратор или edt
б) установите точки останова в следующих позициях
- ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное
- ОбновлениеДанных.РазобратьФайлВСправочник
в) выберите или создайте замер
г) нажмите кнопку "выполнить загрузку"
д) В процедуре "ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное" у вас должен вернуться массив ФайлыДляЗагрузки
...
//Получить файлы для загрузки
Если РеквизитыЗадания.ТипЗамера=ПредопределенноеЗначение("Перечисление.ТипыЗамеров.ТехнологическийЖурнал") Тогда
// Тут должен вернуться массив файлов
ФайлыДляЗагрузки = ПолучитьСписокФайлов(РеквизитыЗадания);
ИначеЕсли РеквизитыЗадания.ТипЗамера=ПредопределенноеЗначение("Перечисление.ТипыЗамеров.PerfomanceMonitor") Тогда
ФайлыДляЗагрузки = ПолучитьСписокФайловPerfomanceMonitor(РеквизитыЗадания);
Иначе
...
Показатье) В случае наличия файлов, должна запуститься процедура обработки "РазобратьФайлВСправочник". В ней должны выполниться условия, что чтение не завершено и файл более 3х байт. Далее идет разбор текста.
Не путай длительность при описании события в настройках, и то, как оно в самом логе выглядит)
Ещё раз: в настройках указываются десятитысячные секунды, а самих в логах - миллионные.
Написать обработку загрузки данных не проблема, однако не понятно что вы хотите в них почерпнуть?
Для мониторинга операций пользователя используйте ТЖ 1С на пользовательском компютере:
1. создайте файл настроек logcfg.xml (с необходимыми настройками)
2. в этом файле пропишите путь к сетевому каталогу видному как от сервера так и от пользователя к примеру: \\server\v8\log\Пользователь1
3. скопируйте в conf каталог (подобно "c:\Program Files\1cv8\conf\")
3. при запуске 1Ски в этот каталог будут писаться данные действий на клиенте.
1. Если этих полей не было ранее, то 1С еще их не связала. Требуется перезапуск приложения. После они появятся.
2. Они также появляются, если встречались при загрузке логов. Если не было загрузки логов с данными полями, то они не отобразятся. Проверить их наличие можно в справочнике "свойства". Т.е. если вы грузите, к примеру, один тип сообщений журнала, то он ограничен набором некоторых полей свойств.
3. А еще я рекомендую поля указывать в карточке "Замеры". Нажмите флаг "дополнять список набором полей" и на появившейся вкладке "Дополнительные поля для списка" укажите необходимые поля. Тогда при выборе замеров у вас автоматически будут меняться колонки, а не существовать всегда
вот система выдала такие данные что это значит? время огромное ! это зависщие сеансы?
по запросам к базе см. скрин максимальное время исполнения запроса 6,64 секунды и по этому вроде все ясно.
1. Это служебные сообщения - закрытие соединения. Попробуйте посмотреть в сторону длительных запросов.
2. По вопросу анализа проблем воспользуйтесь сначала статьей.
- соберите историю - оптимально за день
- в процессе отслеживайте информацию по тем графикам, про которые идет речь в статье (агрегирующие)
- проверьте совпадение проседаний производительности с ростом агрегирующих графиков. Думаю, что совпадения сразу будут видны.А далее возможно сразу будет ясно, кто "кладет" систему.
или вот еще... даленный хост принудительно разорвал существующее подключение. line=1452 file=d:\jenkins\ci_builder2\windowsbuild2\platform\src\rtrsrvc\src\
или вот src\rtrsrvc\src\remoteinterfaceimpl.cpp(736):
dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.
вобщем работа начинается нормально а через 3..4 часа база идет вразнос.. при этом характеристики сервера razen 2400g 4 ядра (8 потоков) озу 16 гб..
грешу на то что запросы неоптимизированы совместили 2 конфигурации УТ и СРМ да и к томуже в базу вносят доработки..
Т.е. вы должны увидеть картину снижения производительности, а уже далее смотреть кто это вызывает и почему.
В журнале логов ТЖ поищите долгие запросы, блокировки, ошибки в коде и т.д. Типовые смотреть не стоит - это обычно результат других причин.
можно с помощью этого инструмента получать статусы регламентных заданий и оповещать по указанным каналам об их успешном или неуспешном завершении?
Вы не задумывались реализовать многопоточную загрузку ТЖ? Понимаю, это не сложно сделать и самому, но, мне кажется, такая возможность пригодилась бы не только мне.
1. Задумывались, и даже, в какой-то ветке-альфа-версии была реализована такая возможность, но потом при почему-то она не зашла в мастер, надо поглядеть причину (скорее всего устроила текущая скорость загрузки и направили ресурсы на другие задачи).
Потоки мы ранее разбивали по файлам, и если загрузка в реальном времени и частота порядка 5-10 минут, то обычно для загрузки не большой объем файлов должен быть.
Поэтому актуальную многопоточную загрузку на мой взгляд логично ставить, если загружать большой пакет файлов не загруженных ранее.
2. Опишите чуть подробнее с вашей стороны почему понадобился вариант много поточности. Для реализации задачи требуется обоснование, т.к. ресурсы у нас ограничены для реализации. У вас большой лог данных? Требуется большая скорость обновления информации? Что-то другое? Какую задачу решаете?
3. Проект открытый, т.ч. если вдруг есть желание и возможность реализовать, то готовы принять pull request. По крайней мере можете создать issue и более предметно можем обсудить там.
Благодарю, я тоже разделил загрузку файлов на отдельные фоновые задания, до 12 одновременно, вроде работает. Вы ведь разрабатывали проект в EDT? Мало знаком с ним, поэтому, боюсь до pull-реквеста вам мне придется с ним разобраться)
Многопоточность понадобилась для загрузки и в дальнейшем анализа контекстов CALL'ов, которые собирались в течение около 2х недель, ~40гб логов, файлы до 80 мб каждый, всего за сутки загрузилось ~25%, ну это так, для информации. Можно было бы наверное быстрее, если бы не топорность моей многопоточности)
1. Можете скинуть в cf, сами добавим.
2. Понятна задача - загрузка большого объема данных
3. Увеличивая количество потоков можно и сервер положить, т.е. он не сможет выполнять другие задачи. Балансировка в руках пользователя.
4. С разделением по файлам, надо еще и разделять их по объему данных. Тут вообще правильнее делать менеджер потоков в потоке) Который будет раздавать каждому по файлу на загрузку, ждать выполнения каким либо потоком задания и давать ему следующий. И вот тут у 1С нет реализации Sleep. Чтобы наш менеджер не грузил за зря систему. Видимо получается что для менеджера потоков нужно делать отдельное задание, которое будет через интервалы запускаться и проверять завершенность потоков. Задачка довольно хорошая по объему.
хорошая конфигурация, но EDT не использую и не могу на GitHub найти файл "fuzzy.xml", который в руководстве упоминается
Добрый день.
1. Скачайте скомпилированный вариант .cf со страницы или из релизов проекта на гитхабе
2. Демонстрационные варианты настроек приведены в приложении статьи . Вы можете их использовать как вариант, но скорее всего понадобиться выполнить донастроить под свою рабочую систему - это экспертная настройка.
3. Если еще есть вопросы пишите в личку, можем обсудить.
Не могу запустить в работу релиз 1c@polyplastic.ru (2.0.9.9) .
Ошибка получения списка кластеров. Файл не обнаружен.
вручную команда отрабатывает rac.exe" cluster localhost:1545 list out ->1
Можете подсказать в чем проблема?
к примеру
можно использовать отбор по свойствам в формате регулярного выражения, пример на картинке
1. Конфигурация бесплатная. Использовать в коммерческих целях можете, ограничений в этом плане нет (соблюдайте п.2 и учитывайте п.3).
2. Авторское право. Сохраняйте ссылку и информацию на репозиторий и авторов (лично я против ребрендинга).
3. Отказ от гарантий. Мы не предоставляем какой-либо гарантии по использованию этого ПО или возмещения какого-либо возможного ущерба и т.п. (программа предоставляется «как есть»).
P.S. Если есть доработки и предложения присоединяйтесь будем рады.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1040073
Создание 18.04.19 10:50
Обновление 18.04.19 10:50
Просмотры 73467
Загрузки 0
Рейтинг
331
Комментарии 98
Код открыт Да
Рубрики HighLoad оптимизация Технологический журнал
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
