This is topic Calc loop is big in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/35/t/000317.html

Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Увидел в лог файле МРВ вот такую запись.
00:16:25 0000 00000001[1] Calc loop is big.
Что это означает?
Плохо это или хорошо?
Если плохо то как это исправить?
 
Posted by Nico (Участник № / Member № 5342) on :
 
Если при старте МРВ и один раз ничего страшного
Сообщение выдается когда текущиии операции потока пересчета CALC занимают больше времени сем заданное время цикла пересчета
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Происходит рас в 5-6 часов. Цикл чего интересно поменять стоит, пересчета самого узла?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Желательно выяснить причину таких эпизодических перегрузок.
Следует мониторить диагностическую переменную @Calc_Loop, которая вернет реальное время цикла пересчета, и системную переменную @Calculate_Cycle, которая возвращает реальное время, затрачиваемое на основной цикл обработки базы каналов.
Эти переменные можно архивировать, чтобы затем сопоставить с реальными процессами и сообщениями.
Самый протсой вариант - заданный цикл для реального процесса достаточно мал, значение @Calculate_Cycle близко к заданному значению цикла и за счет каких-то случайных составляющих возникают редкие перегрузки.
Более сложный случай, если @Calculate_Cycle постоянно существенно меньше заданного цикла и только эпизодически становится сравнимым с ним.
Причина может быть как в эпизодически расширяемом объеме вычислений, так и, например, в возрастающих затратах на проведение файловых операций, реализуемых в основном потоке (атрибуты 128 и 129 каналов CALL).
Причем затраты времени на эти файловые операции могут существенно зависеть от загрузки ОС другими задачами подобного рода.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Эти ктовасии происходят при записи данных каналов во внешнюю БД.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Такие записи осуществляются 1 раз в 5-6 часов?
 
Posted by Nico (Участник № / Member № 5342) on :
 
Канал CALL.sql период пересчета желательно
свой поток или Idle
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
quote:
Отправитель / Originally posted by AdAstra Technical Support:
Такие записи осуществляются 1 раз в 5-6 часов?

Нет каждые 10 секунд. До заполнения баз данных внешних. Такова не было. Поэтому думаю именно на SQL. Такое происходит на 6 разных проектах.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Уточните, пожалуйста.
"Такого не было" до каких пор?
Если записи осуществляются каждые 10 секунд, то что происходит "через 5-6 часов"?
Что означает "До заполнения баз данных внешних."?

Рекомендация NICO "Каналу CALL.sql желательно задать период пересчета "Свой поток" или Idle " очень существенна.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Пока я не сделал запись значений каналов в БД MSSQL каждые 10 секунд, все было нормальна. Каждые 5-6 часов происходит запись в лог сообщения Calc loop is big.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Как уже было указано, каналу CALL.sql желательно задать период пересчета "Свой поток" или Idle.

Следует убедиться, что все записи в БД осуществляются успешно и при необходимости снизить интенсивность потока записей, если драйвер ODBC не справляется с заданным потоком.

Надо провести мониторинг реального времени, затрачиваемого на основной поток (как было предложено выше) и принять необходимые меры, вплоть до увеличения цикла обработки базы каналов.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Значения переменой @Calculate_Cycle находятся в диапазоне от 1 до 102.
Значения переменой @Calc_Loop = 562.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Есть ли способ если выставить эти периоды пересчета "Свой поток" или Idle ". Записывать в БД четко раз в 10 секунд значения каналов. А то там пишется как угодно только не как надо, то раз в 9,10,11 секунд.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В редакторе канала на вкладке "Основные" есть поле "Единица измерения", которая задает тип периода обработки (см. "Каналы и системные переменные/Пересчет базы каналов/Период пересчета каналов").
В этом поле из списка можно выбрать "Цикл IDLE" и "свой поток".

Надо знать, насколько ODBC-драйвер в состоянии поддерживать предлагаемую Вами интенсивность записей и как Вы организуете цикл записей всех каналов 1 раз в 10 сек.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
ODBC-драйвер использую SQL Native Client. Запись в БД происходит по примеру из книги где описана запись в БД Access.

Хорошо.Единица измерения = Цикл IDLE, Период = 1. Это сколько во времени? Или это период это 1 попугай и ко времени вообще не относится. Какой период поставить чтоб один раз в 10 секунд отработало? А не
как попало, если это вообще возможно.

На данный момент стоит единица измерения = сек, период = 5. Запись происходит, все четко один раз в 10 секунд. Период пересчета базы каналов стоит 550 миллисекунд.

С "Цикл IDLE" и "Свой поток" так четкой записи не происходит. Она все время в разные промежутки идет то раз в 9 секунд пишет, то раз в 10, то раз в 11. Нету стабильности записи.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Цикл IDLE может быть задан ключом в файле *.cnf конфигурирования запуска узла:
" IDLLOOP=<idlLoop> – время цикла IDLE как число основных циклов (ср. @Calc_Loop OUTPUT с Параметр=18). Значение по умолчанию:
1, если время основного цикла больше 1 с;
1000мс/<время основного цикла, мс>, если время основного цикла меньше 1 с; "

В примере из книги ("Быстрый старт"?) описывается запрос типа SELECT и управляется он с экрана с помощью кнопки.
Уточните, пожалуйста, используемый Вами алгоритм вызова SQL-запроса с записью данных в БД.
Каким образом при периоде обработки CALL.SQL 5 сек. Вы получаете период записи 10 сек.?
Сколько каналов CALL.SQL Вы запускаете 1 раз в 10 сек.?
Сколько переменных записывается в каждом запросе?
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Запрос на INSERT. Делаю вызов запроса не по кнопке. Вызываю его просто программой (программу привязываю к запросу и вызываю запрос нужного номера ну к примеру в программе пишем SQL=1(т.е будет выполнятся запрос под номером 1)). Программа работает в цикле CALC = 550мс.
Каким образом при периоде обработки CALL.SQL 5 сек. Вы получаете период записи 10 сек.? - Не знаю каким образом это происходит. Но замечено, опытным путем, что если поставить 2 секунды допустим, то период записи в БД будет 4 секунды. То есть Период канал CALL.SQL = n, то в БД записи будут добавляться с периодом n*2.
Сколько каналов CALL.SQL Вы запускаете 1 раз в 10 сек.? - Я запускаю один канал CALL.SQL один раз в 5 секунд. Это запись в базу данных происходит один раз в 10 секунд а не вызов канала.
Сколько переменных записывается в каждом запросе? - 42.

То есть выглядит примерно так
CALL.PROGRAM(Период=1, Единица измерения = CALC) вызывает канал CALL.SQL(Период=5, Единица измерения=сек).
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Надо задать каналу CALL.SQL период 1*"цикл CALC", а выдачу "1" на его вход от программы - с перидом 10 сек. (например, сделать период CALL.Program равным 10 сек.).
Период обработки базы каналов (в настройках узла) для повышения точности надо задать 50*0.01.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Выслал проект, а то я уже запутался что куда. Этот проект пишет в БД с интервалом в 10 секунд.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Выслал модифицированный проект.
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Спасибо. Не могли бы вы разъяснить мою ошибку?
 
Posted by Жигалов Денис Николаевич (Участник № / Member № 6035) on :
 
Тест вашего исправленного проекта. Показал не стабильность. Нету четкости записи. Опять повторяется, что запись не идет строго каждые 10 секунд. А зависит от нагрузки ПК. Есть даже результат что запись в БД идет раз от полутора до пяти минут.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Задайте в "Адинистраторе источников данных ODBC" функцию трассировщика.
1. Задайте в файле конфигурирования запуска узла ключ
DEBUGON=46000
2. Задайте в проекте ОТ.
3. Установите каналу вызова SQL-запроса флажок "Отладка" и флажок "Отчет тревог".
каналу CALL.SQL
4. По протоколу профайлера и по отчету тревог уточните динамику и ошибки отработки канала вызова SQL-запроса. В профайлерном протоколе должны быть зафиксированы моменты начала и конца транзакции и ошибки, зафткстрованные МРВ.
5. По протоколу трассировщика ODBC-драйвера можно увидеть были ли ошибки в транзакциях.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2