отправлено / posted
Увидел в лог файле МРВ вот такую запись. 00:16:25 0000 00000001[1] Calc loop is big. Что это означает? Плохо это или хорошо? Если плохо то как это исправить?
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Nico
Forum Professor / Завсегдатай форума
Участник № / Member № 5342
отправлено / posted
Если при старте МРВ и один раз ничего страшного Сообщение выдается когда текущиии операции потока пересчета CALC занимают больше времени сем заданное время цикла пересчета
Сообщения / Posts 879 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Происходит рас в 5-6 часов. Цикл чего интересно поменять стоит, пересчета самого узла?
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Желательно выяснить причину таких эпизодических перегрузок. Следует мониторить диагностическую переменную @Calc_Loop, которая вернет реальное время цикла пересчета, и системную переменную @Calculate_Cycle, которая возвращает реальное время, затрачиваемое на основной цикл обработки базы каналов. Эти переменные можно архивировать, чтобы затем сопоставить с реальными процессами и сообщениями. Самый протсой вариант - заданный цикл для реального процесса достаточно мал, значение @Calculate_Cycle близко к заданному значению цикла и за счет каких-то случайных составляющих возникают редкие перегрузки. Более сложный случай, если @Calculate_Cycle постоянно существенно меньше заданного цикла и только эпизодически становится сравнимым с ним. Причина может быть как в эпизодически расширяемом объеме вычислений, так и, например, в возрастающих затратах на проведение файловых операций, реализуемых в основном потоке (атрибуты 128 и 129 каналов CALL). Причем затраты времени на эти файловые операции могут существенно зависеть от загрузки ОС другими задачами подобного рода.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
quote:Отправитель / Originally posted by AdAstra Technical Support: Такие записи осуществляются 1 раз в 5-6 часов?
Нет каждые 10 секунд. До заполнения баз данных внешних. Такова не было. Поэтому думаю именно на SQL. Такое происходит на 6 разных проектах.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Уточните, пожалуйста. "Такого не было" до каких пор? Если записи осуществляются каждые 10 секунд, то что происходит "через 5-6 часов"? Что означает "До заполнения баз данных внешних."?
Рекомендация NICO "Каналу CALL.sql желательно задать период пересчета "Свой поток" или Idle " очень существенна.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Пока я не сделал запись значений каналов в БД MSSQL каждые 10 секунд, все было нормальна. Каждые 5-6 часов происходит запись в лог сообщения Calc loop is big.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Как уже было указано, каналу CALL.sql желательно задать период пересчета "Свой поток" или Idle.
Следует убедиться, что все записи в БД осуществляются успешно и при необходимости снизить интенсивность потока записей, если драйвер ODBC не справляется с заданным потоком.
Надо провести мониторинг реального времени, затрачиваемого на основной поток (как было предложено выше) и принять необходимые меры, вплоть до увеличения цикла обработки базы каналов.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Значения переменой @Calculate_Cycle находятся в диапазоне от 1 до 102. Значения переменой @Calc_Loop = 562.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Есть ли способ если выставить эти периоды пересчета "Свой поток" или Idle ". Записывать в БД четко раз в 10 секунд значения каналов. А то там пишется как угодно только не как надо, то раз в 9,10,11 секунд.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
В редакторе канала на вкладке "Основные" есть поле "Единица измерения", которая задает тип периода обработки (см. "Каналы и системные переменные/Пересчет базы каналов/Период пересчета каналов"). В этом поле из списка можно выбрать "Цикл IDLE" и "свой поток".
Надо знать, насколько ODBC-драйвер в состоянии поддерживать предлагаемую Вами интенсивность записей и как Вы организуете цикл записей всех каналов 1 раз в 10 сек.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
ODBC-драйвер использую SQL Native Client. Запись в БД происходит по примеру из книги где описана запись в БД Access.
Хорошо.Единица измерения = Цикл IDLE, Период = 1. Это сколько во времени? Или это период это 1 попугай и ко времени вообще не относится. Какой период поставить чтоб один раз в 10 секунд отработало? А не как попало, если это вообще возможно.
На данный момент стоит единица измерения = сек, период = 5. Запись происходит, все четко один раз в 10 секунд. Период пересчета базы каналов стоит 550 миллисекунд.
С "Цикл IDLE" и "Свой поток" так четкой записи не происходит. Она все время в разные промежутки идет то раз в 9 секунд пишет, то раз в 10, то раз в 11. Нету стабильности записи.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Цикл IDLE может быть задан ключом в файле *.cnf конфигурирования запуска узла: " IDLLOOP=<idlLoop> – время цикла IDLE как число основных циклов (ср. @Calc_Loop OUTPUT с Параметр=18). Значение по умолчанию: 1, если время основного цикла больше 1 с; 1000мс/<время основного цикла, мс>, если время основного цикла меньше 1 с; "
В примере из книги ("Быстрый старт"?) описывается запрос типа SELECT и управляется он с экрана с помощью кнопки. Уточните, пожалуйста, используемый Вами алгоритм вызова SQL-запроса с записью данных в БД. Каким образом при периоде обработки CALL.SQL 5 сек. Вы получаете период записи 10 сек.? Сколько каналов CALL.SQL Вы запускаете 1 раз в 10 сек.? Сколько переменных записывается в каждом запросе?
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Запрос на 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, Единица измерения=сек).
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Надо задать каналу CALL.SQL период 1*"цикл CALC", а выдачу "1" на его вход от программы - с перидом 10 сек. (например, сделать период CALL.Program равным 10 сек.). Период обработки базы каналов (в настройках узла) для повышения точности надо задать 50*0.01.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Выслал проект, а то я уже запутался что куда. Этот проект пишет в БД с интервалом в 10 секунд.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Тест вашего исправленного проекта. Показал не стабильность. Нету четкости записи. Опять повторяется, что запись не идет строго каждые 10 секунд. А зависит от нагрузки ПК. Есть даже результат что запись в БД идет раз от полутора до пяти минут.
Сообщения / Posts 112 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Задайте в "Адинистраторе источников данных ODBC" функцию трассировщика. 1. Задайте в файле конфигурирования запуска узла ключ DEBUGON=46000 2. Задайте в проекте ОТ. 3. Установите каналу вызова SQL-запроса флажок "Отладка" и флажок "Отчет тревог". каналу CALL.SQL 4. По протоколу профайлера и по отчету тревог уточните динамику и ошибки отработки канала вызова SQL-запроса. В профайлерном протоколе должны быть зафиксированы моменты начала и конца транзакции и ошибки, зафткстрованные МРВ. 5. По протоколу трассировщика ODBC-драйвера можно увидеть были ли ошибки в транзакциях.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
